Faces User Management

From MPDLMediaWiki
Revision as of 09:33, 12 January 2012 by Kristina (talk | contribs) (→‎Account User Metadata Set)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
FACES

Scope · Functionalities
Disclaimer and Copyright
Support

Application Profiles
Release Agreement

Specification:
Browse and Display · Search
Albums · Users
Note Pads · Versioning

Related Projects:
Imeji

edit



General Information[edit]

  • Expected participation: approximately 30 new users per year
  • 1. Step (R3): MPDL will create the users (because the Admin solution is not finished yet to give it to other institutes)
  • 2. Step (R4): MPIB will get their own Admin solution to create the users by themselves.
  • The decision which users are allowed to get an user account and which are not lies by the technical agent of the institute, who gets all application forms in the first place.
  • Each accounts is created for exact one user, not for user groups.

UC_FAC_UM_01 Log on to the system[edit]

see UC_PM_UM_02 Log on to the system

UC_FAC_UM_02 Log off from the system[edit]

see UC_PM_UM_03 Log off from the system

UC_FAC_UM_03 View account users list[edit]

see UC_LA_AS_01 View account users list

UC_FAC_UM_04 Create account user[edit]

see UC_LA_UM_01 Create account user

UC_FAC_UM_05 Edit account user[edit]

see UC_LA_UM_02 Edit account user

UC_FAC_UM_06 Deactivate account user[edit]

see UC_LA_UM_04 Deactivate account user

UC_FAC_UM_07 Confirm account user[edit]

see UC_LA_UM_08 Confirm account user

Additional information[edit]

User Roles[edit]

Following roles are needed:

Faces Role Core Service Role For which resource is role defined What are the rights
Account user Privileged viewer Faces context (context that administers Face items)

retrieve content of items (no matter in what visibility)

Depositor

Now: Faces context
In future: Faces Albums context

retrieve own containers and items and binary content of an item in any status if she created the item
create containers and items (i.e. note pads)
update own containers and own items (note pad) in the state pending
lock own containers and items in version status pending (probably not relevant for Faces)
add members to an own container in the state pending
remove members from an own container in the state pending
delete own containers and items (note pad) in state pending
withdraw own containers in state released

MD-Editor container (Album)

Note: not tested if it works for containers
ToDo: Check with FIZ on possibilities for having another specific role, so we avoid granting privileges at the time of creation of the container, as workflow for Faces is different

modify containers and items in status released lock own containers and items in version status released (probably not relevant for Faces)
add members to container in the state released
remove members from container in the state released
submit items and containers if she has last modified the latest item/container version

Moderator container (Album)

Note: not tested if it works for containers
ToDo: Check with FIZ on possibilities for having another specific role, so we avoid granting privileges at the time of creation of the container, as workflow for Faces is different

release containers and items in status submitted
Note: in case of Faces workflow, albums shall be submitted before release by the system

CollaborationGrantor

Note: not implemented yet

container, item, component being able to grant collaborator role to other users for contexts, own containers (e.g. share album), items and components

Note: the rights for this role shall be by default granted together with all Depositors and local-admins, here only added as separate role, as this needs to be communicated to FIZ separately. Assumption: all depositors shall have these rights automatically for own items and containers.

Collaborator Collaborator

Note: not implemented yet

container (Album)
item (Notepad)

add members to collaborated container in state pending (in fact, depending on workflow, esp. for PubMan)
remove members from collaborated container in the state pending
edit collaborated items (note pad) in the state pending

Administrator Administrator Faces context and Faces Album context

is allowed to retrieve items and containers, open/close contexts, withdraw items and containers, revise items and containers, create/revoke grants for contexts

ToDo: Check with FIZ on possibilities for having extension so that user with this role are able to grant privileges to users for objects in their context and if they are able to create new users

Use Cases[edit]

Use Case User Account User Administrator
Browse and Display
UC_FAC_BD_01 View picture list

UC_FAC_BD_02 View picture details
UC_FAC_BD_03 View picture for comparison

