-
Notifications
You must be signed in to change notification settings - Fork 324
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
Legalhold: dynamic whitelisted teams & whitelist-teams-and-implicit-consent feature in tests #1557
Conversation
remove config remove setting & use dynamic whitelist
d191c64
to
b1c9d03
Compare
The end-point already is internal, and has to be by design. It may be easier for the operator to be able to update the table *before* turning it on; I certainly can't think of a reason why it they should be forbidden to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've deactivated the test suite so you can deploy this on staging to make some progress with QA and the team.
Ideas for getting the test suite back on track:
- Don't use
deleteLHWhitelistTeam
, butdeleteTeam
. The latter is implicit inwithTeam
. (See my commits and the comments that come with them.) - Don't remove
grantConsent*
, but check the galley server config. If LH isdisabled-by-default
, usegrantConsent*
(those tests did work until before this PR); if it iswhitelist-implicit-consent
, useputLHWhitelistTeam
. Remember to usewithTeam
if you do that. - Where the behavior differs, branch on feature flag again. Again, the old behavior should work already, the new may need adjusting.
I am still hoping all of the necessary changes will be quite local, but I can't see that very clearly yet.
These should still pass if galley.integration.yaml sets legalhold to `disabled-by-default` again.
underscoring names that we want to keep is still a bit rancid, but at least this way we'll get warnings about new things we introduce accidentally.
I sometimes get the tests to pass now locally, sometimes this happens:
I'd try to get the call stack next. (The way we create this error should be banned, it's been costing me so much time! Or I should just figure out which one it is, and avoid it.) |
Changes to production code
This PR removes the
legalHoldTeamsWhitelist
galley config item and introduces a new internal endpoint/i/legalhold/whitelisted-teams
to manage the set of whitelisted teams (the underlying table isgalley.legalhold_whitelisted
). Since the whitelisted teams are needed on every team member lookup this list is cached: at the beginning of every request the list is fetched and stored in an ioref in galley's environment.The API is
PUT /i/legalhold/whitelisted-teams/{tid}
to whitelist a teamGET /i/legalhold/whitelisted-teams
which returns a list of team uuids as a JSON arrayChanges to integration tests (CI + local development)
This PR updates the galley configuration for 1) CI and and for 2) local development:
legalhold: whitelist-teams-and-implicit-consent
(waslegalhold: disabled-by-default
before)All legalhold integration tests written for the
disabled-by-default
feature flag are moved to moduleLegalHold.DisabledByDefault
(wasLegalHold
before). The tests configured to run only whenlegalhold: disabled-by-default
is set, otherwise they pass without running.All legalhold integration tests in the
LegalHold
module are updated so that they specify the behaviour under thewhitelist-teams-and-implicit-consent
feature flag. The tests configured to run only whenlegalhold: whitelist-teams-and-implicit-consent
is set, otherwise they pass without running.This PR also adapts some of brig's integration tests to work under the assumption that
legalhold: whitelist-teams-and-implicit-consent
is set.Notes
Note: Running galley with
legalhold: whitelist-teams-and-implicit-consent
configuration changes the error codes of some endpoints, namely:DELETE /teams/{tid}/legalhold/setttings
legalhold-disable-unimplemented
.It's not possible to deactivate legalhold for a team.
POST /teams/{tid}/legalhold/setttings
legalhold-unavailable
when team is not whitelisted(is 403
legalhold-not-enabled
when lh is not enabled for the teamwith
legalhold: disabled-by-default
galley config)
POST /teams/{tid}/legalhold/{uid}
legalhold-not-enabled
when user has not given consent(is 403 with label
operation-denied
or 409 with label
legalhold-no-consent
with
legalhold: disabled-by-default
galley config)PUT /teams/{tid}/legalhold/{uid}/approve
access-denied
when user has not given consent(is 403
legalhold-not-enabled
with labelwith
legalhold: disabled-by-default
galley config)These API differences are not introduced by this PR.