-
Notifications
You must be signed in to change notification settings - Fork 333
Conference call initiation flag for personal accounts #1811
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
Conference call initiation flag for personal accounts #1811
Conversation
f33c959
to
c3a17f9
Compare
ci failed in docker images:
pretty sure that's unrelated... |
5c98e0d
to
5d871b2
Compare
1ae03c0
to
1efeacf
Compare
With default for NULL and default for new records.
(will need this in a moment to generate servant-clients in galley integration tests.)
(Turns out I didn't need to move the servant types to wire-api after all, the tests need to be in brig because they require the brig server config. But I'm pretty sure we're going to need that stuff in galley eventually...)
I forgot to actually write this default into newly created users if available. Detail: if you want `defaultIfNew` to be `null` (so you can change your mind about teh default for everybody later), just omit the line in the yaml file. This wasn't possible before, as there is also a hard-coded default in the source.
3a72cf3
to
80607cb
Compare
I need to finish the checklist, but this should be ready for review as it is. I expect the remaining changes to be very small and isolated. |
Hum, I think this last(?) one is still genuine.
|
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.
Looks good. I left a few minor comments. Feel free to address them in a separate PR, if this needs to be merged quickly.
@@ -402,6 +404,11 @@ createUser new = do | |||
return Nothing | |||
pure pdata | |||
|
|||
initAccountFeatureConfig :: UserId -> AppIO () | |||
initAccountFeatureConfig uid = do | |||
mbCciDefNew <- asks (^. settings . getAfcConferenceCallingDefNewMaybe) |
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.
You can just use view
with a lens instead of ask . view
.
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.
(thanks :)
>>= either (liftIO . throwIO . ErrorCall . ("putAccountFeatureConfigClient: " <>) . show) pure | ||
|
||
mbStatus' <- getAccountFeatureConfigClient brigep mgr uid | ||
liftIO $ assertEqual "1" (Right status) mbStatus' |
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.
Could you use write some meaningful error messages here, so when these fail we know what went wrong?
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.
@@ -206,10 +219,12 @@ setFeatureStatusNoConfig applyState tid status = do | |||
Event.Event Event.Update (Public.knownTeamFeatureName @a) (EdFeatureWithoutConfigChanged newStatus) | |||
pure newStatus | |||
|
|||
getSSOStatusInternal :: Maybe TeamId -> Galley (Public.TeamFeatureStatus 'Public.TeamFeatureSSO) | |||
type GetFeatureInternalParam = Either (Maybe UserId) TeamId |
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 guess this is alright, but for the future would it make sense to make this a type family dependent on the feature flag, so that we get more type safety?
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.
fully agreed, yet de-prioritized (sorry...)
getAccountFeatureConfigClientM :: | ||
UserId -> Client.ClientM Public.TeamFeatureStatusNoConfig | ||
( _ | ||
:<|> getAccountFeatureConfigClientM | ||
:<|> _ | ||
:<|> _ | ||
) = Client.client (Proxy @IAPI.API) |
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.
Ah, this is pretty ugly. It took me a while to parse it. Wouldn't it make sense to change the API definition to be a record like the other ones, so we wouldn't need to do this?
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 though about that, and was too lazy. But you're right, I'll try to make the time!
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 was being a bit lazy. hope this is better?
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.
Sure, it's fine, but the other API definitions are now using the Generic-based approach where you can just define a single record data type that contains all of the endpoints, instead of separate types joined by :<|>
. See for example https://github.com/wireapp/wire-server/blob/develop/libs/wire-api/src/Wire/API/Routes/Public/Galley.hs#L75.
https://wearezeta.atlassian.net/browse/SQSERVICES-763
Notes to the reviewer: I recommend looking at the headlines of the individual commits and get a rough idea of what's in them, and then read the whole thing in one step.
The issue describes roughly what's happening here. Some more random remarks:
Checklist
make git-add-cassandra-schema
to update the cassandra schema documentation.changelog.d
.