Seti:UsersModel
From Wikiturbine
TIER 2 MODEL
Contents |
[edit] Description
Core Tier 2 module that should by the end handle user accounts, profiles, privacy options, sessions, and authentication (to some extent).
[edit] Abstract Model
This section is designed for planning model functionality. The code implementation of this abstraction is listed in the CakePHP portion of this page.
[edit] Variables
Variables should have type, name and short description.
Example: string name - object's name
- int id - user's primary key, as per usual
- string nick - nickname, we could debate that it's different from the IRC nick (which could be changed), or keep it same
- string email - primary email
- string firstname - real 1st name
- string lastname - real last name
- int date_registered - UNIX timestamp given upon registration
- int last_seen - UNIX timestamp for last login
- string location - geographical location: City, State/Province, Country
- (?) group - this is for the ACL, basically some form of ARO ident. We probably only have visitors, users and admins.
- int dob - date of birth, we can debate this somehow
- string website - location of person's site, do we want to make this an array?
- boolean online - if the person is online with a corresponding IRC nick (identified), this will be true. also true if they are logged into the private system. might be useless
- string ircnick - somehow keep track of this?
- string profile_img - local or remote location of profile pic, we might want another variable or 2 for thumbnails
- int array privacy_settings - unless we want to keep a separate model for this (which we might) or a better way to do this (which might be a good idea as well), this array will keep the privacy settings for every user. we will name a key after most variables above and point it an int that stands for various forms of privacy (0-public, 1-network, 2-hidden)
More variables and links to other models to follow?
[edit] Methods
Actions we would like to perform with and on this model (this includes MVC's views and controllers together).
We want to be able to do a few things with this model, as well as allow it access/be accessed by other models or model controllers and views. Security and privacy are top priority.
- registration - This might look like a multi step process that might involve several controllers
- invitation sender - Accessible only to the admin ARO. Admin can enter someone's email address and name, perhaps fill in some other variables from the list above. The form gets processed by adding the person to some queue and sending an email. The e-mail contains a link to the next process
- registration processor - When the invitee opens the link to the email, they will be asked whether they want to join or not. Getting over that hump, they can fill out the form which will take care of all the variables and privacy settings. I am not sure how openID works, but this is the step where we will accept it. On submission, they will be added to the db, be asked if they want to be emailed about the registration, and be redirected to the home view.
- login view - when there is no ARO or session present
- logout view - destroys session info
- single profile view - this takes privacy settings and ARO permissions into account
- home view - welcome greeting, profile pic, links to editing settings and links to w/e other modules are up
- user list - list of all user-available profiles and links to each. just pulls down the user db and lists the members
- profile editor - pre-loads a form with all variables for users to edit about themselves.
- admin views:
- admin home view - same as above, but if the user is authenticated as admin they will have a few more links for admin purposes
- admin user list - same as regular list, but each entry links to the user edit form, might even be the same controller that reads AROs
- user edit form - same as profile editor but for admins to edit other users, reset their password, and delete accounts
- server editing views - for server model
- controllers for all of the above
- views and controllers for other tier 2 and 3 models that are accessible to corresponding AROs
[edit] Views
Possible views we need to have the model be capable to support Look in abstract method list above for possible views.
[edit] CakePHP Implementation
[edit] Model
TBA
[edit] Controllers
TBA
[edit] Views
TBA
[edit] Notes
To state the descriptions of views listed in the abstract methods list above more clearly, we want to have the capabilities to:
- Send registration invites, accept invites and register users
- Login/Logout
- Allow users to modify their own profile preferences.
- Allow admins to edit other users without knowing their passwords, reset passwords, and delete users.
- Allow admins to have panel access to tier 2 models such as Servers.
- Allow all users to have access to options for some other models in 2nd and 3rd tiers.
- Allow both admins and users to see user lists and profile pages to the extend provided by their AROs. Visitors will be denied most access beyond public profiles.
- Allow for some sort of homepage and basic private site layout (menus and such).