regarding changing activated to verified
that only makes sense if you have a verification step in the user registration.

«regarding changing activated to verified, that only makes sense if you have a verification step in the user registration.»
If we are utterly exact, you are right. But on the other hand, «activation» only makes sense if you have an activation step in the user registration. Depending on the setting «New User Account Activation» either activated or verified is more precise.

In case «New User Account Activation» is set to «Administrator», verified seems to be preferable.
In case «New User Account Activation» is set to «User», verified is not wrong, since the user self activation process consists of two steps:
1 verification of the email address
2 activating the account by changing the state to «enabled»

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 ).
The Activated status currently appears as a tick (✓) regardless of whether the user has completed email verification.
The issue seems to be that Joomla marks users as "Activated" without checking if they’ve verified their email.

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:
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

@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
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

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.

@crimle

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).
Label renaming improvements (making the terms clearer).

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 ,
Thanks sir

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

The Summary of Changes looks very structured and clear. Compliments and many thanks for this. Not all PRs are so well documented, which makes it often difficult for testers to get the perspective.

I am the person who originally reported this issue. But I am afraid, my request was somewhat misunderstood. My concern is NOT about the manual addition of users by the administrator. I wanted to discuss whether the user registration process should be improved in case the option ‘New User Account Activation’ is set to ’Administrator’.

IS

• A user registers for a new account
• He clicks the verification link in the email he receives
• This action does not change the state of the two icons, neither «Enabled» nor «Activated». Literally speaking this is correct, since the user only has verified his email address, but not activated his account. Keep in mind that the option ‘New User Account Activation’ is set to ’Administrator’.

MY PROPOSAL

• A user registers for a new account
• He clicks the verification link in the email he receives
• This action should change the state of the second of these icons. This allows the administrator to determine that the account has been verified. Otherwise he would have to guess the verification status from the fact, that he has received a notification email from the new user account.
• My proposal would make it necessary that the column's heading is renamed from «Activated» to «Verified».

Summarising I would think, that my propsal would make the whole user registration and approval process more transparent and clear then it was until now.

BY NO MEANS is it necessary, to completely rewrite this function from the scratch. It basically works, but could be clarified a little bit.