Skip to content

Conversation

@battermann
Copy link
Contributor

@battermann battermann commented Sep 11, 2025

Checklist

  • Add a new entry in an appropriate subdirectory of changelog.d
  • Read and follow the PR guidelines

@battermann battermann marked this pull request as ready for review September 11, 2025 15:29
@battermann battermann requested review from a team as code owners September 11, 2025 15:29
@zebot zebot added the ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist label Sep 11, 2025
Copy link
Contributor

@supersven supersven left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 (I especially liked the well-written test.)

supersven added a commit that referenced this pull request Sep 16, 2025
…M should be possible when E2EID is enabled (#4775)

This is a backport of #4772.
@supersven
Copy link
Contributor

IMHO we can merge this once @emil-wire finished testing the backported edition of this PR (#4775).

Copy link
Contributor

@emil-wire emil-wire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, but I'd like some small changes/questions answered


prop
"if e2e identity is activated, the user name cannot be updated"
"if e2e identity is activated, the user name cannot be updated by a wire client"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what happens if you throw SSO into the mix and the users data are different from the ones in scim? Do we have a way of testing/hedging against this scenario?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean the saml attributes and scim data disagree? i don't remember us reading any saml attributes, so that might be fine, but this needs to be double-checked.

Copy link
Contributor Author

@battermann battermann Sep 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand what this question has to do with the problem that this PR solves? But maybe I don't understand the question correctly. SSO/SCIM scenarios are excessively tested in other places.


prop
"if e2e identity is activated, the user name cannot be updated"
"if e2e identity is activated, the user name cannot be updated by a wire client"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean the saml attributes and scim data disagree? i don't remember us reading any saml attributes, so that might be fine, but this needs to be double-checked.

idempLocale = isNothing locale || locale == user.locale
scim = updateOrigin == UpdateOriginWireClient && user.managedBy == Just ManagedByScim
scimConflict = updateOrigin == UpdateOriginWireClient && user.managedBy == Just ManagedByScim
updateByScim = updateOrigin == UpdateOriginScim && user.managedBy == Just ManagedByScim
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is always true that scimConflict == not updateByScim, so you could replace not updateByScim below by scimConflict, then you could simplify line 533 below. and maybe rename scimConflict to updateFromWireClientForScimUser, or something.

or maybe you could shuffle the code long enough to end up with something involving this:

   case updateOrigin of
     Wire... -> _
     Scim... -> _

that may be more readable, and would help with refactoring UpdateOriginType.

(don't take any of this too seriously, doing this review as a test how my virus-infested brain is recovering.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I gave it a try, but was not happy with the result. I suggest leaving it as is, as I think the readability is good, or you make a suggestion?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nah, if you've tried and it didn't improve things i say it's good enough.

@battermann
Copy link
Contributor Author

@emil-wire I tried to address all of your comments and re-requested a review.

@battermann battermann force-pushed the WPB-20203-backend-updating-user-attributes-via-scim-should-be-possible-when-e-2-ei-is-enabled branch from e898360 to dc3bff4 Compare September 25, 2025 12:49
@stefanwire stefanwire requested review from emil-wire and removed request for emil-wire September 30, 2025 09:32
@stefanwire stefanwire removed the request for review from emil-wire September 30, 2025 09:34
@stefanwire
Copy link
Contributor

@emil-wire Requesting changes comes with the obligation to follow up. Dismissed your review for the moment.

@battermann battermann merged commit 09a9044 into develop Sep 30, 2025
8 checks passed
@battermann battermann deleted the WPB-20203-backend-updating-user-attributes-via-scim-should-be-possible-when-e-2-ei-is-enabled branch September 30, 2025 11:22
battermann added a commit that referenced this pull request Oct 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants