Resolve "It is not possible to force user confirmation from Admin Area if confirmation was expired"
What does this MR do and why?
Related to #212539 (closed)
The problem:
GitLab admins cannot confirm the user from the /admin/users/:username
page, by clicking the Confirm user
button, if the confirmation period of the user has expired. Currently, this is 1 day as per our Devise
settings (User.confirm_within
gives this value)
The solution:
GitLab admins should be able to confirm users even if the confirmation period has expired.
To do this, we are now introducing a method named force_confirm
which is only used in Admin::UsersController#confirm
.
This way, we are isolating the effect of this change to this method alone, and not touching the confirm
method of Devise in any manner.
force_confirm
internally calls confirm
, but it does so only after setting a virtual attribute that would later skip the check : has the confirmation period of this user expired?
. Since this check is skipped whenever admins perform force_confirm
on the user, the confirmation always succeeds, even if the confirmation period of 1 day has actually expired.
Screenshots or screen recordings
These are strongly recommended to assist reviewers and reduce the time to merge your change.
How to set up and validate locally
- Turn
Gitlab::CurrentSettings.send_user_confirmation_email
totrue
- Register as a new user on your GitLab instance, say with username
abcd
- From Rails console, do the following
user = User.find_by_username 'abcd'
user.confirmation_sent_at = 10.days.ago # this is to make sure that the confirmation period has expired
user.save!
- Login as gitlab admin in a different browser, and navigate to
/admin/users/abcd
- Click the
Confirm user
button
Before: The request would be successful, but the user would remain unconfirmed. The Confirm user
button still persists on the page.
After the change: The request would be successful, user would be confirmed and the Confirm user
button goes away.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Merge request reports
Activity
changed milestone to %Backlog
assigned to @manojmj
- A deleted user
added backend label
Reviewer roulette
Changes that require review have been detected!
Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:
Category Reviewer Maintainer backend Sashi Kumar Kumaresan ( @sashi_kumar
) (UTC+5.5, same timezone as@manojmj
)Matthias Käppler ( @mkaeppler
) (UTC+1, 4.5 hours behind@manojmj
)To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.
If needed, you can retry the
danger-review
job that generated this comment.Generated by
Danger @manojmj, please can you answer the question: Should this have a feature flag? to help with code review for the Access group.This nudge was added by this triage-ops policy.
removed [deprecated] Accepting merge requests label
added 107 commits
-
36679b13...b146a7dd - 106 commits from branch
master
- 99973111 - Allow admins to foce confirm emails
-
36679b13...b146a7dd - 106 commits from branch
changed milestone to %14.7
- Resolved by Stan Hu
- Resolved by Rohit Shambhuni
@bdenkovych could you please review?
requested review from @bdenkovych
- Resolved by Stan Hu
- Resolved by Stan Hu
- Resolved by Stan Hu
- Resolved by Bogdan Denkovych
requested review from @rshambhuni
removed review request for @bdenkovych
@bdenkovych
, thanks for approving this merge request.This is the first time the merge request is approved. To ensure full test coverage, a new pipeline has been started.
For more info, please refer to the following links:
@stanhu could you please review?
requested review from @stanhu
- Resolved by Stan Hu
mentioned in commit f893cf2c
marked the checklist item I have evaluated the MR acceptance checklist for this MR. as completed
added workflowstaging-canary label and removed workflowready for development label
added workflowstaging label and removed workflowstaging-canary label
added workflowcanary label and removed workflowstaging label
added workflowproduction label and removed workflowcanary label
mentioned in issue #212539 (closed)
removed review request for @rshambhuni
added releasedcandidate label
added releasedpublished label and removed releasedcandidate label
mentioned in merge request kubitus-project/kubitus-installer!562 (merged)
mentioned in merge request gitlab-com/www-gitlab-com!112458 (merged)