pictures and metadata of 6 predefined persons pictures and metadata of all persons pictures and metadata of all persons
UC_FAC_BD_04 View album details -- own private albums, shared private albums and all published albums all private albums and all published albums
UC_FAC_BD_05 View albums list -- yes yes
UC_FAC_BD_06 View released albums -- yes yes
UC_FAC_BD_07 Resolve released album by URL metadata pictures and metadata pictures and metadata
UC_FAC_BD_08 View file metadata files of 6 predefined persons files of all persons files of all persons
UC_FAC_BD_10 View statistics -- -- yes
UC_FAC_BD_11 Navigate within one picture yes yes yes
UC_FAC_BD_12 View note pad -- Own private note pads, note pads he is sharing, released note pads from all users All note pads
Searching
UC_FAC_SR_01 Search within the 6 predefined persons of the collection within the whole collection and in all published albums within the whole collection and in all published albums
UC_FAC_SR_02 View all pictures of one person pictures of 6 predefined persons pictures of all predefined persons pictures of all predefined persons
UC_FAC_SR_03 Public Album Search -- yes yes
Album Management
UC_FAC_AM_01 Create album -- yes yes
UC_FAC_AM_02 Add picture to album -- own private albums, shared albums ??? all private albums ???(would be a long drop down)
UC_FAC_AM_03 Remove picture from album -- own private albums, shared albums all private albums
UC_FAC_AM_04 Edit album -- own private albums all private albums
UC_FAC_AM_05 Delete album -- own private albums all private albums
UC_FAC_AM_06 Release album -- own private albums all private albums
UC_FAC_AM_07 Withdraw album -- own published albums all published albums
UC_FAC_AM_08 Export album -- own private albums, shared private albums and all published albums all private albums and all published albums
UC_FAC_AM_09 Share album -- own private albums all private albums
UC_FAC_AM_10 Confirm shared user -- yes (after invitation) yes (after invitation), but makes no sense because he has already the privileges
UC_FAC_AM_11 Unshare Album -- yes yes
UC_FAC_AM_12 Copy album content -- own private albums, shared private albums and all published albums all private albums and all published albums
User Management
UC_FAC_UM_01 Log on to the system -- yes yes
UC_FAC_UM_02 Log off from the system -- yes yes
UC_FAC_UM_03 View account users list -- -- all account users
UC_FAC_UM_04 Create account user -- -- yes
UC_FAC_UM_05 Edit account user -- -- yes
UC_FAC_UM_06 Deactivate account user -- -- yes
UC_FAC_UM_07 Confirm account user -- own user account own user account
Note Pads
UC_FAC_NP_01 Create private note pad -- yes yes
UC_FAC_NP_02 Edit note pad -- Own note pads yes
UC_FAC_NP_04 Delete note pad -- Own note pads yes
UC_FAC_NP_05 Release note pad -- Own note pady yes
UC_FAC_NP_06 Withdraw note pad -- Own notepads yes

Open Points
No roles available for following privileges:

Account User Metadata Set[edit]

A new created account user in the system has following attributes:

  • Name
The name of the account user which consists of a given and a family name.
(string, mandatory, once)
eduPerson: eduPersonPrincipalName (cn, sn)
  • Organization
The name of the organization the account user works for.
(string, mandatory, once)
eduPerson: eduPersonOrgDN
  • Unit
The unit within the organization the account user works for.
(string, optional, once)
eduPerson: eduPersonOrgUnitDN
  • Position
The position of the account user within the organization.
(string, optional, once)
eduPerson: eduPersonAffiliation
  • Address
The adress of the organization (street name and number, postal core, city, country).
(string, mandatory, once)
eduPerson: postalAddress
  • e-Mail
The e-mail address of the account user.
(string, mandatory, many)
eduPerson: mail
  • Telephone
The telephone number of the account user.
(string, optional, many)
eduPerson: facsimileTelephoneNumber
  • Fax
The fax number of the account user.
(string, optional, many)
eduPerson: ???
Is this metadata realy necessary? --Natasa 14:27, 25 August 2008 (UTC)
Its part of the application form from the institute. So if they want it, we have to keep it. --Kristina 09:22, 28 August 2008 (UTC)
  • Study Name
The name of the study the account user will use Faces for.
(string, optional, once)
eduPerson: description
Should the study name be mandatory and a single field and is it a property of the account user in fact?--Natasa 14:27, 25 August 2008 (UTC)
Perhaps we can put study name and description together and use eduPerson property "Description" for it. --Kristina 09:09, 29 August 2008 (UTC)
  • Study Description
A short description of the study the account user will use Faces for.
(string, optional, once)
eduPerson: description

Discussion