Talk:PubMan Func Spec Submission

QA by GUI team

UC_PM_SM_01 create item: -> QA rejected because it contains a blocker for the workflow (choosing a collection):

Proposal for choose collection: To prevent the user from choosing a collection manually:

• it can be done by personal settings (not R3)
• by defining a 'standard collection' as a default

Rupert 11:03, 17 December 2007 (CET)

Rupert, can you please clarify what do you mean with this? The user must choose a collection at some point. Where would you think this should be done? A standard collection for one user may not be a standard collection for another user. --Natasa 09:25, 18 December 2007 (CET)

Let's say an institute has 3 collections and one of it is frequently used (this might often be the case). If the collection administrator could mark this as the 'standard collection' we can set this one as default just to get the user immediately to the edit item page. There he will still be able to decide for another collection - let's say with a additional dropdown in the edit item mask. Is this technically possible during the create item process? Rupert 14:26, 20 December 2007 (CET)

Rupert, according to our basic concepts it is possible that a user who belongs to one institute has the privilege to submit to the collection of another institute. The local administrator may be responsible for one institute only and therefore cannot define this kind of priority. In fact, the default collection is a "user preference" and not an "institute preference". If it's very important to skip the selection step, the pubman application could consider an alternative rule to select a default collection, e.g. sort the list of collections alphabetically and take the first. Anyway, I'm not sure if this wanted by the administrative users of the system: If they assign one user with the privilege to submit to more than one collections, there is obviously a need for him to select one of those. Making this selection less obvious may lead to many misrouted submissions. These submissions will be "sent back for revision" to the depositor, thus create another kind of overload. --Inga 16:13, 20 December 2007 (CET)

OK, so I understand now why the collection page is a blocker. The goal is to make sure that users are not doing wrong things. But how we do it is another question. To block the edit mask is in my opinion not the right way.

- we can place the collection selection very prominent in the edit mask

- we can remind the user with messages in the edit mask

Rupert 21:05, 20 December 2007 (CET)

That would not be nice for Technical team, as edit mask is most used from many other use cases. We have to deal with another level of complexity. Agreed with Inga's argumentation as well - maybe nicer way to select before coming to the edit mask should be thought of.

For example, if the user comes to depositor workspace he does not have to see directly list of items filtered by a certain status, but maybe the grouping can be:

• Collection A [action:submit][action:all][action:pending][action:submitted][action:released][action:withdrawn]
  • MyItem1
  • MyItem2
  • MyItem3
• Collection B [action:submit][action:all][action:pending][action:submitted][action:released][action:withdrawn]
  • MyItem5
  • MyItem6
  • MyItem7

where [action:all][action:pending][action:submitted][action:released][action:withdrawn] are actually the filtering actions which items to see :) --Natasa 16:29, 21 December 2007 (CET)

OK, then lets take inga's proposal. The best solution would be to have it in the preferences. Until we have that we could take the first one (alphabetically). Agreed? Rupert 14:01, 8 January 2008 (CET)

UC_PM_SM_02 edit item -> QA done

UC_PM_SM_03 submit item -> QA done

UC_PM_SM_04 fetch metadata from external system -> QA done

UC_PM_SM_11 create new revision of item -> QA done

Rupert 11:56, 17 December 2007 (CET)

Quality Assurance

Graphical User Interface

Use Case

Central European Time