Difference between revisions of "Talk:Faces Album Management"

Latest revision as of 09:20, 24 July 2009

General[edit]

Basic idea of sharing an album (outcome of FACES Meeting 17.02.09):

UC_FAC_AM_01 Create album[edit]

User roles to be checked for album creation. See http://zim01.gwdg.de:8080/browse/AS-525 for more infos. --Natasa 10:47, 27 August 2008 (UTC)

UC_FAC_AM_02 Add picture to album[edit]

CLOSED Discussion:
Possibility to add one picture to more than one single album in one step

GUI: Is not possible with an intuitive GUI (Data quality! No undo available!) The functionality of seeing which pictures are already in an album (in the browsing view) will get lost. Maybe as administrative feature --Unfried 13:59, 8 September 2008 (UTC)
DEV: Can be technically provided. Tricky part is to automatically tell user in which albums (with status different from "released", "withdrawn" he has privileges for adding) the picture was already added (ToDO: check with FIZ on querying the semantic store) --Natasa 15:46, 25 August 2008 (UTC)

Conclusion:

As the requirement of adding one picture to several albums within one step can not be supported by the GUI, we decided to delete it from the requirements. --Kristina 07:49, 12 September 2008 (UTC)

UC_FAC_AM_03 Remove picture from album[edit]

UC_FAC_AM_04 Edit album[edit]

UC_FAC_AM_05 Delete album[edit]

UC_FAC_AM_06 Release album[edit]

UC_FAC_AM_07 Withdraw album[edit]

UC_FAC_AM_08 Export album[edit]

UC_FAC_AM_09 Share album[edit]

CLOSED Discussion:
Usage of user groups for the sharing of an album

Instead of sharing an album with several users, the possibility of creating an user group can be used

Create a user group
1. A user (who has the corresponding privileges) creates a user group by providing e-mail addresses of possible participants.
2. The system invites the possible participants via e-mail.
3. The possible participants confirm their participation in the user group by following a link provided by the e-mail.
Sharing of an album with a user group
1. Visibility
  - User group and their participants must be visible to the owner of an album
  - Each user can only see the user groups and their participants he is part of
  - During invitation: is interesting to know which users are also invited to the user group (independently if they already have confirmed their participation or not) --> not possible
2. One user group will be selected to share the album.
3. Users will get a notification but do not have to confirm the sharing.
4. When a user does not want to share the album he has to leave the user group. When the group is sharing other albums, too, he will unshare this albums, too.

CLOSED Discussion:
How to add a shared user

Two possibilities were discussed:

Via User Name
Via e-Mail Address

Conclusion:

Via user name is not possible because the user name is not known by the system when using a handle system --> via e-mail address will be used (was decided in an internal meeting on 11.12.08; participants: Natasa, Rike, Bastien, Rupert, Denise, Markus M., Kristina)

UC_FAC_AM_10 Confirm shared user[edit]

Development ToDo:

Check core service feature "retrieveCurrentGrants" of a user, discuss with FIZ on some filter possibilities i.e. given objectID user to get the list of Roles he is in for an object; check Bugzilla issue 707
FIZ is informed on requirement that the user who owns an object (item/container) shall be able to grant privileges to this item/container -> this is at present not possible, as the only user who is able to grant privileges is "roland"; check Bugzilla issue 708

UC_FAC_AM_11 Unshare Album[edit]

CLOSED Discussion:

The system should be able to only display a list of user accounts which are really at present sharing this album i.e. that have Collaborator role for the album (related issue check Bugzilla issue 707 - not implemented yet in the core service). --Natasa 14:37, 16 January 2009 (UTC)
Work around: The e-mail addresses will be saved as properties of the note pad. --Kristina 16:11, 18 February 2009 (UTC)

UC_FAC_AM_12 Copy album content[edit]

Remarks for GUI implementation:

GUI might be different here because multiselect is necessary. --Unfried 15:33, 8 January 2009 (UTC)

@@ Line 22: / Line 22: @@
 == UC_FAC_AM_06 Release album ==
-===DevInput===
-*Comments from --[[User:Natasab|Natasa]] 12:54, 16 January 2009 (UTC)
-**in case workflow proposed in [[Talk:Faces_Album_Management#UC_FAC_AM_05_Delete_album]] is accepted then release of an album can be done:
-***When album is in status pending, and is not shared (in this case automatically gets status submitted and afterwards released)
-***When album is in status submitted, and is shared (in this case one transition to status released is made) (for this purpose, the precondition needs to be changed accordingly).
-**Question: shared NotePad can still be album member and does not have to be released ever. The same is the case with evtl. private notepads. Can these be edited after an album is released?
-*** Yes, why not. --[[User:Kristina|Kristina]] 11:05, 13 February 2009 (UTC)
 == UC_FAC_AM_07 Withdraw album ==
-===DevInput===
-* Comments from --[[User:Natasab|Natasa]] 13:02, 16 January 2009 (UTC)
-** Question: what is happening with the notepads during the Album withdrawal? Shall they all be really deleted?
-*** Proposal: delete them all just before an album is withdrawn in the core service (i.e. after user confirmed the withdrawal)
-* No, the note pads shall not be deleted. Where did you find that information? It's not in the use case. I just want to keep them as they are (still pending, still editable if needed). --[[User:Kristina|Kristina]] 10:34, 13 February 2009 (UTC)
 == UC_FAC_AM_08 Export album ==
@@ Line 56: / Line 44: @@
 ## Users will get a notification but do not have to confirm the sharing.
 ## When a user does not want to share the album he has to leave the user group. When the group is sharing other albums, too, he will unshare this albums, too.
-: '''Conclusion:'''
-: Not really interesting for FACES. User groups will only be discussed when the institute requires them. --[[User:Kristina|Kristina]] 13:12, 22 December 2008 (UTC)
 '''CLOSED Discussion:''' <br/>
-'''How to add a shared user:'''
+'''How to add a shared user'''
 : Two possibilities were discussed:
 :# Via User Name
@@ Line 66: / Line 52: @@
 : '''Conclusion:'''
 :Via user name is not possible because the user name is not known by the system when using a handle system --> '''via e-mail address''' will be used (was decided in an internal meeting on 11.12.08; participants: Natasa, Rike, Bastien, Rupert, Denise, Markus M., Kristina)
-===DevInput===
-*Comments from --[[User:Natasab|Natasa]] 13:06, 16 January 2009 (UTC)
-**See the proposal at [[Talk:Faces_Album_Management#UC_FAC_AM_05_Delete_album]]
-***if this proposal is accepted, then the flow and this use case need to be changed.
-****we need "submit for sharing" album use case that would submit the album and will automatically create a shared notepad
-****for clarity rename this use case to "add shared users to an album" (and exclude automatic creation of a shared notepad)
-**To clarify a bit the steps 2, 3 specified in the UC:
-***2. The system displays the share album entry mask. The user enters for each shared user an valid e-mail address and confirms his input.
-**** I assume this will be like an email send form, where user can add as many email addresses as they wish, delimited with ",". In addition, user may add in the message body some free text, in addition to "User X invited you for sharing of this album" and some more explanations on how to ask for a user account or log-in to the system.
-***3. The system saves each e-mail as inactive shared users to the album and sends each of them a notification. Further on, a shared note pad (item) in the state pending will automatically created by the system and related to the album. The use case ends successfully.
-****After confirmation of the email, the system sends this email to all addresses in the email.
-****Afterwards users continue with UC_FAC_AM_10 Confirm shared user
-**NOTE: to add upon the notes in Unshare album, as it appeared as separate idea: we may save the list of email accounts to which the album is sent for sharing in the shared notepad of this album
 == UC_FAC_AM_10 Confirm shared user ==
-===DevInput===
+'''Development ToDo:'''
-*Comments from --[[User:Natasab|Natasa]] 13:54, 16 January 2009 (UTC)
+* Check core service feature "retrieveCurrentGrants" of a user, discuss with FIZ on some filter possibilities i.e. given objectID user to get the list of Roles he is in for an object; check [http://www.escidoc.org/issueManagement/show_bug.cgi?id=707 Bugzilla issue 707]
-**The e-mail shall contain the following information
+* FIZ is informed on requirement that the user who owns an object (item/container) shall be able to grant privileges to this item/container -> this is at present not possible, as the only user who is able to grant privileges is "roland"; check [http://www.escidoc.org/issueManagement/show_bug.cgi?id=708 Bugzilla issue 708]
-***what to do if the invited person has already a Faces account (+link to confirm-share)
-***what to do if the invited person does not have a Faces account (+link to Faces request account form)
-**if invited person has a Faces account then (maybe some security issues can be checked with Robert as well):
-***link can contain redirect to a login-form (or if already logged in) with target to some page that contains a button to confirm this explicitly
-****the confirm can make internal log-in as administrator user and make a corresponding grant to the invited person (current user handle) e.g. user A (granting of a Collaborator role for AlbumX to user A)
-***the confirmation procedure shall really be carefully thought off e.g.:
-****if user tries to click the link and album has been deleted in a meantime (e.g. unshared and then deleted, the link should be invalid and a corresponding message needs to be provided to the end user).
-****if user tries to click the same link second time, where first time he made already a confirmation (and thus is being granted with respective privilege) - appropriate message needs to be provided and system should do nothing
-****others to think of..
-****NOTE: idea appeared with Notepad extra information,  after confirmation, we can add userid, email to the shared notepad
-**if invited person does not have a Faces account then she should click the link to Faces request account form. Standard creation of user account and granting of basic Faces collection privileges will then happen in a separate workflow. Only then user can continue (by clicking the link he got in the first email to be redirected to a login form or confirm share page).
-**Related to the step 4: ''The system changes the state of the user to active, creates a private note pad related to the album for the user and adds the shared user (name and affiliated organization) as "further authors" to the album metadata. From now on, the shared album is visible for the shared user. The use case ends successfully.'' : i find problematic the following: automatic creation of the shared user as an author to the album and automatic creation of private note-pad.
-***private notepad: can be done by explicit set of actions (create/edit/delete private notepad), because not all users would need to have private notepads, for some it may be confusing. All can create them, but we would not force them to be created by the system automatically. This is a per-need feature.
-***adding the shared user as author to the album is not possible because we would have no information on the person behind the shared user and because only creator of an album is allowed to edit the album. This would mean that the creator of an album should be able to "manually" edit the album with corresponding metadata. As future development, this can maybe done via Cone service and when we establish relation between persons and users.
-'''DevToDO'''
+== UC_FAC_AM_11 Unshare Album ==
-*check core service feature "retrieveCurrentGrants" of a user, discuss with FIZ on some filter possibilities i.e. given objectID user to get the list of Roles he is in for an object; check [http://www.escidoc.org/issueManagement/show_bug.cgi?id=707 Bugzilla issue 707]
-*FIZ is informed on requirement that the user who owns an object (item/container) shall be able to grant privileges to this item/container -> this is at present not possible, as the only user who is able to grant privileges is "roland"; check [http://www.escidoc.org/issueManagement/show_bug.cgi?id=708 Bugzilla issue 708]
-== UC_FAC_AM_11 Unshare Album ==
+'''CLOSED Discussion:'''
-===DevInput===
+* The system should be able to only display a list of user accounts which are really at present sharing this album i.e. that have Collaborator role for the album (related issue check [http://www.escidoc.org/issueManagement/show_bug.cgi?id=707 Bugzilla issue 707] - not implemented yet in the core service). --[[User:Natasab|Natasa]] 14:37, 16 January 2009 (UTC)
-*Comments from --[[User:Natasab|Natasa]] 14:37, 16 January 2009 (UTC)
+*: Work around: The e-mail addresses will be saved as properties of the note pad. --[[User:Kristina|Kristina]] 16:11, 18 February 2009 (UTC)
-**Only while reading this use case became aware of active/inactive users for an album, but this would not be possible (referring to step 2 ''The system displays a list of all shared users with their states (for active users the user name is displayed and for inactive users the provided e-mail address as the user name is still not known).''
-***we do not have the feature of active/inactive grants for account users
-***we do not have a place where to keep the information on emails asked for a request
-***if the user would like to have an overview to which emails he sent the share request, the system may send actually an automatic email also to this user
-**** I think thats not necessary. --[[User:Kristina|Kristina]] 13:08, 13 February 2009 (UTC)
-***The system should be able to only display a list of user accounts which are really at present sharing this album i.e. that have Collaborator role for the album (related issue check [http://www.escidoc.org/issueManagement/show_bug.cgi?id=707 Bugzilla issue 707] - not implemented yet in the core service)
-***OK. I deleted the separation between active and inactive shared users in the use cases. So now only users who confirm to share an album are shared users. --[[User:Kristina|Kristina]] 13:08, 13 February 2009 (UTC)
-***NOTE: there is a possibility to add this information automatically somehow in the shared notepad of an album, as a non-user editable data, until the 707 is implemented; However, even in this case, if the user shared with e-mail addresses he will not be able to unshare them, as it is outside of the system (if my understanding of sharing procedure is correct :)
-**regarding step 4 ''The system updates the shared users of the album and sends all deleted active users a notification via e-mail. '':
-***i assume this would not be possible so easily, as for account users we would not have email information. For email accounts that have not yet corresponding Faces accounts - probably it even makes no sense, because they are officially not even shared
-***NOTE: again, this can be possibly implemented with some extra information via the shared NOTEPAD data (just an idea)
-**Question: what is happening with private notepads when the user is unshared?
-**: Logically, note pad has to be deleted. Is that technical possible? --[[User:Kristina|Kristina]] 12:22, 13 February 2009 (UTC)
-::Technically somehow yes, but just to put comment in here, that private note-pads do not belong to the album, but to the users. Therefore, maybe users who own their private note-pads should have possibility to delete them. --[[User:Natasab|Natasa]] 12:31, 13 February 2009 (UTC)
-**Question: what is happening with shared notepad when the album is completely unshared?
-**: Logically, note pad has to be deleted. But in this case can also stay as it is but is now only visible for the owner of the album (similar to his own private album). --[[User:Kristina|Kristina]] 12:22, 13 February 2009 (UTC)
-::Same comment as for above. --[[User:Natasab|Natasa]] 12:31, 13 February 2009 (UTC)
 == UC_FAC_AM_12 Copy album content ==
 '''Remarks for GUI implementation:'''
 * GUI might be different here because multiselect is necessary. --[[User:Unfried|Unfried]] 15:33, 8 January 2009 (UTC)
-===DevInput===
-*Question: why would not be possible to extend not released album with pictures of another album? Is this a functional requirement from our users?
-**Background: I find it very practical when already have an album created, to go through other albums, view them and add their content to e.g. my active album.
-** I would like to have this. This could be realized through the add functionality below each picture when browsing an album (an the add all functionality, when you want to have all pictures of this album). But the GUI team does not want to have this, because it makes the GUI inconsistent. At the moment it is only possible to add the pictures from a public album when going on the detailed view of the album. So you can only add one picture in one step. --[[User:Kristina|Kristina]] 13:16, 13 February 2009 (UTC)