With IS 5.3.0, we have currently provided a Rest API for resending confirmation code (Refer [1]), which supports only for self signup feature. So that, we are planning to provide a more generic REST API and a OSGi service, for resending confirmation code for any scenario.

Following are the scenarios, currently where we are sending confirmation emails in IS.

Password Reset - password recovery using email-based notifications

Account Confirmation - email confirmation on user self registration

Ask Password - ask password from user through confirmation email

Admin Forced Password Reset- admin to trigger a password reset for a given user account

Admin Forced Password Reset With OTP - admin send an email to the user with a one time password that the user can use to login once to the account after which, the user will be prompted to set a new password

Email Confirmation - account confirmation through email notification

In there, the confirmation emails get expired after a configured time period in order to make the accounts secure. After the expiration, we may need to resend the confirmation emails.

So with this implementation, when we request for resending confirmation code, previously issued code (even though, it's still not expired), should get expired and the new confirmation code should considered as active. So that in any scenario, if a user is requesting to use an expired confirmation code, we need to redirect the user, to an error page mentioning of using an expired confirmation link.

In case of user self registration, if request has made for resending confirmation link, after a account activation, I think it should be handled in the self registration API (currently Re-Send button to resend the confirmation link will be appeared in the login page, when we try to login to an unverified account). We may not need to consider it, when resending the confirmation code. WDYT?

Other than that, I think we can consider following scenarios as further improvements. WDYT?

In case of a forgery, we may need to expire the confirmation link, manually before the configured time (without resending the confirmation link).

Currently for resending confirmation email for user self registration, we have provided support in the login page where user can request to resend confirmation link (We have not added this to the documentation, created a doc jira in [2]). In order to resend the confirmation emails from admin (or user with a required permissions), we can provide support in management console to :

select the user(s) to whom need to resend the activation email

select a role, to send confirmation emails to a group of users - here we may need to automatically skip over users who have already activated there accounts in case of self registration

With IS 5.3.0, we have currently provided a Rest API for resending confirmation code (Refer [1]), which supports only for self signup feature. So that, we are planning to provide a more generic REST API and a OSGi service, for resending confirmation code for any scenario.

Following are the scenarios, currently where we are sending confirmation emails in IS.

Password Reset - password recovery using email-based notifications

Account Confirmation - email confirmation on user self registration

Ask Password - ask password from user through confirmation email

Admin Forced Password Reset- admin to trigger a password reset for a given user account

Admin Forced Password Reset With OTP - admin send an email to the user with a one time password that the user can use to login once to the account after which, the user will be prompted to set a new password

Email Confirmation - account confirmation through email notification

In there, the confirmation emails get expired after a configured time period in order to make the accounts secure. After the expiration, we may need to resend the confirmation emails.

So with this implementation, when we request for resending confirmation code, previously issued code (even though, it's still not expired), should get expired and the new confirmation code should considered as active. So that in any scenario, if a user is requesting to use an expired confirmation code, we need to redirect the user, to an error page mentioning of using an expired confirmation link.

In case of user self registration, if request has made for resending confirmation link, after a account activation, I think it should be handled in the self registration API (currently Re-Send button to resend the confirmation link will be appeared in the login page, when we try to login to an unverified account). We may not need to consider it, when resending the confirmation code. WDYT?

So, generally, when resendingm it should verify the user email address isn't that the case case here? genreally, you will not re-send confirmation code for unverified accounts

Other than that, I think we can consider following scenarios as further improvements. WDYT?

In case of a forgery, we may need to expire the confirmation link, manually before the configured time (without resending the confirmation link).

How to filter out the facts? you mean managing UI per inactive confirmation links? then selectivly disabling? Anyway, yeah this looks to be a good initiate to have anyway.

Currently for resending confirmation email for user self registration, we have provided support in the login page where user can request to resend confirmation link (We have not added this to the documentation, created a doc jira in [2]). In order to resend the confirmation emails from admin (or user with a required permissions), we can provide support in management console to :

+1

select the user(s) to whom need to resend the activation email

users/s how many users at once? don't you think it may get complicate when user store is large and if the selection get larger

select a role, to send confirmation emails to a group of users - here we may need to automatically skip over users who have already activated there accounts in case of self registration

would appropriate to send email to a user group rather a indvidual IMO or may be users who are in certain group as you have specified, that may more praticle (I'm thinking larger user store)

With IS 5.3.0, we have currently provided a Rest API for resending confirmation code (Refer [1]), which supports only for self signup feature. So that, we are planning to provide a more generic REST API and a OSGi service, for resending confirmation code for any scenario.

Following are the scenarios, currently where we are sending confirmation emails in IS.

Password Reset - password recovery using email-based notifications

Account Confirmation - email confirmation on user self registration

Ask Password - ask password from user through confirmation email

Admin Forced Password Reset- admin to trigger a password reset for a given user account

Admin Forced Password Reset With OTP - admin send an email to the user with a one time password that the user can use to login once to the account after which, the user will be prompted to set a new password

Email Confirmation - account confirmation through email notification

IMO it is not required to have an option to resend the confirmation codes for following scenarios.

Password Reset

Admin Force Password Reset

Admin Force Password Reset with OTP

There is no intermediate step between sending confirmation and validating confirmation in mentioned scenarios. So, instead of resending the code, users can start a new flow again. (Ex. Try another attempt to reset password )

BTW, it is good to have a generic API to resend the confirmation codes.

In there, the confirmation emails get expired after a configured time period in order to make the accounts secure. After the expiration, we may need to resend the confirmation emails.

So with this implementation, when we request for resending confirmation code, previously issued code (even though, it's still not expired), should get expired and the new confirmation code should considered as active. So that in any scenario, if a user is requesting to use an expired confirmation code, we need to redirect the user, to an error page mentioning of using an expired confirmation link.

In case of user self registration, if request has made for resending confirmation link, after a account activation, I think it should be handled in the self registration API (currently Re-Send button to resend the confirmation link will be appeared in the login page, when we try to login to an unverified account). We may not need to consider it, when resending the confirmation code. WDYT?

Other than that, I think we can consider following scenarios as further improvements. WDYT?

In case of a forgery, we may need to expire the confirmation link, manually before the configured time (without resending the confirmation link).

+1. Please create a improvement Jira to track this.

Currently for resending confirmation email for user self registration, we have provided support in the login page where user can request to resend confirmation link (We have not added this to the documentation, created a doc jira in [2]). In order to resend the confirmation emails from admin (or user with a required permissions), we can provide support in management console to :

select the user(s) to whom need to resend the activation email

select a role, to send confirmation emails to a group of users - here we may need to automatically skip over users who have already activated there accounts in case of self registration

I have a general comment on this. Are we not planning to support this in the UI at least in the public release? Because planning for backend only IMO is not a good idea from previous experience because it will remain at the same state for years. Don't want to go back there. And from a capabilities POV it won't be considered as OOTB capabilities of the product, which makes it hard to sell :).

With IS 5.3.0, we have currently provided a Rest API for resending confirmation code (Refer [1]), which supports only for self signup feature. So that, we are planning to provide a more generic REST API and a OSGi service, for resending confirmation code for any scenario.

Following are the scenarios, currently where we are sending confirmation emails in IS.

Password Reset - password recovery using email-based notifications

Account Confirmation - email confirmation on user self registration

Ask Password - ask password from user through confirmation email

Admin Forced Password Reset- admin to trigger a password reset for a given user account

Admin Forced Password Reset With OTP - admin send an email to the user with a one time password that the user can use to login once to the account after which, the user will be prompted to set a new password

Email Confirmation - account confirmation through email notification

IMO it is not required to have an option to resend the confirmation codes for following scenarios.

Password Reset

Admin Force Password Reset

Admin Force Password Reset with OTP

There is no intermediate step between sending confirmation and validating confirmation in mentioned scenarios. So, instead of resending the code, users can start a new flow again. (Ex. Try another attempt to reset password )

BTW, it is good to have a generic API to resend the confirmation codes.

Yes. Please carefully consider the scenarios where "resending" is absolutely necessary. Wherever we can "restart" the process we don't need to "resend".

We can have two types of emails as far as I understand; emails with confirmation codes for verification and emails with just text for notification. Please consider these two kind of mails also when designing. Are we planning to support "resend" for emails for just notifications? E.g. user account disable?

In there, the confirmation emails get expired after a configured time period in order to make the accounts secure. After the expiration, we may need to resend the confirmation emails.

So with this implementation, when we request for resending confirmation code, previously issued code (even though, it's still not expired), should get expired and the new confirmation code should considered as active. So that in any scenario, if a user is requesting to use an expired confirmation code, we need to redirect the user, to an error page mentioning of using an expired confirmation link.

In case of user self registration, if request has made for resending confirmation link, after a account activation, I think it should be handled in the self registration API (currently Re-Send button to resend the confirmation link will be appeared in the login page, when we try to login to an unverified account). We may not need to consider it, when resending the confirmation code. WDYT?

I am not sure I understood the differences in the scenarios you are explaining well. Can you explain in a different way?

Other than that, I think we can consider following scenarios as further improvements. WDYT?

In case of a forgery, we may need to expire the confirmation link, manually before the configured time (without resending the confirmation link).

+1. Please create a improvement Jira to track this.

Currently for resending confirmation email for user self registration, we have provided support in the login page where user can request to resend confirmation link (We have not added this to the documentation, created a doc jira in [2]). In order to resend the confirmation emails from admin (or user with a required permissions), we can provide support in management console to :

select the user(s) to whom need to resend the activation email

select a role, to send confirmation emails to a group of users - here we may need to automatically skip over users who have already activated there accounts in case of self registration

+1 to consider resending to a group of users if we feel it's useful.

Can we introduce a new role that contains all the users to whom emails have been sent and confirmation pending? And may be another role to contain all the users who have confirmed? Otherwise there is no way to easily retrieve the list of users who are pending confirmation or already confirmed. @Maduranga implemented a similar use case for a customer recently. Please discuss with him and see how he did it.

With IS 5.3.0, we have currently provided a Rest API for resending confirmation code (Refer [1]), which supports only for self signup feature. So that, we are planning to provide a more generic REST API and a OSGi service, for resending confirmation code for any scenario.

Following are the scenarios, currently where we are sending confirmation emails in IS.

Password Reset - password recovery using email-based notifications

Account Confirmation - email confirmation on user self registration

Ask Password - ask password from user through confirmation email

Admin Forced Password Reset- admin to trigger a password reset for a given user account

Admin Forced Password Reset With OTP - admin send an email to the user with a one time password that the user can use to login once to the account after which, the user will be prompted to set a new password

Email Confirmation - account confirmation through email notification

IMO it is not required to have an option to resend the confirmation codes for following scenarios.

Password Reset

Admin Force Password Reset

Admin Force Password Reset with OTP

There is no intermediate step between sending confirmation and validating confirmation in mentioned scenarios. So, instead of resending the code, users can start a new flow again. (Ex. Try another attempt to reset password )

BTW, it is good to have a generic API to resend the confirmation codes.

+1, I also think no need re send the code if user can retry the scenarios.

In there, the confirmation emails get expired after a configured time period in order to make the accounts secure. After the expiration, we may need to resend the confirmation emails.

So with this implementation, when we request for resending confirmation code, previously issued code (even though, it's still not expired), should get expired and the new confirmation code should considered as active. So that in any scenario, if a user is requesting to use an expired confirmation code, we need to redirect the user, to an error page mentioning of using an expired confirmation link.

In case of user self registration, if request has made for resending confirmation link, after a account activation, I think it should be handled in the self registration API (currently Re-Send button to resend the confirmation link will be appeared in the login page, when we try to login to an unverified account). We may not need to consider it, when resending the confirmation code. WDYT?

Other than that, I think we can consider following scenarios as further improvements. WDYT?

In case of a forgery, we may need to expire the confirmation link, manually before the configured time (without resending the confirmation link).

In this scenarios how do we going to identify the incident and who will going to revoke the conformation code.

+1. Please create a improvement Jira to track this.

Currently for resending confirmation email for user self registration, we have provided support in the login page where user can request to resend confirmation link (We have not added this to the documentation, created a doc jira in [2]). In order to resend the confirmation emails from admin (or user with a required permissions), we can provide support in management console to :

select the user(s) to whom need to resend the activation email

select a role, to send confirmation emails to a group of users - here we may need to automatically skip over users who have already activated there accounts in case of self registration

Thanks

Isura.

Appreciate your ideas and comments on this.

This is open ended feature. shall we break down the tasks, So it whould be easy for you to start.

I have a general comment on this. Are we not planning to support this in the UI at least in the public release? Because planning for backend only IMO is not a good idea from previous experience because it will remain at the same state for years. Don't want to go back there. And from a capabilities POV it won't be considered as OOTB capabilities of the product, which makes it hard to sell :).

AFAIU, you have mentioned about providing UI support for resending confirmation emails?

I think we should consider the UI validations in account recovery endpoint, when a previously issued confirmation link is used, as I have mentioned previously (ex: when someone use a previously issued confirmation link for reset password, user should redirect to an error page, without redirect to the password reset page). WDYT?

With IS 5.3.0, we have currently provided a Rest API for resending confirmation code (Refer [1]), which supports only for self signup feature. So that, we are planning to provide a more generic REST API and a OSGi service, for resending confirmation code for any scenario.

Following are the scenarios, currently where we are sending confirmation emails in IS.

Password Reset - password recovery using email-based notifications

Account Confirmation - email confirmation on user self registration

Ask Password - ask password from user through confirmation email

Admin Forced Password Reset- admin to trigger a password reset for a given user account

Admin Forced Password Reset With OTP - admin send an email to the user with a one time password that the user can use to login once to the account after which, the user will be prompted to set a new password

Email Confirmation - account confirmation through email notification

IMO it is not required to have an option to resend the confirmation codes for following scenarios.

Password Reset

Admin Force Password Reset

Admin Force Password Reset with OTP

There is no intermediate step between sending confirmation and validating confirmation in mentioned scenarios. So, instead of resending the code, users can start a new flow again. (Ex. Try another attempt to reset password )

BTW, it is good to have a generic API to resend the confirmation codes.

Yes. Please carefully consider the scenarios where "resending" is absolutely necessary. Wherever we can "restart" the process we don't need to "resend".

Yes. Planning to cover only the necessary scenarios from the above list.

We can have two types of emails as far as I understand; emails with confirmation codes for verification and emails with just text for notification. Please consider these two kind of mails also when designing. Are we planning to support "resend" for emails for just notifications? E.g. user account disable?

I think it's not needed to resend emails with just text notifications. Or you are considering implementation of a generic API for notification sending in recovery scenarios rather than API for notification resending?

In there, the confirmation emails get expired after a configured time period in order to make the accounts secure. After the expiration, we may need to resend the confirmation emails.

So with this implementation, when we request for resending confirmation code, previously issued code (even though, it's still not expired), should get expired and the new confirmation code should considered as active. So that in any scenario, if a user is requesting to use an expired confirmation code, we need to redirect the user, to an error page mentioning of using an expired confirmation link.

In case of user self registration, if request has made for resending confirmation link, after a account activation, I think it should be handled in the self registration API (currently Re-Send button to resend the confirmation link will be appeared in the login page, when we try to login to an unverified account). We may not need to consider it, when resending the confirmation code. WDYT?

I am not sure I understood the differences in the scenarios you are explaining well. Can you explain in a different way?

My concern was, when we resending a confirmation email for self registration, in the back-end REST API, we need to validate whether the account have been activated or not? Or we can provide a UI validation as currently in the login page (Re-Send button to resend the confirmation link will be appeared in the login page, if only account is not activated)?

Other than that, I think we can consider following scenarios as further improvements. WDYT?

In case of a forgery, we may need to expire the confirmation link, manually before the configured time (without resending the confirmation link).

+1. Please create a improvement Jira to track this.

Currently for resending confirmation email for user self registration, we have provided support in the login page where user can request to resend confirmation link (We have not added this to the documentation, created a doc jira in [2]). In order to resend the confirmation emails from admin (or user with a required permissions), we can provide support in management console to :

select the user(s) to whom need to resend the activation email

select a role, to send confirmation emails to a group of users - here we may need to automatically skip over users who have already activated there accounts in case of self registration

+1 to consider resending to a group of users if we feel it's useful.

Can we introduce a new role that contains all the users to whom emails have been sent and confirmation pending? And may be another role to contain all the users who have confirmed? Otherwise there is no way to easily retrieve the list of users who are pending confirmation or already confirmed. @Maduranga implemented a similar use case for a customer recently. Please discuss with him and see how he did it.

Thanks all for your valuable feedbacks, it will be helpful to improve this in future.

In the design discussion (Refer [1]), it's concluded that to implement a generic OSGI service for resending
confirmation code in account recovery scenarios and self registration and to consider other improvements in next IS release. The OSGI service has been implemented with [2] and other improvements will be tracking with [3].

I have a general comment on this. Are we not planning to support this in the UI at least in the public release? Because planning for backend only IMO is not a good idea from previous experience because it will remain at the same state for years. Don't want to go back there. And from a capabilities POV it won't be considered as OOTB capabilities of the product, which makes it hard to sell :).

AFAIU, you have mentioned about providing UI support for resending confirmation emails?

I think we should consider the UI validations in account recovery endpoint, when a previously issued confirmation link is used, as I have mentioned previously (ex: when someone use a previously issued confirmation link for reset password, user should redirect to an error page, without redirect to the password reset page). WDYT?

With IS 5.3.0, we have currently provided a Rest API for resending confirmation code (Refer [1]), which supports only for self signup feature. So that, we are planning to provide a more generic REST API and a OSGi service, for resending confirmation code for any scenario.

Following are the scenarios, currently where we are sending confirmation emails in IS.

Password Reset - password recovery using email-based notifications

Account Confirmation - email confirmation on user self registration

Ask Password - ask password from user through confirmation email

Admin Forced Password Reset- admin to trigger a password reset for a given user account

Admin Forced Password Reset With OTP - admin send an email to the user with a one time password that the user can use to login once to the account after which, the user will be prompted to set a new password

Email Confirmation - account confirmation through email notification

IMO it is not required to have an option to resend the confirmation codes for following scenarios.

Password Reset

Admin Force Password Reset

Admin Force Password Reset with OTP

There is no intermediate step between sending confirmation and validating confirmation in mentioned scenarios. So, instead of resending the code, users can start a new flow again. (Ex. Try another attempt to reset password )

BTW, it is good to have a generic API to resend the confirmation codes.

Yes. Please carefully consider the scenarios where "resending" is absolutely necessary. Wherever we can "restart" the process we don't need to "resend".

Yes. Planning to cover only the necessary scenarios from the above list.

We can have two types of emails as far as I understand; emails with confirmation codes for verification and emails with just text for notification. Please consider these two kind of mails also when designing. Are we planning to support "resend" for emails for just notifications? E.g. user account disable?

I think it's not needed to resend emails with just text notifications. Or you are considering implementation of a generic API for notification sending in recovery scenarios rather than API for notification resending?

In there, the confirmation emails get expired after a configured time period in order to make the accounts secure. After the expiration, we may need to resend the confirmation emails.

So with this implementation, when we request for resending confirmation code, previously issued code (even though, it's still not expired), should get expired and the new confirmation code should considered as active. So that in any scenario, if a user is requesting to use an expired confirmation code, we need to redirect the user, to an error page mentioning of using an expired confirmation link.

In case of user self registration, if request has made for resending confirmation link, after a account activation, I think it should be handled in the self registration API (currently Re-Send button to resend the confirmation link will be appeared in the login page, when we try to login to an unverified account). We may not need to consider it, when resending the confirmation code. WDYT?

I am not sure I understood the differences in the scenarios you are explaining well. Can you explain in a different way?

My concern was, when we resending a confirmation email for self registration, in the back-end REST API, we need to validate whether the account have been activated or not? Or we can provide a UI validation as currently in the login page (Re-Send button to resend the confirmation link will be appeared in the login page, if only account is not activated)?

Other than that, I think we can consider following scenarios as further improvements. WDYT?

In case of a forgery, we may need to expire the confirmation link, manually before the configured time (without resending the confirmation link).

+1. Please create a improvement Jira to track this.

Currently for resending confirmation email for user self registration, we have provided support in the login page where user can request to resend confirmation link (We have not added this to the documentation, created a doc jira in [2]). In order to resend the confirmation emails from admin (or user with a required permissions), we can provide support in management console to :

select the user(s) to whom need to resend the activation email

select a role, to send confirmation emails to a group of users - here we may need to automatically skip over users who have already activated there accounts in case of self registration

+1 to consider resending to a group of users if we feel it's useful.

Can we introduce a new role that contains all the users to whom emails have been sent and confirmation pending? And may be another role to contain all the users who have confirmed? Otherwise there is no way to easily retrieve the list of users who are pending confirmation or already confirmed. @Maduranga implemented a similar use case for a customer recently. Please discuss with him and see how he did it.

We need to also enforce captcha on the self signup Rest API (following the same pattern implemented for other Rest APIs), because the self signup API only has application level authentication and users who can access the application (by default "authenticationendpoint") are able carry out a bot attack.

Thanks all for your valuable feedbacks, it will be helpful to improve this in future.

In the design discussion (Refer [1]), it's concluded that to implement a generic OSGI service for resending
confirmation code in account recovery scenarios and self registration and to consider other improvements in next IS release. The OSGI service has been implemented with [2] and other improvements will be tracking with [3].

I have a general comment on this. Are we not planning to support this in the UI at least in the public release? Because planning for backend only IMO is not a good idea from previous experience because it will remain at the same state for years. Don't want to go back there. And from a capabilities POV it won't be considered as OOTB capabilities of the product, which makes it hard to sell :).

AFAIU, you have mentioned about providing UI support for resending confirmation emails?

I think we should consider the UI validations in account recovery endpoint, when a previously issued confirmation link is used, as I have mentioned previously (ex: when someone use a previously issued confirmation link for reset password, user should redirect to an error page, without redirect to the password reset page). WDYT?

With IS 5.3.0, we have currently provided a Rest API for resending confirmation code (Refer [1]), which supports only for self signup feature. So that, we are planning to provide a more generic REST API and a OSGi service, for resending confirmation code for any scenario.

Following are the scenarios, currently where we are sending confirmation emails in IS.

Password Reset - password recovery using email-based notifications

Account Confirmation - email confirmation on user self registration

Ask Password - ask password from user through confirmation email

Admin Forced Password Reset- admin to trigger a password reset for a given user account

Admin Forced Password Reset With OTP - admin send an email to the user with a one time password that the user can use to login once to the account after which, the user will be prompted to set a new password

Email Confirmation - account confirmation through email notification

IMO it is not required to have an option to resend the confirmation codes for following scenarios.

Password Reset

Admin Force Password Reset

Admin Force Password Reset with OTP

There is no intermediate step between sending confirmation and validating confirmation in mentioned scenarios. So, instead of resending the code, users can start a new flow again. (Ex. Try another attempt to reset password )

BTW, it is good to have a generic API to resend the confirmation codes.

Yes. Please carefully consider the scenarios where "resending" is absolutely necessary. Wherever we can "restart" the process we don't need to "resend".

Yes. Planning to cover only the necessary scenarios from the above list.

We can have two types of emails as far as I understand; emails with confirmation codes for verification and emails with just text for notification. Please consider these two kind of mails also when designing. Are we planning to support "resend" for emails for just notifications? E.g. user account disable?

I think it's not needed to resend emails with just text notifications. Or you are considering implementation of a generic API for notification sending in recovery scenarios rather than API for notification resending?

In there, the confirmation emails get expired after a configured time period in order to make the accounts secure. After the expiration, we may need to resend the confirmation emails.

So with this implementation, when we request for resending confirmation code, previously issued code (even though, it's still not expired), should get expired and the new confirmation code should considered as active. So that in any scenario, if a user is requesting to use an expired confirmation code, we need to redirect the user, to an error page mentioning of using an expired confirmation link.

In case of user self registration, if request has made for resending confirmation link, after a account activation, I think it should be handled in the self registration API (currently Re-Send button to resend the confirmation link will be appeared in the login page, when we try to login to an unverified account). We may not need to consider it, when resending the confirmation code. WDYT?

I am not sure I understood the differences in the scenarios you are explaining well. Can you explain in a different way?

My concern was, when we resending a confirmation email for self registration, in the back-end REST API, we need to validate whether the account have been activated or not? Or we can provide a UI validation as currently in the login page (Re-Send button to resend the confirmation link will be appeared in the login page, if only account is not activated)?

Other than that, I think we can consider following scenarios as further improvements. WDYT?

In case of a forgery, we may need to expire the confirmation link, manually before the configured time (without resending the confirmation link).

+1. Please create a improvement Jira to track this.

Currently for resending confirmation email for user self registration, we have provided support in the login page where user can request to resend confirmation link (We have not added this to the documentation, created a doc jira in [2]). In order to resend the confirmation emails from admin (or user with a required permissions), we can provide support in management console to :

select the user(s) to whom need to resend the activation email

select a role, to send confirmation emails to a group of users - here we may need to automatically skip over users who have already activated there accounts in case of self registration

+1 to consider resending to a group of users if we feel it's useful.

Can we introduce a new role that contains all the users to whom emails have been sent and confirmation pending? And may be another role to contain all the users who have confirmed? Otherwise there is no way to easily retrieve the list of users who are pending confirmation or already confirmed. @Maduranga implemented a similar use case for a customer recently. Please discuss with him and see how he did it.