-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[5.3] Registering new user account: email address verification does not change admin view #45063
Comments
regarding changing activated to verified |
«regarding changing activated to verified, that only makes sense if you have a verification step in the user registration.» In case «New User Account Activation» is set to «Administrator», verified seems to be preferable. |
hi im interested in working in this issue, can i start resolving this? |
@brianteeman @crimle , I’ve been analyzing this issue and want to confirm my understanding before proceeding further , The Block state (in DB ) determines whether a user can log in (0 = can login, 1 = cant ). |
hi , just want to clarify one more thing , like would it better to show activated with green tick once email is verifed by user , no matter if admin approves respective user or not ? Would be happy to know opinions please |
hi , just want to clarify one more thing , like would it better to show activated with green tick once email is verifed by user , no matter if admin approves respective user or not ? Would be happy to know opinions please This is exactly my opinion how it should be done. And that's why I am suggesting to rename some terms: |
@crimle , Yes sir , that makes sense. Currently, the green tick appears after email verification only when the New User Account Activation option is set to Self. However, if it's set to Admin, the activation status remains pending until the administrator approves the user. Displaying the green tick immediately after self email verification (without tying it to admin approval) would indeed be a more intuitive approach. Since the Block status already reflects whether an admin has approved or restricted the user, this change would help differentiate between email verification and administrative approval more clearly. @crimle , would it be better to add this refinement to the existing issue? Since it’s closely related to activation behavior, I can work on it.. Looking forward to your thoughts sir! |
@Amitesh007z I completely agree with you as far as the «email verification» green tick is concerned. I would be happy to see this refinement at any time. I do not know how much work this will be causing. What do you think of my suggestions regarding renaming some labellings? Activated: replace by Verified From my point of language understanding «block» is pretty harsh, implying that the user has violated any guidelines or rules. «Enabled» oder «Disabled» is more neutral and describes exactly what is going on, without implying anything. Thank you very much for your commitment. |
Hi sir , Thank you so much for your feedback and insights! I completely agree with implementing the email verification refinement so that the green tick appears once the user verifies their email, independent of admin approval. This would make the process clearer and align well with how verification should work. I’d be happy to work on this change! Regarding your label renaming suggestions, I also think that using "Enable/Disable" instead of "Block/Unblock" provides a more neutral and user-friendly experience. Your suggestions make a lot of sense, and I'd be glad to implement them. To keep things structured, I propose working on these improvements too : Email verification refinement (showing the green tick after self-verification). Would you like me to go ahead and create a new issue for this? Let me know your thoughts, and I’d be happy to proceed accordingly. Thanks again for your guidance sir! |
Yes, please go ahead. We seem to have an absolutely identical opinion. I will be happy to be one of the first testing persons. |
Yeah sure sir , Will get the issue sorted soon and let you know , |
Hi @Amitesh007z thank you for your contributions. Next thing would be a Pull Request or two. May be you want to split it up in 2 PR's one for language changes (in the backend and the sent emails) and another one logic changes. It is important you understand the whole registration process and the options in the registration process. |
Hi @MacJoom , thank you for your guidance. I will create two separate PRs—one for the language changes (in the backend and emails) and another for the logic updates to address the issue effectively. While going through the codebase, I also gained a clearer understanding of the complete registration process. I'll proceed accordingly. |
@crimle @MacJoom, I have a few clarifications regarding the activation process sir. Would you like the activation to be entirely self-managed, where the user's verification via email directly results in a green tick in the admin panel? Currently, we have a setting that allows activation to be either self or admin-controlled.Admin controlled goes through admin approval . Could you confirm which approach we should follow, go completely without admin approval in any case? I understand that we intend to make email verification independent of admin approval since the block field remains under the admin's control. Please let me know your thoughts on this sir . |
do NOT change the activation process!!! That will not be accepted |
Hey @brianteeman , following up on my previous discussions with @MacJoom and @crimle. They had asked me on enabling activation when user verifies mail. How should I proceed from here? Would appreciate your guidance |
@MacJoom said nothing at all about that |
My apologies for any confusion. I was following advice from @crimle, but I may have misunderstood the revised issue in discussion . I'd appreciate to knowh on which way to proceed further for this issue ? or to follow same which was asked to sort at start of issue |
We don't want the registration process to be changed in any way. The thing that appears not consistent to me is that when the administrator clicks on the link in his mail to approve a user that has confirmed his mail he ends up in the backend and has both Enabled and Activated with the green hook. If the administrator goes manually in the backend, the Activated (e.g. Verified) hook is not there. And when the administrator clicks on the 'Unblock' link, Activated will not be set. That means inconsistent with the Link behavior. |
oh well , I get the issue now—it’s different from what I was focusing on before. When an admin approves via the email link, both "Enabled" and "Activated" turn green, but if they manually unblock the user in the backend, only "Enabled" updates while "Activated" stays unchanged.The behavior should be consistent in both cases. |
before you can even look at "fixing" anything you need to understand what each user registration option does (i dont know) and only then are you in a position to change/fix/improve anything. Simply going in and removing core functionality is not a fix remember any change that you will make is not just on a single web site. that change will be made on millions of web sites |
I would start by documenting (perhaps in a table) the state of the two fields at each stage of the registration and approval process for ALL the possible registration and approval methods |
I apologize for the confusion @MacJoom @brianteeman . You're right that any modifications impact millions of websites, and I commit to a more careful, informed approach before proposing changes.yeah initally i made set of fields like table to check state of two field in all three conditions too, , got complete grasp and expected end result on isuue, will sort it soon sir |
Steps to reproduce the issue
Expected result
Actual result
System information (as much as possible)
Joomla 5.3.0-beta1
PHP Version 8.3.16
Additional comments
From my point of view, some terms here are used inaccurately and could be misleading. I suggest the following:
Activated: replace by Verified
Activate: replace by Verify
Block: replace by Disable
Unblock: replace by Enable
You can't block yourself: replace by You can't disable yourself
Filter Options:
Select Active State: replace by Select Verification State
Activated: replace by Verified
Unactivated: replace by Unverified
The text was updated successfully, but these errors were encountered: