Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add restrictions to catalogs based on user attributes #369

Merged
merged 6 commits into from
Feb 7, 2024

Conversation

johnksv
Copy link
Contributor

@johnksv johnksv commented Feb 5, 2024

By providing a restrictions configuration to a catalog (in catalogs.json) we can now restrict which catalogs should be presented to the user based on some attribute they have. This may be useful in scenarios where one only wants certain users some catalogs (i.e. differentiating catalogs based on some user trait).

Catalogs which have some. restrictions will NOT be available on the public/catalogs endpoint. Instead a new endpoint under /my-lab is introduced.
The restrictions are also enforced when the user try to launch a service.
Changes in the frontend are required.
This PR is backward compatible, in that case that catalogs without any restrictions are still available and can be launched by the user.

By providing a restrictions-object to the catalogs.json we can now restrict which catalogs should be presented to the user based on some attribute they have. This may be useful in scenarios where one only wants certain users some catalogs.
From this commit it still remain to implement a check on actual launch, as well at documentation of how the restrictions-object should be configured in the json

Co-authored-by: Olivier Levitt <olivier.levitt@gmail.com>
Clearer separation of concerns, which also makes it easier to test
Such that the user can't launch a service he is not entitled to.
Also rewrite to return optionals to make it clearer that it may actually be the case that the catalog may not exist in the user 'context'
Copy link

sonarcloud bot commented Feb 6, 2024

Quality Gate Passed Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

@johnksv johnksv marked this pull request as ready for review February 6, 2024 11:51
@olevitt
Copy link
Contributor

olevitt commented Feb 7, 2024

LGTM, thanks 👍

@olevitt olevitt merged commit c90a846 into InseeFrLab:main Feb 7, 2024
5 checks passed
@johnksv johnksv deleted the differantiate-catalogs branch February 9, 2024 17:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants