On Tue, Mar 21, 2017 at 9:09 PM, Ayesha Dissanayaka <[email protected]> wrote:
> On Tue, Mar 21, 2017 at 1:34 AM, Omindu Rathnaweera <[email protected]> > wrote: > >> +1 for using HTML mail templates. But do we have to consider mail clients >> which doesn't support HTML ? If so, either the endpoint which accepts the >> confirmation code should work for both GETs and POSTs or we have to use >> a different approach to enter the confirmation code. Ex: a prompt to enter >> the code. >> > > I think we need to support both > > HTML based and non HTML based mail clients. Also password reset page we > should support both GET and POST to cater this (email link and button > submit). > > Also for non html emails, we can change the email template to send the > confirmation code in body or URL, depending on system preference. In that > case page returned from the given link should support both cases as below, > - if confirmation code comes in url as query parameter, validate it and > proceed to reset step. > - otherwise prompt input field for user to fill the confirmation code > that is sent in the email body, validate and proceed to reset step > +1 for this, lets supports both HTML based and non HTML based mail clients. while password reset page can support both GET and POST. > > > On Tue, Mar 21, 2017 at 12:33 PM, Dinali Dabarera <[email protected]> wrote: > >> We are not going to lock the user since we use a random password when >> storing the user in DB and it will be over written by the user password >> update. > > Why do we need a password at all, can't we create a user without a > password? Is there any such restriction? > According to our current database implementation we can not store a user without a password. We need to discuss this in atchitecture level for a new implementation. > > Thanks! > -Ayesha > > I'll move with this edited story including above comments for the implemenation . The edited user story: *Pre-requisites* 1. User must be logged into Admin Portal. 2. User must have the required privilege to add new user. 3. There must be at least one identity store available to add the new user. *Narrative* 1. User chooses to add new user with “email verification and ask password from user” option. 2. User selects a domain/user store from a list of available domains/user store, to which the new user must be added. 3. User enters username. 4. User provides email address of the created user. 5. User finishes user addition. *Acceptance Criteria* 1. An email must be sent to the created user’s email account with a link to update the password. 2. This link should be expired within a given period of time. 3. If the action is successful, then it should be notified in the UI. 4. If the action is unsuccessful, then it should be notified in the UI. 5. If the entered email address is not a valid email address or link is expired, It should be notified in the UI and account should not be created. 6. Finally user should be directed to the user listing page. 7. The created user must be shown in the user listing page. -- *Dinali Rosemin Dabarera* Software Engineer WSO2 Lanka (pvt) Ltd. Web: http://wso2.com/ Email : [email protected] LinkedIn <https://lk.linkedin.com/in/dinalidabarera> Mobile: +94770198933 <https://lk.linkedin.com/in/dinalidabarera>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
