UserManagement overview #111
Description
UserManagement is how users can be more interactive with the site and allow future growth of editing, submissions, etc.
create a service to create and update users
registration page - unique value is email - contain email - the verification link will ask for a password.
create will send an email to the user with a link to verify - this link will contain a GUID - use the UUID from Java to do this.
that registration UUID will not expire. Once the UUID has been used by a registrant the UUID will be marked inactive.
Registration - email, UUID, active, date created, date completed
when registration is completed the user will be redirected to the profile page
user profile page - display all items for a user from registration and additional items like username, real name, email, facebook link, twitter link, youtube link, etc
a way to change password (validate both fields are the same before allowing the change in the database
all new registrations will get a "member" role
UserRole - role - can be admin, member admin, editor, member - where member admin is someone that can set active or inactive for users, editors can submit entries to be approved, or approve other entries, members can just use the site and save preferences, admins are those that have full control over the system
admins have access to every page on the site, members have access to the public-facing pages, member admin has access to the member admin page (which will need to be created to view and edit users - no access to passwords - but set a user inactive or active or fix an email address for login), editors have access to public-facing pages and the editing pages (eventually, members will be able to submit changes and editors can approve or deny requests)
reset password link - creates a GUID that can be passed from an email to the reset password page. this guid will do the lookup and the user can change their password. GUID should have an expiration date in the database - so if the lookup of the GUID and the time are passed then it'll give an error message. once that happens or the GUID has been used then that record in the database will be marked inactive. any requests for invalid GUIDs should display a generic error message
User created list - set permissions to public, private, unlisted. public = no check for a user logged in. if we later allow users to be looked up or browsed for or a user shares their profile with someone else then these lists are unrestricted. private = check to see if the user is logged in and the list belongs to that user - if not display an error message. unlisted = will not display on a user profile page if it's not the user viewing their profile - can be accessed without checking to see if the accessor is logged in.
if someone attempts to get to a private list and isn't logged in then they should be sent to a login page with a message that reads something like "please login to view this list" then allow a login and once logged in redirect back to that list if they have permissions to view it otherwise send them to the page but don't display the list just display an error message that reads "you don't have permissions to view this list" or something similar
future oauth for google and facebook logins
As well, eventually, every entry on the site will be able to be added to a list - by entry I mean any word in the dictionary individually with a link to the dictionary entry. This would include verb conjugation entries as well.
I can put together a flow of how pages should work if that makes it easier.