-
Notifications
You must be signed in to change notification settings - Fork 5
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
feat: User verification status Proteus (WPB-1775) #2111
Conversation
Datadog ReportBranch report: ✅ |
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.
LGTM 🍨 just a suggestion to add more logs 📝
.fold({ error -> Result.Failure(error) }, | ||
{ Result.Success } |
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.
Do we want to log this info to Datadog? I guess it might not harm as it might be useful identifying and tracking possible issues in the future?
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.
Having the isProteus verified in the client table is ok, but having the same value as aggregated one for the user in my opinion is hard to maintain. I suggest only having the value for the client and whenever we want the aggregated value for the user we need to calculate it on the fly.
fun fromDetailsEntityToUserSummary(userDetailsEntity: UserDetailsEntity): UserSummary | ||
fun fromUserDetailsEntityToOtherUser(userDetailsEntity: UserDetailsEntity): OtherUser |
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.
suggestion: in the first function we have fromDetails, but in the second one is fromUserDetails, I suggest make them the same, either mention fromUserDetails... or fromDetails...
userTypeEntity: UserTypeEntity | ||
): UserDetailsEntity | ||
|
||
fun fromFailedUserToDetailEntity(userId: NetworkQualifiedId): UserDetailsEntity |
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.
suggestion: since it's details
not detail
I suggest to keep the name as it is in the function naming.
@@ -209,6 +308,38 @@ internal class UserMapperImpl( | |||
defederated = false | |||
) | |||
|
|||
/** | |||
* Null and default/hardcoded values will be replaced later when fetching known users. |
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.
suggestion: add todo to it would be better in my opinion.
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.
removed this mapper, as it's not needed
@@ -209,6 +308,38 @@ internal class UserMapperImpl( | |||
defederated = false | |||
) | |||
|
|||
/** | |||
* Null and default/hardcoded values will be replaced later when fetching known users. |
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.
suggestion: add todo to it would be better in my opinion.
@@ -18,6 +18,7 @@ | |||
package com.wire.kalium.logic.util.arrangement.repository | |||
|
|||
import com.wire.kalium.logic.CoreFailure | |||
import com.wire.kalium.logic.StorageFailure |
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.
question: do we need this import anymore?
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.
nope, removed, strange that build script didn't find it
@@ -18,6 +18,7 @@ | |||
package com.wire.kalium.logic.util.arrangement.repository | |||
|
|||
import com.wire.kalium.logic.CoreFailure | |||
import com.wire.kalium.logic.StorageFailure |
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.
question: do we need this import anymore?
CREATE VIEW IF NOT EXISTS UserDetails AS | ||
SELECT | ||
User.qualified_id, | ||
User.name, | ||
User.handle, | ||
User.email, | ||
User.phone, | ||
User.accent_id, | ||
User.team, | ||
User.connection_status, | ||
User.preview_asset_id, | ||
User.complete_asset_id, | ||
User.user_availability_status, | ||
User.user_type, | ||
User.bot_service, | ||
User.deleted, | ||
User.incomplete_metadata, | ||
User.expires_at, | ||
User.defederated, | ||
CASE IFNULL ((SELECT COUNT (*) FROM Client WHERE Client.user_id = User.qualified_id), 0) | ||
-- no clients means not verified | ||
WHEN 0 THEN 0 | ||
ELSE (CASE IFNULL ((SELECT COUNT (*) FROM Client WHERE Client.user_id = User.qualified_id AND is_proteus_verified = 0), 0) | ||
WHEN 0 THEN 1 | ||
-- at least one client is not verified -> user is not verified | ||
ELSE 0 | ||
END) | ||
END AS is_proteus_verified | ||
FROM User; |
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.
suggestion: my suggestion here is to use group-by instead of nested queries.
See this for example:
SELECT
User.qualified_id AS user_id,
CASE
WHEN SUM(CASE WHEN Client.is_proteus_verified = 1 THEN 1 ELSE 0 END) = COUNT(*) THEN 1
ELSE 0
END AS isProteusVerified
FROM User
LEFT JOIN Client ON User.qualified_id = Client.user_id
GROUP BY User.qualified_id;
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.
nice, i make it even better :)
Datadog ReportAll test runs ✅ 2 Total Test Services: 0 Failed, 0 with New Flaky, 2 Passed Test Services
|
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.
👏🏄♂️ Well done buddy
What's new in this PR?
OtherUser
andClient
models (addedisProteusVerified
field)is_proteus_verified
field which is calculated in DB level, by checking if user has any client and if all of them are verified)