-
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
User subsystem: add profile update operations #4046
Conversation
3896b3c
to
c250c5f
Compare
0211289
to
8cf862d
Compare
Some of the functions in brig now have a UserStore constraint. This is only temporary until all the user-related functionality has been migrated to subsystems.
8cf862d
to
3f3ac72
Compare
Conflicts: services/brig/src/Brig/API/Public.hs
-- PERFORMANCE(fisx): if a user changes 4 attributes with one request, the database will | ||
-- be hit with 4 requests (one for each attribute). this is probably fine as this | ||
-- operation is not heavily used. (also, the four operations are batched, which may or | ||
-- may not help.) |
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.
anybody care to give a second opinion?
@@ -1,13 +1,72 @@ | |||
{-# LANGUAGE TemplateHaskell #-} | |||
{-# OPTIONS_GHC -Wno-ambiguous-fields #-} |
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.
What do you mean? Is this scheduled to become an error in ghc? What's the replacement?
retry x5 $ write handleDelete (params LocalQuorum (Identity h)) | ||
let key = "@" <> fromHandle h | ||
deleteClaim uid key (30 # Minute) | ||
_ -> pure () -- this shouldn't happen, the call side should always check that `h` and `uid` belong to the same account. |
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.
this is very old code. let's not touch it in this PR?
-- | Simple updates (as opposed to, eg., handle, where we need to manage locks). Empty fields are ignored (not deleted). | ||
UpdateUserProfile :: Local UserId -> Maybe ConnId -> UpdateOriginType -> UserProfileUpdate -> UserSubsystem m () | ||
-- | parse and lookup a handle, return what the operation has found | ||
CheckHandle :: Text {- use Handle here? -} -> UserSubsystem m CheckHandleResp | ||
-- | checks a number of 'Handle's for availability and returns at most 'Word' amount of them | ||
CheckHandles :: [Handle] -> Word -> UserSubsystem m [Handle] | ||
-- | parses a handle, this may fail so it's effectful | ||
UpdateHandle :: Local UserId -> Maybe ConnId -> UpdateOriginType -> Text {- use Handle here? -} -> UserSubsystem m () |
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.
not decided yet, that's why we left the question. :)
-- | Simple updates (as opposed to, eg., handle, where we need to manage locks). Empty fields are ignored (not deleted). | ||
UpdateUserProfile :: Local UserId -> Maybe ConnId -> UpdateOriginType -> UserProfileUpdate -> UserSubsystem m () | ||
-- | parse and lookup a handle, return what the operation has found | ||
CheckHandle :: Text {- use Handle here? -} -> UserSubsystem m CheckHandleResp | ||
-- | checks a number of 'Handle's for availability and returns at most 'Word' amount of them | ||
CheckHandles :: [Handle] -> Word -> UserSubsystem m [Handle] | ||
-- | parses a handle, this may fail so it's effectful | ||
UpdateHandle :: Local UserId -> Maybe ConnId -> UpdateOriginType -> Text {- use Handle here? -} -> UserSubsystem m () |
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 think it's better to keep the question rather than making the impression to future readers that nobody has ever thought about this.
@@ -544,17 +561,18 @@ listActivatedAccountsH | |||
u4 <- (\phone -> API.lookupAccountsByIdentity (Right phone) includePendingInvitations) `mapM` phones | |||
pure $ u1 <> u2 <> join u3 <> join u4 | |||
|
|||
-- FUTUREWORK: this should use UserStore only through UserSubsystem. |
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.
maybe resolve that now?
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.
nah, next PR!
@@ -52,28 +75,41 @@ newtype NotPendingStoredUser = NotPendingStoredUser StoredUser | |||
|
|||
instance Arbitrary NotPendingStoredUser where | |||
arbitrary = do | |||
user <- arbitrary | |||
user <- arbitrary `suchThat` \user -> isJust user.identity |
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.
because it's not trivial (nothing is, not even this conversation) and serves no practical purpose? sorry :). let's discuss in person if that doesn't convince you.
@@ -52,28 +75,41 @@ newtype NotPendingStoredUser = NotPendingStoredUser StoredUser | |||
|
|||
instance Arbitrary NotPendingStoredUser where | |||
arbitrary = do | |||
user <- arbitrary | |||
user <- arbitrary `suchThat` \user -> isJust user.identity |
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 would prefer to think / talk about the question how to reduce the amount of assumptions that goes into this type. like, is an arbitrary user consistent if we merely change the status?)
This reverts commit 8c66230. (maybe this is used elsewhere? also the removal wasn't complete.)
@@ -544,17 +561,18 @@ listActivatedAccountsH | |||
u4 <- (\phone -> API.lookupAccountsByIdentity (Right phone) includePendingInvitations) `mapM` phones | |||
pure $ u1 <> u2 <> join u3 <> join u4 | |||
|
|||
-- FUTUREWORK: this should use UserStore only through UserSubsystem. |
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.
nah, next PR!
https://wearezeta.atlassian.net/browse/WPB-8880
Checklist
changelog.d