Changes between Version 4 and Version 5 of BluePrint/UserManagement


Ignore:
Timestamp:
11/11/12 11:56:18 (9 years ago)
Author:
Michael Howden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/UserManagement

    v4 v5  
    99<Name existing solutions, e.g. in other applications>
    1010
     11== Use-Cases ==
     12When a User registers and is approved, Sahana will automatically create them:
     13* Staff Record (if they request it & Admin agrees)
     14* Volunteer Record (if they request it & Admin agrees)
     15* Member Record (if they request it & Admin agrees)
     16* Membership of auth_groups (Roles)
     17 * minimally AUTHENTICATED
     18* Membership of pr_groups (Teams, Mailing Lists)
     19* Contacts
     20 * minimally EMAIL
     21* Extra fields (as per configuration)
     22
    1123== Requirements ==
    12 <Outline the requirements here>
    13 <Group requirements in subsections, e.g. functional, non-functional, interoperability etc.>
    14 
    15 https://docs.google.com/document/d/1lvuzNaRokKteLG71jGWTBFAf5OkAUhtnnk8hB1X-Sk0/edit#
    16 == Use-Cases ==
    17 <Describe actors and use-cases>
    18 <Describe workflows>
    19 <Include diagrams where useful>
     24* a deployment_setting to control what type of records (Staff, Vol, Member, etc) can be created for a new user
     25* allow a URL var to be used to automatically determine the type of record to be created for that user, and hide the widget on the registration form
     26* Show the administrator what types of records will be created for the user when they are approved.
     27* Extra fields to collect (configurable - possibly included in above deployment_setting & possibly a separate one), e.g.:
     28 * Disclaimer(s) - just a client-side JS requirement to tick box before submit
     29 * Organisation - unless in email domain
     30 * Facility (org_site)
     31 * Mailing Lists (pr_group memberships)
     32 * Contacts (Mobile Phone, Landline, Twitter, Skype, etc)
     33 * Address
     34 * Date of Birth
     35 * Skills
     36 * Comments (e.g. ‘Why should you be given access?’)
    2037
    2138== Design ==
    22 <Describe a possible design, repeat any design sections for alternative designs>
    23 <Include diagrams, screen mockups and wireframes where useful>
     39* auth_user record would have to contain some sort of tracking of what types of records are linked to it.
     40* s3_link_user would be extended to link the user to the different types of records
    2441
    2542== Implementation ==