THREESCALE-12410: Remove signup types :partner and :partner:*#4308
Open
jlledom wants to merge 2 commits into
Open
THREESCALE-12410: Remove signup types :partner and :partner:*#4308jlledom wants to merge 2 commits into
:partner and :partner:*#4308jlledom wants to merge 2 commits into
Conversation
The :partner and :partner:system_name signup types were redundant variants of :created_by_provider, used only for partner-managed provider accounts. This consolidation simplifies the signup type taxonomy by eliminating the unused User::SignupType#partner? predicate and the Partner#signup_type method that generated the dynamic :partner:system_name variants. Partner users now use :created_by_provider consistently, which accurately reflects that these users are created programmatically via the Partners API rather than through self-signup. The behavior change is minimal: password validation for users without open_id now skips as expected for :created_by_provider (restoring the original pre-validation-tightening behavior where partner users could be created without passwords and would use password reset to log in). Existing :partner DB records are left as-is and continue to work, since the only behavioral difference (password validation) applies only to new_record? checks and thus does not affect persisted records. Assisted-by: Claude Code
Update all tests to reflect the consolidation of :partner signup types into :created_by_provider. This includes removing obsolete tests for the deleted partner? predicate and Partner#signup_type method, updating assertions to expect :created_by_provider instead of :partner:system_name, and fixing password validation tests to reflect the restored behavior where partner users without open_id can be created without passwords (requiring password reset to log in). The test updates also add comprehensive coverage for the :created_by_provider signup type behavior, verifying that machine? returns true and by_user? returns false as expected for programmatically-created users. Assisted-by: Claude Code
❌ 1 blocking issue (1 total)
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
In order to get rid of signup types and simplify signup codebase, the current branch removes the partner signup types and replaces them by the
:created_by_providertype. From now on, partner users are considered regular:created by providerusers.Similar to what happened with #4293, the
:partner*signup types are in fact just a variant of:created_by_provider, so the only reason to justify their existence is to keep them for data or analytics purposes. I don't know of any scenario where customers would need such analytics so I don't think:partnersignup types are justified.After removing the partner types, the only behavioral change happens when creating a new partner user: Previously it didn't accept creating a user without neither
passwordoropen_id, this PR starts accepting it. If not credentials provided, the new user will have to go through the reset password form in order to get a password. However, this in fact restores the old behavior before #4195.About the existing users with partner signup types, those are not affected, those users already behave like
:created_by_providerbecause the only behavioral difference between:partnerand:created_by_providerare how password is validated for new users. For existing users there is no difference at all between:partnerand:created_by_provider.Which issue(s) this PR fixes
https://redhat.atlassian.net/browse/THREESCALE-12410
Verification steps
Test should pass.