1
0
mirror of https://github.com/Unleash/unleash.git synced 2025-03-14 00:15:52 +01:00
Commit Graph

100 Commits

Author SHA1 Message Date
Thomas Heartman
6188079122
feat: add project owners to personal dashboard (#8293)
This PR adds all user-type owners of projects that you have access to to
the personal dashboard payload. It adds the new `projectOwners` property
regardless of whether you have access to any projects or not because it
required less code and fewer conditionals, but we can do the filtering
if we want to.

To add the owners, it uses the private project checker to get accessible
projects before passing those to the project owner read model, which has
a new method to fetch user owners for projects.
2024-09-30 10:49:34 +02:00
Thomas Heartman
a7e0743d88
chore: remove manual anonymization of outgoing project owners (#8252)
This change removes the flag used to anonymize project owners on the
way out. It was an issue in demo when we'd forgotten to configure the
email encryption. However, this issue has been resolved and we can
remove this check now.
2024-09-26 11:29:18 +02:00
Mateusz Kwasniewski
ceb21fbe51
feat: get projects by ids (#8269) 2024-09-26 11:27:59 +02:00
Mateusz Kwasniewski
823f6330b7
refactor: move getProjectsByUser to read model (#8262) 2024-09-26 09:45:02 +02:00
Thomas Heartman
44bf6615a3
feat: add project owners to personal dashboard project payload (#8248)
This PR adds project owner information to the personal dashboard's
project payload.

To do so, it uses the existing project owners read model.

I've had to make a few changes to the project owners read model to
accomodate this:
- make the input type to `addOwners` more lenient. We only need the
project ids, so we can make that the only required property
- fall back to using email as the name if the user has no name or
username (such as if you sign up with the demo auth)
2024-09-25 11:32:33 +00:00
gitar-bot[bot]
338b5ce853
[Gitar] Cleaning up stale flag: useProjectReadModel with value true (#8211)
Co-authored-by: Gitar <noreply@gitar.co>
Co-authored-by: Tymoteusz Czech <2625371+Tymek@users.noreply.github.com>
2024-09-23 13:20:42 +02:00
gitar-bot[bot]
1296327c03
[Gitar] Cleaning up stale flag: archiveProjects with value true (#8201) 2024-09-23 11:51:55 +02:00
Fredrik Strand Oseberg
2406b10ca3
chore: remove debug logs (#8147)
We used these logs to debug an issue in sandbox regarding permissions.
They are no longer needed.
2024-09-17 09:06:29 +02:00
Fredrik Strand Oseberg
9c435a9ec6
chore: add stringified logs (#8134) 2024-09-11 09:33:13 +02:00
Fredrik Strand Oseberg
8a92dd0fd7
chore: add logging to new code path (#8133) 2024-09-11 08:31:31 +02:00
Fredrik Strand Oseberg
e1b7cfd8dd
Fix/project role permission grant (#8084)
## Background

In #6380 we fixed a privilege escalation bug that allowed members of a
project that had permission to add users to the project with roles that
had a higher permission set than themselves. The PR linked essentially
constricts you only be able to assign users to roles that you possess
yourself if you are not an Admin or Project owner.

This fix broke expectations for another customer who needed to have a
project owner without the DELETE_PROJECT permission. The fix above made
it so that their custom project owner role only was able to assign users
to the project with the role that they posessed.

## Fix

Instead of looking directly at which role the role granter has, this PR
addresses the issue by making the assessment based on the permission
sets of the user and the roles to be granted. If the granter has all the
permissions of the role being granted, the granter is permitted to
assign the role.

## Other considerations

The endpoint to get roles was changed in this PR. It previously only
retrieved the roles that the user had in the project. This no-longer
makes sense because the user should be able to see other project roles
than the one they themselves hold when assigning users to the project.

The drawback of returning all project roles is that there may be a
project role in the list that the user does not have access to assign,
because they do not hold all the permissions required of the role. This
was discussed internally and we decided that it's an acceptable
trade-off for now because the complexities of returning a role list
based on comparing permissions set is not trivial. We would have to
retrieve each project role with permissions from the database, and run
the same in-memory check against the users permission to determine which
roles to return from this endpoint. Instead we opted for returning all
project roles and display an error if you try to assign a role that you
do not have access to.

## Follow up
When this is merged, there's no longer need for the frontend logic that
filters out roles in the role assignment form. I deliberately left this
out of the scope for this PR because I couldn't wrap my head around
everything that was going on there and I thought it was better to pair
on this with @chriswk or @nunogois in order to make sure we get this
right as the logic for this filtering seemed quite complex and was
touching multiple different components.

---------

Co-authored-by: Fredrik Strand Oseberg <fredrikstrandoseberg@Fredrik-sin-MacBook-Pro.local>
2024-09-10 20:35:45 +02:00
Mateusz Kwasniewski
47753b90b2
fix: user projects should exclude archived ones (#8118) 2024-09-06 12:29:05 +02:00
Jaanus Sellin
037651c35f
feat: start returning onboarding status with project overview (#8058)
To show/hide onboarding flow, we need to get extra info about onboarding
status. This PR adds it to project overview.
2024-09-03 14:41:47 +03:00
Mateusz Kwasniewski
f27e07ab88
feat: onboarding store (#8027) 2024-09-02 08:53:23 +02:00
Tymoteusz Czech
427c43e123
fix: project last seen at metrics (#7988)
Read `last_seen_at` from correct table `last_seen_at_metrics`, instead
of deprecated `feature.last_seen_at`
2024-08-27 10:17:19 +00:00
gitar-bot[bot]
4615ff40ce
[Gitar] Cleaning up stale flag: resourceLimits with value true (#7964)
[![Gitar](https://raw.githubusercontent.com/gitarcode/.github/main/assets/gitar-banner.svg)](https://gitar.co)
  
  ---
This automated PR was generated by [Gitar](https://gitar.co). View
[docs](https://gitar.co/docs).

---------

Co-authored-by: Gitar <noreply@gitar.co>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
2024-08-22 13:20:53 +02:00
Mateusz Kwasniewski
ee1d8ee8cd
fix: misc fixes for project archive (#7948) 2024-08-21 10:34:13 +02:00
Thomas Heartman
7c774b22e8
fix: don't count flags multiple times (bonus: don't count non-project events) (#7931)
This PR fixes an issue where the number of flags belonging to a project
was wrong in the new getProjectsForAdminUi.

The cause was that we now join with the events table to get the most
"lastUpdatedAt" data. This meant that we got multiple rows for each
flag, so we counted the same flag multiple times. The fix was to use a
"distinct".

Additionally, I used this as an excuse to write some more tests that I'd
been thinking about. And in doing so also uncovered another bug that
would only ever surface in verrry rare conditions: if a flag had been
created in project A, but moved to project B AND the
feature-project-change event hadn't fired correctly, project B's last
updated could show data from that feature in project A.

I've also taken the liberty of doing a little bit of cleanup.
2024-08-20 09:31:45 +00:00
Thomas Heartman
7008070fc1
chore: impl empty results for fake project read model (#7912)
Implements empty responses for the fake project read model. Instead of
throwing a not implemented error, we'll return empty results.

This makes some of the tests in enterprise pass.
2024-08-19 10:53:05 +02:00
Thomas Heartman
f965246b83
chore: minor cleanup in new project read model (#7911)
This PR touches up a few small things in the project read model.

Fixes:
Use the right method name in the query/method timer for
`getProjectsForAdminUi`. I'd forgotten to change the timer name from the
original method name.

Spells the method name correctly for the `getMembersCount` timer (it
used to be `getMemberCount`, but the method is callled `getMembersCount`
with a plural s).

Changes:
Call the `getMembersCount` timer from within the `getMembersCount`
method itself. Instead of setting that timer up from two different
places, we can call it in the method we're timing. This wasn't a problem
previously, because the method was only called from a single place.
Assuming we always wanna time that query, it makes more sense to put the
timing in the actual method.
2024-08-19 10:13:30 +03:00
Thomas Heartman
79c3f8e975
refactor: switch projectStore.getProjects with projectReadModel.getProjectsForAdminUi in project service (#7904)
Hooks up the new project read model and updates the existing project
service to use it instead when the flag is on.

In doing:
- creates a composition root for the read model
- includes it in IUnleashStores
- updates some existing methods to accept either the old or the new
model
- updates the OpenAPI schema to deprecate the old properties
2024-08-19 08:46:50 +02:00
Thomas Heartman
0847a395dc
chore: Extract project read model (#7887)
Creates a new project read model exposing data to be used for the UI and
for the insights module.

The model contains two public methods, both based on the project store's
`getProjectsWithCounts`:
- `getProjectsForAdminUi`
- `getProjectsForInsights`

This mirrors the two places where the base query is actually in use
today and adapts the query to those two explicit cases.

The new `getProjectsForAdminUi` method also contains data for last flag
update and last flag metric reported, as required for the new projects
list screen.

Additionally the read model contains a private `getMembersCount` method,
which is also lifted from the project store. This method was only used
in the old `getProjectsWithCounts` method, so I have also removed the
method from the public interface.

This PR does *not* hook up the new read model to anything or delete any
existing uses of the old method.

## Why?

As mentioned in the background, this query is used in two places, both
to get data for the UI (directly or indirectly). This is consistent with
the principles laid out in our [ADR on read vs write
models](https://docs.getunleash.io/contributing/ADRs/back-end/write-model-vs-read-models).

There is an argument to be made, however, that the insights module uses
this as an **internal** read model, but the description of an internal
model ("Internal read models are typically narrowly focused on answering
one question and usually require simple queries compared to external
read models") does not apply here. It's closer to the description of
external read models: "View model will typically join data across a few
DB tables" for display in the UI.

## Discussion points

### What about properties on the schema that are now gone?

The `project-schema`, which is delivered to the UI through the
`getProjects` endpoint (and nowhere else, it seems), describes
properties that will no longer be sent to the front end, including
`defaultStickiness`, `avgTimeToProduction`, and more. Can we just stop
sending them or is that a breaking change?

The schema does not define them as required properties, so in theory,
not sending them isn't breaking any contracts. We can deprecate the
properties and just not populate them anymore.

At least that's my thought on it. I'm open to hearing other views.

### Can we add the properties in fewer lines of code? 

Yes! The [first commit in this PR
(b7534bfa)](b7534bfa07)
adds the two new properties in 8 lines of code.

However, this comes at the cost of diluting the `getProjectsWithCounts`
method further by adding more properties that are not used by the
insights module. That said, that might be a worthwhile tradeoff.

## Background

_(More [details in internal slack
thread](https://unleash-internal.slack.com/archives/C046LV6HH6W/p1723716675436829))_

I noticed that the project store's `getProjectWithCounts` is used in
exactly two places:

1. In the project service method which maps directly to the project
controller (in both OSS and enterprise).
2.  In the insights service in enterprise.

In the case of the controller, that’s the termination point. I’d guess
that when written, the store only served the purpose of showing data to
the UI.

In the event of the insights service, the data is mapped in
getProjectStats.
But I was a little surprised that they were sharing the same query, so I
decided to dig a little deeper to see what we’re actually using and what
we’re not (including the potential new columns). Here’s what I found.

Of the 14 already existing properties, insights use only 7 and the
project list UI uses only 10 (though the schema mentions all 14 (as far
as I could tell from scouring the code base)). Additionally, there’s two
properties that I couldn’t find any evidence of being used by either:
-   default stickiness
-   updatedAt (this is when the project was last updated; not its flags)
2024-08-16 10:52:57 +02:00
Mateusz Kwasniewski
30cbde573b
feat: return archived at in project overview (#7888) 2024-08-15 14:15:06 +02:00
Tymoteusz Czech
3baeb4c541
feat: dialogs for project revive and delete (#7863)
Dialog needed to confirm revive/delete actions
2024-08-15 07:25:49 +00:00
Jaanus Sellin
627768b96c
feat: start using event service composition root (#7871)
During adding privateProjectsChecker, I saw that events composition root
is not used almost at all.
Refactored code so we do not call new EventService anymore.
2024-08-15 08:33:46 +03:00
Mateusz Kwasniewski
b042afb7dd
feat: archived projects query improved (#7866) 2024-08-14 11:01:17 +02:00
Mateusz Kwasniewski
4738d4a61f
feat: query archived projects (#7862) 2024-08-13 15:33:31 +02:00
Mateusz Kwasniewski
bb30032f2e
feat: revive project (#7847) 2024-08-13 10:25:42 +02:00
Mateusz Kwasniewski
fcf1329816
feat: exclude archived projects from insights and project stats (#7843) 2024-08-13 10:00:04 +02:00
Mateusz Kwasniewski
9b781b781a
feat: prevent move feature to archived project (#7839) 2024-08-12 13:29:38 +02:00
Mateusz Kwasniewski
bde81b940c
feat: prevent adding flags to archived project (#7811) 2024-08-09 09:00:19 +02:00
Mateusz Kwasniewski
fffed5d8dc
feat: filter out archived projects from the main project list (#7803) 2024-08-08 13:22:44 +02:00
Mateusz Kwasniewski
0450bfe6f9
feat: archive project service (#7794) 2024-08-07 12:09:00 +02:00
Jaanus Sellin
0118f88964
fix: feature type is now validated (#7769)
Previously people were able to send random data to feature type. Now it
is validated.

Fixes https://github.com/Unleash/unleash/issues/7751

---------

Co-authored-by: Thomas Heartman <thomas@getunleash.io>
2024-08-06 12:27:20 +03:00
Jaanus Sellin
bcb7a803d0
feat: new event search (#7708)
This introduces the new event search API, with paging.
2024-08-02 10:56:42 +03:00
Tymoteusz Czech
d1e70eefbe
feat: Remove orphaned tokens flags (#7714)
Cleanup of `allowOrphanedWildcardTokens` and `cleanApiTokenWhenOrphaned`
2024-08-01 13:31:52 +02:00
Tymoteusz Czech
1f2d47bd91
fix: on project delete with tokens put token deleted in audit log (#7675)
Use service with audit tracking instead of store directly.
2024-07-26 14:06:15 +02:00
Thomas Heartman
f15bcdc2a6
chore: send prometheus metrics when someone tries to exceed resource limits (#7617)
This PR adds prometheus metrics for when users attempt to exceed the
limits for a given resource.

The implementation sets up a second function exported from the
ExceedsLimitError file that records metrics and then throws the error.
This could also be a static method on the class, but I'm not sure that'd
be better.
2024-07-18 13:35:45 +02:00
Tymoteusz Czech
b9c3d101ba
feat: statistics for orphaned tokens (#7568)
Added metrics for orphaned tokens and modified `createTokenRowReducer` to exclude tokens in v1 format.
2024-07-11 11:39:38 +02:00
Thomas Heartman
e2c6d468e4
Chore: use createApiTokenService instead of newing it up (#7560)
PR #7519 introduced the pattern of using `createApiTokenService` instead
of newing it up. This usage was introduced in a concurrent PR (#7503),
so we're just cleaning up and making the usage consistent.
2024-07-09 14:11:56 +02:00
David Leek
2e5d81cb89
chore: delete project api tokens when last mapped project is removed (#7503)
Deletes API tokens bound to specific projects when the last project they're mapped to is deleted.

---------

Co-authored-by: Tymoteusz Czech <2625371+Tymek@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
2024-07-09 13:49:26 +02:00
Mateusz Kwasniewski
e9b643761c
feat: Project limit UI (#7518) 2024-07-02 15:29:58 +02:00
Mateusz Kwasniewski
8a9535d352
feat: projects limit (#7514) 2024-07-02 12:03:00 +02:00
Mateusz Kwasniewski
5bd32f264d
feat: strategy limit to 30 (#7473) 2024-06-28 11:18:44 +02:00
Thomas Heartman
95359ecff8
fix: cap project ids to 90 characters (without suffix) (#7481)
This fixes the issue where project names that are 100 characters long
or longer would cause the project creation to fail. This is because
the resulting ID would be longer than the 100 character limit imposed
by the back end.

We solve this by capping the project ID to 90 characters, which leaves
us with 10 characters for the suffix, meaning you can have 1 billion
projects (999,999,999 + 1) that start with the same 90
characters (after slugification) before anything breaks.

It's a little shorter than what it strictly has to be (we could
probably get around with 95 characters), but at this point, you're
reaching into edge case territory anyway, and I'd rather have a little
too much wiggle room here.
2024-06-28 09:25:27 +02:00
Thomas Heartman
a9a87bc84d
chore: change generated project id format to use incrementing numbers instead of hashes (#7456) 2024-06-27 09:21:09 +02:00
Mateusz Kwasniewski
ea1221c45e
chore: remove unstable label from GA metrics features (#7433) 2024-06-24 13:32:35 +02:00
Thomas Heartman
0af5bbad38
chore: remove createProjectWithEnvironmentConfig and newCreateProjectUI flags (#7429)
This PR removes the last two flags related to the project managament
improvements project, making the new project creation form GA.

In doing so, we can also delete the old project creation form (or at
least the page, the form is still in use in the project settings).
2024-06-24 12:53:55 +02:00
Thomas Heartman
c2a29b49b8
fix: turn off showing usernames and emails in the project cards when the flag is turned on (#7421)
This PR:
- adds a flag to anonymize user emails in the new project cards
- performs the anonymization using the existing `anonymise` function
that we have.

It does not anonymize the system user, nor does it anonymize groups. It
does, however, leave the gravatar url unchanged, as that is already
hashed (but we may want to hide that too).

This PR also does not affect the user's name or username. Considering
the target is the demo instance where the vast majority of users don't
have this (and if they do, they've chosen to set it themselves), this
seems an appropriate mitigation.

With the flag turned off:

![image](https://github.com/Unleash/unleash/assets/17786332/10a84562-c025-4e5c-b642-f949595b4e7e)

With the flag on:

![image](https://github.com/Unleash/unleash/assets/17786332/6fc35203-e2fa-4208-9650-0a87d3898996)
2024-06-21 12:51:37 +02:00
Nuno Góis
4736084e00
fix: check for permission in group access assignment (#7408)
Fix project role assignment for users with `ADMIN` permission, even if
they don't have the Admin root role. This happens when e.g. users
inherit the `ADMIN` permission from a group root role, but are not
Admins themselves.

---------

Co-authored-by: Gastón Fournier <gaston@getunleash.io>
2024-06-18 17:06:34 +01:00