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)

Allowed Genre as collection setting: UC Create new revision

Discussion on genres transfered from Jira AS-269

Kiefl Rupert - [12/Dec/07 11:53 PM]

The collection defines genres available for submission. Is this done to block explicitly all other genres?

Lets walk through the case: The user wants to create a new revision. He chooses a different collection and wants to submit. The system states he has a wrong genre and can not submit.

The user has the following options:

1. Change the genre (just to be able to submit?)
2. Contact the administrator to add a new genre to the collection?

Both ways seem to be not satisfying. Can we add a genre to the collection automatically if an item was added with an unknown/not allowed genre?

Tschida, Ulla - [13/Dec/07 09:47 AM ]

see my answers to your questions below:

The collection defines genres available for submission. Is this done to block explicitly all other genres? => It is due to the reason, that some institutes are not at all interested in our 15(?) genres, but just in some of them. By defining allowed genres for a collection, they have a "customized" drop down list, for their mostly relevant publication types.

use case create new revision: indeed a critical point...background is, we have the feature that genres are "allowed" for a collection (see comment above). but when creating revisions, you might want to change the genre, and you might want to create the revision in a new collection, and then the collection and the genre are not compatible.

I know that proposed solution is not optimal. Alternatively, we could say: when creating a revision, the item data are pre-filled (from source item), except genre. Therefore, user would have to state the genre again, when creating a revision. Not sure what is "muehsamer".

The option 2 you mention, is of course not possible. Option 1 neither, he would have to change the collection (collection policies...rules are always mühsam)

We identified when creating a new revision that there may be problems with the genre and in this case we have the following options having in mind genre is "inherited" as a default metadata of the revision.

Reference to use case step 9, options a and b. Option a: if genre is allowed in the collection, genre is inherited Option b: (in my opinion should be): if genre is not allowed in the collection, genre is not inherited Would doubt that creation of a new revision is always a same genre as the previous revision, but may be :) --Natasa 11:11, 21 December 2007 (CET)

OK, agreed Rupert 11:58, 21 December 2007 (CET)

Remarks for modification of create/edit item use cases, fetch metadata, create from template etc.

If the functional team is satisfied with the UC as they look now DevT should implement them in the exactly same manner. My proposals were oriented towards creation of easy to maintain edit mask, as all changes for editing of items would only be on editing of items that are already created (in the system as Value objects or even in the FW - in case of single item ingestion).

With that approach edit will really only be edit and there will be more starting points to which user comes to edit an item. My proposals are also based on the (bad) experience of dealing with the edit item use case and GUI mask in the past and taking the use-case as the exact must-be-implemented for the GUI, so was rather towards making it more easier. --Natasa 17:03, 16 January 2008 (CET)

Remarks for proposal to define separate use cases for file upload

The file upload is at the moment used in - standard submission - easy submission - other submission interfaces? - by other solutions? So this was my reason to split it to a separate use case. It is also making the edit item use case pretty unreadable. --Natasa 17:03, 16 January 2008 (CET)

Remarks for proposal to define one single information on a single place rather than repeating it into every use case

Would work only if the whole set of functionality is well understood by each developer and if each developer should read many pages. So should be in that case as a minimum be on a single page, but linked from each use case of relevance. --Natasa 17:05, 16 January 2008 (CET)

Quality Assurance

Graphical User Interface

Use Case

Central European Time