Difference between revisions of "Talk:Faces User Management"

Revision as of 09:01, 29 August 2008

UC_FAC_UM_01 Log on to the system[edit]

As long as the standard mechanism provided by the coreservices is used this use-case is fine. --Natasa 14:27, 25 August 2008 (UTC)

UC_FAC_UM_02 Log off from the system[edit]

UC_FAC_UM_03 Create account user[edit]

State inactive is not supported by the core services yet. Natasa will talk to FIZ, because the state is needed for Faces and PubMan (see Jira Task FAC-68: http://zim01.gwdg.de:8080/browse/FAC-68). --Kristina 08:39, 29 August 2008 (UTC)

UC_FAC_UM_04 Edit account user[edit]

UC_FAC_UM_05 Deactivate account user[edit]

Technically, an album can not be deleted if it is in state submitted. --Kristina 08:56, 29 August 2008 (UTC)

Two possibilities have to be checked by Natasa with FIZ:

Automatically rewise the album to the state "in revision" and delete it then.
Allow it that submitted albums can also be deleted.

This problem also influences UC_FAC_AM_05 Delete album.

UC_FAC_UM_06 Confirm account user[edit]

User States[edit]

User Roles[edit]

My assumption (Natasa):

We need one context "Faces Albums" where users can create albums (gets depositor rights).
We need one context "Faces" plus the role "Privileged Viewer" (has only viewing rights, no depositing ones) for users who are able to view all items independent on component (image) visibility.

Background: Currently only the states private (only visible for the creator of the image) and public (visible for all users) are available in the framework. But for Faces we need more. Therefore the role "Privileged Viewer" will be implemented which allows a user to view all private components within a special context (Faces) also when he is not the creator. This role has to be automatically assigned to each Faces account user.

--> Role was delivered by the framework

@@ Line 21: / Line 21: @@
 == User Roles ==
-*A more generic remark: defined component visibility is tricky, as it is required by a certain context (ie. FACES context allows "public" component visibility only for the 6 persons, the rest have to be "private" or "restrcited visibility to the account users.) therefore, definition of component visibility due to certain usage in a certain context might make "re-usage" and "re-purposing" of data tricky. For FACES collection, we still might go this way, as the usage rights for the images will not change, neither in other contextes...--[[User:Uat|Ulla]] 08:55, 12 June 2008 (UTC)
-*not certain if all Face albums by users should be created in "Faces" context in fact
+* My assumption (Natasa):
-:: What other context is possible? --[[User:Kristina|Kristina]] 09:15, 27 June 2008 (UTC)
+:* We need one context "Faces Albums" where users can create albums (gets depositor rights).
-*My assumption (Natasa):
+:* We need one context "Faces" plus the role "Privileged Viewer" (has only viewing rights, no depositing ones) for users who are able to view all items independent on component (image) visibility.
-**We need 1 separate context i.e. "Albums context" where users can create albums
+: Background: Currently only the states private (only visible for the creator of the image) and public (visible for all users) are available in the framework. But for Faces we need more. Therefore the role "Privileged Viewer" will be implemented which allows a user to view all private components within a special context (Faces) also when he is not the creator. This role has to be automatically assigned to each Faces account user.
-**We need in "Faces" context thus role "Privileged Viewer" for users who are able to view all items independent on component (image) visibility.
+:--> Role was delivered by the framework
-:: Background: Currently only the states private (only visible for the creator of the image) and public (visible for all users) are available in the framework. But for Faces we need more. Therefore the role "Privileged Viewer" will be implemented which allows a user to view all private components within a special context (Faces) also when he is not the creator. This role has to be automatically assigned to each Faces account user.
-::--> Role was delivered by the framework
 == Account User Metadata Set ==