-
Notifications
You must be signed in to change notification settings - Fork 325
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
Fix calendar integration setting in backoffice / stern #3761
Changes from all commits
357b315
0dbc53c
399bddf
0b99c98
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Fix calendar integration setting in backoffice / stern |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -92,6 +92,7 @@ tests s = | |
test s "/teams/:tid/features/mls" $ testFeatureConfig @MLSConfig, | ||
test s "GET /teams/:tid/features/classifiedDomains" $ testGetFeatureConfig @ClassifiedDomainsConfig (Just FeatureStatusEnabled), | ||
test s "GET /teams/:tid/features/outlookCalIntegration" $ testFeatureStatus @OutlookCalIntegrationConfig, | ||
test s "PUT /teams/:tid/features/outlookCalIntegration{,'?lockOrUnlock'}" $ testFeatureStatusWithLock @OutlookCalIntegrationConfig, | ||
test s "GET /i/consent" testGetConsentLog, | ||
test s "GET /teams/:id" testGetTeamInfo, | ||
test s "GET i/user/meta-info?id=..." testGetUserMetaInfo, | ||
|
@@ -337,6 +338,46 @@ testFeatureStatusOptTtl mTtl = do | |
cfg' <- getFeatureConfig @cfg tid | ||
liftIO $ wsStatus cfg' @?= newStatus | ||
|
||
testFeatureStatusWithLock :: | ||
forall cfg. | ||
( KnownSymbol (FeatureSymbol cfg), | ||
ToSchema cfg, | ||
Typeable cfg, | ||
IsFeatureConfig cfg, | ||
Eq cfg, | ||
Show cfg | ||
) => | ||
TestM () | ||
testFeatureStatusWithLock = do | ||
let mTtl = Nothing -- this function can become a variant of `testFeatureStatusOptTtl` if we need one. | ||
(_, tid, _) <- createTeamWithNMembers 10 | ||
getFeatureConfig @cfg tid >>= \cfg -> liftIO $ do | ||
cfg @?= defFeatureStatus @cfg | ||
-- if either of these two lines fails, it's probably because the default is surprising. | ||
-- in that case, make the text more flexible. | ||
wsLockStatus cfg @?= LockStatusLocked | ||
wsStatus cfg @?= FeatureStatusDisabled | ||
|
||
void $ putFeatureStatusLock @cfg tid LockStatusUnlocked mTtl | ||
getFeatureConfig @cfg tid >>= \cfg -> liftIO $ do | ||
wsLockStatus cfg @?= LockStatusUnlocked | ||
wsStatus cfg @?= FeatureStatusDisabled | ||
|
||
void $ putFeatureStatus @cfg tid FeatureStatusEnabled Nothing | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Testing to en-/disable the feature isn't really needed IMO, but it also doesn't hurt. |
||
getFeatureConfig @cfg tid >>= \cfg -> liftIO $ do | ||
wsLockStatus cfg @?= LockStatusUnlocked | ||
wsStatus cfg @?= FeatureStatusEnabled | ||
|
||
void $ putFeatureStatusLock @cfg tid LockStatusLocked mTtl | ||
getFeatureConfig @cfg tid >>= \cfg -> liftIO $ do | ||
wsLockStatus cfg @?= LockStatusLocked | ||
wsStatus cfg @?= FeatureStatusDisabled | ||
|
||
void $ putFeatureStatusLock @cfg tid LockStatusUnlocked mTtl | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought we implemented the team features so that if they are locked, they are reset to their default, which would be "disabled", no? I am surprised that this test passes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if locked, status is the default. but if unlocked, it switches back to whatever it was during the last unlock window. we can debate whether this is a good idea, but last time we did we concluded that it's nice for the admin to not lose settings if they forget to update their cc info. |
||
getFeatureConfig @cfg tid >>= \cfg -> liftIO $ do | ||
wsLockStatus cfg @?= LockStatusUnlocked | ||
wsStatus cfg @?= FeatureStatusEnabled | ||
|
||
testGetConsentLog :: TestM () | ||
testGetConsentLog = do | ||
(_, email) <- randomEmailUser | ||
|
@@ -619,6 +660,31 @@ putFeatureStatus tid status mTtl = do | |
mkTtlQueryParam :: Maybe FeatureTTL -> Request -> Request | ||
mkTtlQueryParam = maybe id (queryItem "ttl" . toByteString') | ||
|
||
putFeatureStatusLock :: | ||
forall cfg. | ||
( KnownSymbol (FeatureSymbol cfg), | ||
ToSchema cfg, | ||
Typeable cfg, | ||
IsFeatureConfig cfg | ||
) => | ||
TeamId -> | ||
LockStatus -> | ||
Maybe FeatureTTL -> | ||
TestM ResponseLBS | ||
putFeatureStatusLock tid lockStatus mTtl = do | ||
s <- view tsStern | ||
put | ||
( s | ||
. paths ["teams", toByteString' tid, "features", Public.featureNameBS @cfg, "lockOrUnlock"] | ||
. queryItem "lock-status" (toByteString' lockStatus) | ||
. mkTtlQueryParam mTtl | ||
. contentJson | ||
. expect2xx | ||
) | ||
where | ||
mkTtlQueryParam :: Maybe FeatureTTL -> Request -> Request | ||
mkTtlQueryParam = maybe id (queryItem "ttl" . toByteString') | ||
|
||
putFeatureConfig :: | ||
forall cfg. | ||
( KnownSymbol (FeatureSymbol cfg), | ||
|
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.
Our query parameters are mostly snake case, and sometimes camel case is used. But I haven't seen kebab cases so far. But I am ok with it here (it's just stern)