Difference between revisions of "Talk:PubMan Func Spec Submission"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(118 intermediate revisions by 7 users not shown)
Line 1: Line 1:
=Discussion PubMan_Functional_Specification=
==UC_PM_SM_01 create item==
==UC_PM_SM_01 create item==
The user selects a collection where she wants to create a new item.
The user selects a collection where she wants to create a new item. With this action the publication workflow is started.


===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''in design'''
*Schedule:'''R3'''
*Schedule:'''R3'''


Line 13: Line 12:
**create new revision of an item
**create new revision of an item
**fetch metadata from external system
**fetch metadata from external system


===Actors===
===Actors===
Line 19: Line 17:


===Pre-Conditions===
===Pre-Conditions===
*None.
*if this use case was invoked by another use case then a template item with default metadata and (optionally) a relation to an existing item is passed


===Flow of Events===
===Flow of Events===
*1. The user chooses to create an item.
*1. The user chooses to create an item.
*2. The system displays a list of all collections in state "opened" for which the user has the privileges as Depositor.
*2. The system displays a list of all collections and their description in state "opened" for which the user has the privileges as Depositor.
*3. (Optionally) The user chooses to view the collection description.
*3. The user selects a collection of her choice.
**3.1. The system displays the collection description.
*4. continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]]  
*4. The user selects a collection of her choice.
*5. continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]]  


===Alternatives===
===Alternatives===
Line 46: Line 42:
The user edits the last version of an item while executing a task in the publication or in the modification workflow defined for the collection of the item.
The user edits the last version of an item while executing a task in the publication or in the modification workflow defined for the collection of the item.
===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''in design'''
*Schedule:'''R3'''
*Schedule:'''R3'''


Line 57: Line 53:
**[[PubMan_Func_Spec_Submission#UC_PM_SM_11_create_new_revision_of_item|UC_PM_SM_11 create new revision of item]]
**[[PubMan_Func_Spec_Submission#UC_PM_SM_11_create_new_revision_of_item|UC_PM_SM_11 create new revision of item]]
**[[PubMan_Func_Spec_Quality_Assurance‎#UC_PM_QA_11_modify_item|UC_PM_QA_11 modify item]]
**[[PubMan_Func_Spec_Quality_Assurance‎#UC_PM_QA_11_modify_item|UC_PM_QA_11 modify item]]
*This use case includes the use cases:
**[[PubMan_Func_Spec_Submission#UC_PM_SM_12_file_upload|UC_PM_SM_12 file upload ]]


===Actors===
===Actors===
Line 65: Line 63:
===Pre-Conditions===
===Pre-Conditions===
*Last item version is selected or this use case was invoked from [[PubMan_Func_Spec_Submission#UC_PM_SM_01_create_item|UC_PM_SM_01 create item]]
*Last item version is selected or this use case was invoked from [[PubMan_Func_Spec_Submission#UC_PM_SM_01_create_item|UC_PM_SM_01 create item]]
and (optionally) a template item (metadata and (optionally) relations) is passed
*One validation point is selected.
*One validation point is selected.


===Flow of Events===
===Flow of Events===
*3. The system displays an edit view with the metadata from the last version of the item or pre-filled metadata.  
*3. The system displays an edit view with the metadata from the last version of the item or pre-filled metadata.  
*7. (Optionally) Include use case [[PubMan_Func_Spec_Submission#UC_PM_SM_16_file_upload|UC_PM_SM_16 file upload]]  
*7. (Optionally) Include use case [[PubMan_Func_Spec_Submission#UC_PM_SM_16_file_upload|UC_PM_SM_16 file upload]]
*8. (Optionally) The user enters a locator for the file, selects the visibility, adds a name and a comment and selects the content category (for R3 the content category can't be changed and is per default "supplementary material").
*5. (Optionally) The user edits the item attributes, adds new metadata values or modifies existing metadata values. This includes the selection of an entry from an authority file which is linked to a metadata element. For dealing with organizations when creating the metadata element "Organisation" see 11.2.
*5. (Optionally) The user edits the item attributes, adds new metadata values or modifies existing metadata values. This includes the selection of an entry from an authority file which is linked to a metadata element. For dealing with organizations when creating the metadata element "Organisation" see 11.2.
*6. (Optionally) The user chooses to view the collection description.
*6. (Optionally) The user chooses to view the collection description.
Line 76: Line 76:
*11. Extension point: '''''validate data'''''.
*11. Extension point: '''''validate data'''''.
**11.1. If the user wants to validate the data of the item include use case [[PubMan_Func_Spec_Submission#UC_PM_SM_09_validate_item|UC_PM_SM_09 validate item]] for the selected validation point.
**11.1. If the user wants to validate the data of the item include use case [[PubMan_Func_Spec_Submission#UC_PM_SM_09_validate_item|UC_PM_SM_09 validate item]] for the selected validation point.
*12. The user decides to finalize the editing of an item by submitting the item.
*12.a. The user decides to finalize the editing of an item by submitting the item.
**12.1.  The system creates a new version of an item. Continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_03_submit_item|UC_PM_SM_03 submit item]]  
**12.a.1.  The system creates a new version of an item. Continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_03_submit_item|UC_PM_SM_03 submit item]]  
**12.2. If the item version can not be created the system displays an appropriate error message or a validation report. The use case ends unsuccessfully.
**12.a.2. If the item version can not be created the system displays an appropriate error message or a validation report. The use case ends unsuccessfully.


===Alternatives===
===Alternatives===
*12.a. The user decides to finalize the editing of an item by saving the item.
*12.b. The user decides to finalize the editing of an item by saving the item without submitting.
*12.a.1 The system creates a new version of an item and displays a success message.
**12.b.1. The system validates the item data against the default validation rules
**12.b.2. The system creates a new version of an item. The use case ends successfully.
**12.b.3. If the item version cannot be created the system displays an appropriate error message or a validation report. The use case ends unsuccessfully.


===Post-Conditions / Results===
===Post-Conditions / Results===
Line 89: Line 91:
*possible use case for look-up of metadata triggered during edit item to serve for fetching specific set of metadata e.g. source metadata(book, conference paper, event)
*possible use case for look-up of metadata triggered during edit item to serve for fetching specific set of metadata e.g. source metadata(book, conference paper, event)
*file locator - possible use case to specify a file locator for a fulltext such as:
*file locator - possible use case to specify a file locator for a fulltext such as:
*8. (Optionally) The user adds one or more file locators to the item.
*8. (Optionally) The user adds one or more file locators (from where the full text can be downloaded by PubMan and be integrated into PubMan) to the item.
**8.1. The system sets default values for file attributes from the collection settings and displays an edit view for the file.
**8.1. The system sets default values for file attributes from the collection settings and displays an edit view for the file.
**8.2. The user enters a locator for the file, selects the visibility if not already set and the content type.
**8.2. The user enters a locator for the file, selects the visibility if not already set and the content type.
**8.3. (Optionally) The user changes the visibility, the content type, the mime type or enters a description.
**8.3. (Optionally) The user changes the visibility, the content type, the mime type or enters a description.
**8.4. The user confirms the entries.
**8.4. The user confirms the entries.
**8.5. The system links the file to the item.
**8.5. The system links the file to the item


==File upload==
===Allowed file types===
*7. (Optionally) The user adds one or more files to the item.
pdf, rtf, txt,doc, xml, jpg, bmp, png
**7.1. The system prompts for the path of the file.
**7.2. The user enters the path to the file and confirms the input.
**7.3. The system uploads the file.
**7.4. The system checks the size of the file against the defined maximum file size.
***a. The file size is less or equal to the maximum file size.
***b. The file size is greater than the maximum file size. The system discards the file and displays an error message. Continue with 7.
**7.5. ['''Not R3'''] The system checks the file against viruses.
***a. No Virus is found.
***b. At least one virus is found. The system discards the file and displays an error message. Continue with 7.
**7.6. The system identifies the mime type of the file and sets the information to the file.
**7.7. The system checks the mime type of the file against the recommended mime types.
***a. The mime type is recommended.
***b. The mime type is not recommended. The system displays a warning message.
**7.8. The system sets default values for file attributes (i.e. the file visibility) from the collection settings.
**7.9. The system displays an edit view for the file.
**7.10. The user selects the visibility if not already set and the content type.
**7.11. (Optionally) The user changes the visibility, the content type, the mime type or enters a description.
**7.12. If the user has chosen the visibility "Organizational unit" the system shows a list of all open organizational units.
***7.12.1. The user selects one or more organizational units and confirms the choice.
***7.12.2. The system sets the file to be visible by the selected organizational units.
**7.13. The user confirms the entries.
**7.14. The system links the file to the item.


*9. (Optionally) The user modifies the attributes of one file.
(has to be enhanced!)
**9.1. The system displays an edit view for the file.
**9.2. (Optionally) The user changes the visibility, the content type, the mime type, the locator or enters a description.
***9.2.1. The system checks the change of the visibility.
****a. The visibility has changed from "Organizational unit". The system removes the setting of organizational units for the visibility.
****b. The visibility has changed to "Organizational unit". The system shows a list of all open organizational units.
*****i. The user selects one or more organizational units and confirms the choice.
*****ii. The system sets the file to be visible by the selected organizational units.
****c. Other changes of the visibility were done or the visibility has not changed.
**9.3. (Optionally) The visibility is "Organizational unit" and the user chooses to change the organizational units the file is visible by.
***9.3.1. The system shows a list of all open organizational units.
***9.3.2. The user selects one or more organizational units and confirms the choice.
***9.3.3. The system sets the file to be visible by the selected organizational units.
**9.4. The user confirms the entries.


==UC_PM_SM_03 submit item==
==UC_PM_SM_03 submit item==
The user submits the last version of the item.
The user submits the last version of the item.
===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''in design'''
*Schedule:'''R3'''
*Schedule:'''R3'''


===Triggers===
===Triggers===
*The user wants to submit an item.
*The user wants to submit the last version of an item.
 
: ''item version''--[[User:Natasab|Natasa]] 14:39, 21 December 2007 (CET)
 
:: ''Comment Inga: see my comment above'' --[[User:Inga|Inga]] 20:27, 1 January 2008 (CET)
 
'''[Comment Nicole:]''' I would put this information in the same place as the information on "that every started action can be canceled by the user". Natasa, Ulla, please suggest an appropriate place, as I mentioned before. --[[User:Nicole|Nicole]] 10:31, 8 January 2008 (CET)


===Actors===
===Actors===
Line 155: Line 116:


===Pre-Conditions===
===Pre-Conditions===
*One item is selected.
*Last item version is selected.
*The last item version is in state "pending" or "in rework".
*The last item version is in state "pending" or "in rework".
 
*Depositor user is the owner of the last item version
: ''Comment Galina: Check if "the  user is the owner.. " must be a precondition''
 
:: ''Comment uat: As this UC is now also included by modification workflow it cannot be a precondition. Am I right?''
 
::: ''Comment Inga: According to the worfklow diagrams, the submit UC is only used by the depositor while submission/modification. So we could make ownership to a pre-condition.'' --[[User:Inga|Inga]] 20:31, 1 January 2008 (CET)
 
:''The user has privilege to submit the item in the current collection of the item.'' --[[User:Natasab|Natasa]] 14:43, 21 December 2007 (CET)
 
::''I wouldn't define this as a pre-condition, but handle it as exception in step 2 of the flow of event, see proposal below.'' --[[User:Inga|Inga]] 02:18, 31 December 2007 (CET)
:::''My proposal was motivated from not giving the user at all possibility to even see the link submit item if she has not privileges to do so, it is minor stuff, so no need to discuss further, as long as exception is there ''--[[User:Natasab|Natasa]] 17:33, 16 January 2008 (CET)
 
'''[Comment Nicole:]''' Ulla, Natasa, please check Inga's proposal and remove the comments if you agree with Inga's proposal. --[[User:Nicole|Nicole]] 10:32, 8 January 2008 (CET)


===Flow of Events===
===Flow of Events===
Line 175: Line 124:
*2. The system checks if the collection of the item is in state "opened" and if the user has the privilege as Depositor.
*2. The system checks if the collection of the item is in state "opened" and if the user has the privilege as Depositor.
**a. The collection is in state "opened" and the user has the privilege as Depositor.
**a. The collection is in state "opened" and the user has the privilege as Depositor.
**b. The collection is not in state "opened". The systems displays an error message (MSG_PM_SM_02_A). The use case ends without success.
**b. The collection is not in state "opened". The systems displays an error message ([[PubMan_System_Messages|MSG_PM_SM_02_A]]). The use case ends without success.
**b. The user has not the privilege as Depositor. The systems displays an error message (MSG_PM_SM_02_B). The use case ends without success.
**b. The user has not the privilege as Depositor. The systems displays an error message ([[PubMan_System_Messages|MSG_PM_SM_02_B]]). The use case ends without success.
*3. Include use case [[PubMan_Func_Spec_Submission#UC_PM_SM_09_validate_item|UC_PM_SM_09 validate item]] for validation point "submit".
*3. The system validates the item for validation point "submit".
*4. The system checks the validation report status.
**3.a. The validation report status is valid.
**a. The validation report status is valid.
**3.b. The validation report status is invalid. The selected item is unaffected. The system displays an error message ([[PubMan_System_Messages|MSG_PM_SM_03]]). The use case ends without success.
**b. The validation report status is invalid. The selected item is unaffected. The system displays an error message (MSG_PM_SM_03). The use case ends without success.
*4. (Optionally) The user enters a comment for the submission.
*5. The system prompts for a confirmation of the submission.
*5. The user finalizes the submission.
*6. (Optionally) The user enters a comment for the submission.
*6. The system sets the status of the item version to "submitted".
*7. The user confirms the submission.
*7. The system displays a success message ([[PubMan_System_Messages|MSG_PM_SM_04]]). The use case ends successfully.
 
'''[Start-Dev-QA]'''
 
''In fact at this point the system must check if the collection of the item is in state "opened". Proposal, move step 2 after step 7, or omit the step 2 in any case, as the framework should do this validation.--[[User:Natasab|Natasa]] 15:06, 21 December 2007 (CET) <br>
 
: The idea was to inform the user as soon as possible if the item cannot be submitted and to provide him with context-sensitive instructions (see corresponding error messages). It could cause confusion, if she/he is able to confirm the submission even the collection is closed. <br>BTW: If the error messages are created by the pubman solution itself or just handed over from the framework makes no difference from user's perspective --[[User:Inga|Inga]] 20:47, 1 January 2008 (CET)
 
'''[End-Dev-QA]'''
 
*8. The system sets the status of the item version to "submitted".
*9. The system displays a success message (MSG_PM_SM_04). The use case ends successfully.


===Alternatives===
===Alternatives===
*7a. The user does not confirm to submit the item.
*None
**1. The selected item is unaffected. The use case ends without success.
===Post-Conditions / Results===
===Post-Conditions / Results===
*The item version is in state "submitted".
*The item version is in state "submitted".
Line 206: Line 143:


===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''in design'''
*Schedule:'''R3'''
*Schedule:'''R3'''


Line 216: Line 153:
*None
*None
===Flow of Events===
===Flow of Events===
*1. The user chooses to harvest metadata from an external service.
*1. The user chooses to harvest (meta)data from an external service.
*2. The system displays a list of all available ingestion sources which provide an ID fetch method.
*2. The system displays a list of all available ingestion sources which provide an ID fetch method.
*3. The user selects one ingestion source and specifies an external ID appropriate to the selected ingestion source. The user triggers the query of the external system.
*3. The user selects one ingestion source and specifies an external ID appropriate to the selected ingestion source.  
*4. The system queries for item metadata with the specified ID.
*4.    The system checks if the selected ingestion source enables fetching of available fulltexts and offers to the user the possibility to decide on fulltext fetching.
**4.a. The system receives item metadata for the specified ID. Continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]] with fetched metadata values for metadata as default.
**4.a.  (optionally) The user decides to fetch one or more available fulltexts from the selected ingestion source.
**4.b. The query fails. The system does not receive item metadata for the specified ID. The system displays an error message. The use case ends without success. ''TODO: specify error message''
*5. The system queries for item metadata with the specified ID.
**5.a. The system receives item metadata for the specified ID.  
**5.b. The query fails. The system does not receive item metadata for the specified ID. The system displays an error message ([[PubMan_System_Messages|MSG_PM_SM_10)]]. The use case ends without success.
*6.    (optionally) If the user decided to fetch one or more available fulltexts from the selected ingestion source, continue with the use case [[PubMan_Func_Spec_Easy_Submission#UC_PM_EASM_02_fetch_full_text_by_identifier|UC_PM_EASM_02 fetch fulltext by identifier]].
*7.      Continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]] with fetched metadata values (and optionally fulltexts) .


===Post-Conditions / Results===
===Post-Conditions / Results===
*Fetched metadata are used to create a new item.
*Fetched metadata (and optionally fulltexts) are used to create a new item.
 
===Constraints===
No ingestion sources are defined, only Identifiers from arXiv  are considered.
 
''See https://dev.livingreviews.org/projects/epubtk/browser/trunk/ePubTk/lib/arxiv.py for an example of how to use arxiv's oai-pmh interface.''
 
===Future Development===
*Add identifier type DOI (consider SFX and OpenURL?)
*Allow fetching Metadata and fetching fulltext
*Definition of ingestion sources, see [[PubMan_Ingestion | PubMan Ingestion]]


==UC_PM_SM_05 create item from template==
==UC_PM_SM_05 create item from template==
Line 230: Line 181:


===Status/Schedule===
===Status/Schedule===
*Status: '''not implemented'''
*Status: '''in design'''
*Schedule:'''to be defined'''
*Schedule:'''R3'''


===Triggers===
===Triggers===
Line 245: Line 196:
*1. The user chooses to create a new item from the selected item. The metadata values are taken from the selected item.
*1. The user chooses to create a new item from the selected item. The metadata values are taken from the selected item.
*2. Continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_01_create_item|UC_PM_SM_01 create item]]
*2. Continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_01_create_item|UC_PM_SM_01 create item]]


===Post-Conditions / Results===
===Post-Conditions / Results===
Line 274: Line 223:
*2. The system prompts the user to confirm the item deletion.
*2. The system prompts the user to confirm the item deletion.
*3. The user confirms to delete the item.
*3. The user confirms to delete the item.
*4. The system deletes the item, ''all existing relations where this item is a source item'' and displays a success message (MSG_PM_SM_05). The use case ends successfully.
*4. The system deletes the item and displays a success message ([[PubMan_System_Messages|MSG_PM_SM_05]]). The use case ends successfully.


===Post-Conditions / Results===
===Post-Conditions / Results===
*The selected item is deleted.
*The selected item is deleted.


==UC_PM_SM_07 change collection of item==
==UC_PM_SM_07 change collection of item==
Line 307: Line 255:
*5. The system checks the item data against values and functionality allowed by the collection.
*5. The system checks the item data against values and functionality allowed by the collection.
**a. The item data is in accordance with the allowed values and functionality of the collection.
**a. The item data is in accordance with the allowed values and functionality of the collection.
**b. The item data is not in accordance with the allowed values and functionality of the collection. The system displays an error message (MSG_PM_SM_06). The use case ends unsuccessfully.
**b. The item data is not in accordance with the allowed values and functionality of the collection. The system displays an error message ([[PubMan_System_Messages|MSG_PM_SM_06]]). The use case ends unsuccessfully.
*6. The system checks the item data against the default values of attributes and metadata definitions of the collection.
*6. The system checks the item data against the default values of attributes and metadata definitions of the collection.
**a. The item data is in accordance with the default values of the collection.
**a. The item data is in accordance with the default values of the collection.
**b. The item data is not in accordance with the default values of the collection. The system prompts the user to confirm that the item data is not overwritten.
**b. The item data is not in accordance with the default values of the collection. The system prompts the user to confirm that the item data is not overwritten.
***6.1. The user confirms not to overwrite the item data.
***6.1. The user confirms not to overwrite the item data.
*7. The system changes the collection of the item and displays a success message (MSG_PM_SM_07). The use case ends successfully.
*7. The system changes the collection of the item and displays a success message ([[PubMan_System_Messages|MSG_PM_SM_07]]). The use case ends successfully.


===Alternatives===
===Alternatives===
Line 318: Line 266:
**1. The system overwrites the existing attribute values of the item with the collection’s settings for attribute values.
**1. The system overwrites the existing attribute values of the item with the collection’s settings for attribute values.
**2. The system overwrites the existing metadata values of the item with the collection settings for metadata values.
**2. The system overwrites the existing metadata values of the item with the collection settings for metadata values.
**3. The system creates a new item version, stores it and displays a success message (MSG_PM_SM_08) Continue with flow of events step 7.
**3. The system creates a new item version, stores it and displays a success message ([[PubMan_System_Messages|MSG_PM_SM_08]]) Continue with flow of events step 7.


===Post-Conditions / Results===
===Post-Conditions / Results===
*The item has been moved to another collection.
*The item has been moved to another collection.


==UC_PM_SM_09 validate item==
==UC_PM_SM_09 validate item==
The last version of an item has to be validated.
The user wants to validate the last version of an item for the given validation point.


===Status/Schedule===
===Status/Schedule===
*Status: '''implemented'''
*Status: '''in design'''
*Schedule:'''R1'''
*Schedule:'''R3'''


===Triggers===
===Triggers===
*The item has to be validated.
*This use case extends the use cases
*This use case is included by the use cases UC_PM_QA_01 confirm pre-check item, UC_PM_QA_03 accept item, UC_PM_QA_10 accept and authorize item, UC_PM_QA_11 modify item,  [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]], [[PubMan_Func_Spec_Submission#UC_PM_SM_03_submit_item|UC_PM_SM_03 submit item]].
**[[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]],


===Actors===
===Actors===
*System
*Depositor
*Metadata Editor
*Moderator


===Pre-Conditions===
===Pre-Conditions===
*One item is selected.
*Last item version is selected.
*One validation point is selected.
*One validation point is selected by the system.


===Flow of Events===
===Flow of Events===
*1. ['''Not R3'''] The system identifies possible duplicate items.
*1. The user decides to validate the last version of the item.
*2. The system checks the data of the last version of the item for missing values for obligatory metadata and further constraints defined for the selected validation point.
*2. The system checks the data of the last version of the item for missing values for obligatory metadata and further constraints defined for the selected validation point.
*3. The system generates an overview of the data of the last version of the item, the possible duplicate items and the check results.
*3. The system generates an overview that contains the validation report.
*4. ['''Not R3'''] Include use case UC_PM_SM_10 handle duplicate items.
*4. Use case ends successfully.
*5. Use case ends successfully.


===Post-Conditions / Results===
===Post-Conditions / Results===
*None
*None


===Future development===
*The system identifies possible duplicate items and proceeds further with handling of duplicates. (UC_PM_SM_10 handle duplicate items.)


==UC_PM_SM_11 create new revision of item==
==UC_PM_SM_11 create new revision of item==
The user creates a new revision of the item. This action creates a new item and a relation of type "IsRevisionOf" from the new item to the selected item.
The user wants to create an intellectually revised item.


===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''in design'''
*Schedule:'''R3'''
*Schedule:'''R3'''


===Triggers===
===Triggers===
*The user wants to create an intellectually revised item.
*The user creates a new item with a relation "isRevisionOf" to an existing item


===Actors===
===Actors===
Line 367: Line 317:


===Pre-Conditions===
===Pre-Conditions===
*One item is selected.  
*Last item version is selected.  
: ''One item version is selected?''--[[User:Natasab|Natasa]] 15:50, 21 December 2007 (CET)
*Last item version is in state "released".
:: ''See comment above'' --[[User:Inga|Inga]] 21:05, 1 January 2008 (CET)
*At least one item version is in state "released".


===Flow of Events===
===Flow of Events===
*1. The user chooses to create a new revision for the selected item.
*1. The user chooses to create a new revision for the selected item version.
*2. The systems checks for existing items with a relation of type "isRevisionOf" to the selected item.
*2. Continue with the use [[PubMan_Func_Spec_Submission#UC_PM_SM_05_create_item_from_template|UC_PM_SM_05 create item from template]] with the following metadata and the relation "isRevisionOf" to the selected item version used as a template:
**a. At least one item with relation of type "isRevisionOf" to the selected item exists. The system displays the list of these item(s).
**b. No item with relation of type "isRevisionOf" to the selected item exists.
*3. The system prompts for a description of the relation and confirmation of the new revision.
*4. (optionally) The user enters a description for the relation.
*5. The user confirms the new revision.
*6. The system displays a list of all collections for which the user has the privileges as Depositor.
*7. (optionally) The user chooses to view the collection description.
**7.1. The system displays the collection description.
*8. The user selects a collection as target collection and confirms the choice.
*9. The system checks if the genre of the selected item is an allowed genre in the target collection.
**a. The genre is an allowed genre in the target collcetion. Procceed with step 10.
**b. The genre is not an allowed genre in the taget collection. The system displays a warning message saying, that the genre is not an allowed genre in the target collection and that if he does not change the genre, he will not be able to submit.
:''My proposal and the most straightforward solution imho would be: do not inherit the genre in this case at all, do not do anything else i.e. no system message displayed and no automated addition of new genre--[[User:Natasab|Natasa]] 11:15, 21 December 2007 (CET) ''


'''[Comment Nicole:]''' This is dependant on if we will have genre specific MD or not in the future. If we have genre specific MD the step should stay as it is now. Ulla, Inga, what do you think? --[[User:Nicole|Nicole]] 11:31, 8 January 2008 (CET)
:*     Genre
 
*10. The system creates a new item with the user as the owner in the target collection. The item version is in state "pending" and has a relation of type "isRevisionOf" to the selected item. The default values for attributes and metadata values are inherited from the metadata set and the target collection settings. Collection settings overwrite values inherited from the metadata set. Following metadata values are prefilled from the selected item:
:* Genre
:* Creator
:* Creator
:* Title
:* Title
Line 399: Line 331:
:* Subject
:* Subject


*11. Continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]] with the new item as selected item and the validation point "submit" as selected validation point. The use case ends successfully.
If the genre, that should be populated is not an allowed genre for the collection, the genre will not be populated.


'''[Start-GUI-QA]'''
===Future Development===
 
*2. The systems checks for existing items with a relation of type "isRevisionOf" to the selected item.
''A message would be good: You have successfully created a new revision in state pending. [[User:Rkiefl|Rupert]] 08:29, 30 December 2007 (CET)''
**a. At least one item with relation of type "isRevisionOf" to the selected item exists. The system displays the list of these item(s).
 
**b. No item with relation of type "isRevisionOf" to the selected item exists.
: ''Please note that the new revision is not permanently stored before the user saves it at the end of the edit UC. <br/>Until now, we haven't considered many intermediate information in the UCs, e.g. information like "You have successfully created a new item" or "You have successfully executed a search'' are missing. Anyway, it is fine for me if additional instructions are considered while GUI design.'' --[[User:Inga|Inga]] 21:14, 1 January 2008 (CET)
*3. The system prompts for a description of the relation and confirmation of the new revision.
 
*4. (optionally) The user enters a description for the relation.
'''[Comment Nicole:]''' Rupert, please check Inga's comment and remove the GUI-QA comments if you agree with Inga. --[[User:Nicole|Nicole]] 11:31, 8 January 2008 (CET)
*5. The user confirms the new revision.
 
'''[End-GUI-QA]'''
 
===Alternative===
*6a If the user has Depositor rights for only one collection, the collection selection is automatically performed by the system.
**1. Continue with Flow of Events step 9.
*6b If the user has in his/her private preferences defined a target collection the system automatically selects the collection.
**1. Continue with Flow of Events step 9.


===Post-Conditions / Results===
===Post-Conditions / Results===
*A new item with the user as owner and a relation of type "isRevisionOf" to the selected item  have been created.
*None


===Allowed Genre as collection setting: UC Create new revision===
==UC_PM_SM_12_file_upload==
Discussion on genres transfered from [http://zim01.gwdg.de:8080/browse/AS-269 Jira AS-269]
The user uploads a file and defines the visibility of the uploaded file.


Kiefl Rupert - [12/Dec/07 11:53 PM]
===Status/Schedule===
* Status: '''in design'''
* Schedule:'''R3'''


The collection defines genres available for submission. Is this done to block explicitly all other genres?
===Triggers===
*The user wants to upload one or more files.
*This use case is included by the use case [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02_edit_item]]


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.
===Actors===
*Depositor


The user has the following options:
===Pre-Conditions===
# Change the genre (just to be able to submit?)
*One collection is selected.
# Contact the administrator to add a new genre to the collection?
=== Flow of Events===
*1. The user starts to upload one or more files to the system or for an item
**1.1 The system prompts for the path of the file.
**1.2 The user enters the path to the file and confirms the input.
**1.3 The system uploads the file.
**1.4 The system checks the size of the file against the defined maximum file size.
***a. The file size is less or equal to the maximum file size.
***b. The file size is greater than the maximum file size. The system discards the file and displays an error message. Continue with 1.
**1.6. The system identifies the mime type of the file and sets the information to the file.
**1.8. The system sets default values for file attributes (i.e. the file visibility) from the collection settings.
**1.9. The system displays an edit view for the file.
**1.10. The user selects the visibility if not already set and the content type.
**1.11. (Optionally) The user changes the visibility, the content type or enters a description.
**1.13. The user finalizes the entry.
*2. (Optionally) The user modifies the attributes of one file.
**2.1. The system displays an edit view for the file.
**2.2. (Optionally) The user changes the visibility, the content type, name of the file or enters a description.
***2.2.1. The system checks the change of the visibility.
****c. Other changes of the visibility were done or the visibility has not changed.
**2.4. The user finalizes the entry.


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?
===Post-Conditions / Results===
* The files are uploaded to the system


Tschida, Ulla - [13/Dec/07 09:47 AM ]
===Further development===
*Virus checking for uploaded files
**1.5. ['''Not R3'''] The system checks the file against viruses.
***a. No Virus is found.
***b. At least one virus is found. The system discards the file and displays an error message. Continue with 7.
**1.7. The system checks the mime type of the file against the recommended mime types.
***a. The mime type is recommended.
***b. The mime type is not recommended. The system displays a warning message.
*Extraction of metadata and language identification from uploaded files


see my answers to your questions below:
Visibility "OrgUnit" not yet provided by the framework:
 
**1.12. If the user has chosen the visibility "Organizational unit" the system shows a list of all open organizational units.
The collection defines genres available for submission. Is this done to block explicitly all other genres?
***1.12.1. The user selects one or more organizational units and confirms the choice.
=> 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.
***1.12.2. The system sets the file to be visible by the selected organizational units.
 
***2.2.1
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.
****a. The visibility has changed from "Organizational unit". The system removes the setting of organizational units for the visibility.
 
****b. The visibility has changed to "Organizational unit". The system shows a list of all open organizational units.
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".
*****i. The user selects one or more organizational units and confirms the choice.
 
*****ii. The system sets the file to be visible by the selected organizational units.
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)
**2.3. (Optionally) The visibility is "Organizational unit" and the user chooses to change the organizational units the file is visible to.
 
***2.3.1. The system shows a list of all open organizational units.
: 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.
***2.3.2. The user selects one or more organizational units and confirms the choice.
Reference to use case step 9, options a and b.
***2.3.3. The system sets the file to be visible by the selected organizational units.
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 :)
--[[User:Natasab|Natasa]] 11:11, 21 December 2007 (CET)
 
::OK, agreed [[User:Rkiefl|Rupert]] 11:58, 21 December 2007 (CET)
 
 
 
== 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. --[[User:Natasab|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. --[[User:Inga|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
:::: [[User:Rkiefl|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 :) --[[User:Natasab|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? [[User:Rkiefl|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)
 
 
 
==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.  
--[[User:Natasab|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
=Discussion Functional Prototype=
- 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.
--[[User:Natasab|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==
==Meeting on Func. Prototype, 31.3.2008; Malte, Ulla and Nicole==
Would work only if the whole set of functionality is well understood by each developer and if each developer should read many pages.
:Notes added that will be resolved in implementation. Reference only for Rupert --[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
So should be in that case as a minimum be on a single page, but linked from each use case of relevance. --[[User:Natasab|Natasa]] 17:05, 16 January 2008 (CET)
*If it is not complicated from a technical point of view, we would like to integrate "fetch MD" to full submission, as specified in the functional  prototype. If this is the case the flow for create item has to be changed. The option to choose the submission method has to be added.
:Not certain if the prototype was understood well: to my understanding "fetch MD" leads to "full submission" and that is already specified in the easy submission prototype. In submission prototype this is to my understanding only clarification on the page flow. --[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*Decision: The messages from the func. spec. have to be referenced in the prototype. In addition to that Rupert can specify additional messages.
*re-name the menu entry "new submission" to "full submission"
:Proposal: why not then calling only "Submission" and "Advanced submission" respectively? --[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*please make sure, that even if only one collection exists, the user has the possibility to view the collection description (is valid create item flow and page flow)
:that is already included in edit item page. Is it meant that the user has the possibility to view the collection description in similar manner as in easy submission (if collectionNo=1 then display collection description and then continue to edit item?)--[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*add message if validation is not successful(?) not consistent - when only report, when report and message? (valid for page flow and flow submission and validate item flow)
:In my understanding: the report contains several statements that point to minimum 1 invalid metadata, the message is a single statement. --[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*unclear pageflow validate in https://zim01.gwdg.de/repos/smc/tags/public/PubMan/Prototypes/08_Submission/index.html
:please specify if this is unclear because of previous message vs. report point or in other manner?--[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*message for successful save needs prototype message ID (as there is no message in the UC)
*message for successful release is: MSG_PM_QA_08 please add to page flow
*edit item page: remove all languages except for language of publication and please add "English" as default value, please remove "--"
*edit item page: "cancel" leads to?
:should not it cancel the process of create/edit item and it should go back to where it was i.e. either "view item version page" or "depositor workspace" - is that the case?--[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*please specify what happens if the user clicks on "add more Orgs." in prototype for edit item
:as it may become very confusing using the Organization term for both "creators" and "affiliations" my proposal is to rename "Organization Name and Address" to "Affiliation Name and Address" and the button "Add more Orgs." to "Add Affiliations"--[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*typo file locator and remove MIME type
:Should not also the File name be removed from the edit form? (It will be defaulted to the value of the locator in the data which goes to the FW) --[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*proposal to make the difference between source MD and non source MD more clear, please add source in front of all labels
:Proposal: to add "Source" only in front of the "group labels" instead of every field (i.e. Source Details, Source Creators etc.)
*identifier: please remove ID Type "escidoc"
:Proposal: and specify the labels for identifier type and value correspondingly--[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*genre: default article, please remove "--"
*please add ID type and value to source
:But probably in this case "escidoc" identifier type can stay?--[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*add/remove forms:
**please add to the 2nd title "alternative"
**what means "the last form can not be removed? Is it not rather the first form?
**please remove the "remove" icon from the first form
*flow submit item:
**it is always the action submit and release
**analog to page flow 08_submission: connect submission comment and view item version(?)
:Please do not make changes on this - users will not always submit. Proposal/Email sent to GUI team on this topic also for easy submission flow. --[[User:Natasab|Natasa]] 09:52, 1 April 2008 (CEST)
*flow create new revision:
**please add reference to create item from template
**please re-formulate the comment to create new revision as specified in the UC_PM_SM_11 create new revision of item
*page flow (edit item)
**successor and error message(s) are missing

Latest revision as of 09:48, 26 January 2009

UC_PM_SM_01 create item[edit]

The user selects a collection where she wants to create a new item. With this action the publication workflow is started.

Status/Schedule[edit]

  • Status: in design
  • Schedule:R3

Triggers[edit]

  • The user wants to create a new item.
  • this use case may additionally be invoked by the following use cases:
    • create item from template
    • create new revision of an item
    • fetch metadata from external system

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • if this use case was invoked by another use case then a template item with default metadata and (optionally) a relation to an existing item is passed

Flow of Events[edit]

  • 1. The user chooses to create an item.
  • 2. The system displays a list of all collections and their description in state "opened" for which the user has the privileges as Depositor.
  • 3. The user selects a collection of her choice.
  • 4. continue with use case UC_PM_SM_02 edit item

Alternatives[edit]

  • 2a If the user has Depositor rights for only one collection, the collection selection is automatically performed by the system.
    • 2a.1. Continue with Flow of Events step 5.
  • 2b If the user has in his/her private preferences a target collection defined and the user has depositor privileges for that collection, the system automatically selects the collection.
    • 2b.1. Continue with Flow of Events step 5.
  • 2c The system may offer to the user the collection to where she last created the item successfully.
    • 2c.1 Continue with Flow of Events step 5.

Post-Conditions / Results[edit]

  • None

Future development[edit]

  • when creating new item default values for attributes and metadata values are inherited from the metadata set and the collection settings. Collection settings overwrite values inherited from the metadata set.

UC_PM_SM_02 edit item[edit]

The user edits the last version of an item while executing a task in the publication or in the modification workflow defined for the collection of the item.

Status/Schedule[edit]

  • Status: in design
  • Schedule:R3

Triggers[edit]

  • The user wants to change or provide data for an item.

Actors[edit]

  • Depositor
  • Moderator
  • Metadata Editor

Pre-Conditions[edit]

and (optionally) a template item (metadata and (optionally) relations) is passed

  • One validation point is selected.

Flow of Events[edit]

  • 3. The system displays an edit view with the metadata from the last version of the item or pre-filled metadata.
  • 7. (Optionally) Include use case UC_PM_SM_16 file upload
  • 8. (Optionally) The user enters a locator for the file, selects the visibility, adds a name and a comment and selects the content category (for R3 the content category can't be changed and is per default "supplementary material").
  • 5. (Optionally) The user edits the item attributes, adds new metadata values or modifies existing metadata values. This includes the selection of an entry from an authority file which is linked to a metadata element. For dealing with organizations when creating the metadata element "Organisation" see 11.2.
  • 6. (Optionally) The user chooses to view the collection description.
    • 6.1. The system displays the collection description.
  • 10. (Optionally) The user removes one or more uploaded files.
  • 11. Extension point: validate data.
    • 11.1. If the user wants to validate the data of the item include use case UC_PM_SM_09 validate item for the selected validation point.
  • 12.a. The user decides to finalize the editing of an item by submitting the item.
    • 12.a.1. The system creates a new version of an item. Continue with use case UC_PM_SM_03 submit item
    • 12.a.2. If the item version can not be created the system displays an appropriate error message or a validation report. The use case ends unsuccessfully.

Alternatives[edit]

  • 12.b. The user decides to finalize the editing of an item by saving the item without submitting.
    • 12.b.1. The system validates the item data against the default validation rules
    • 12.b.2. The system creates a new version of an item. The use case ends successfully.
    • 12.b.3. If the item version cannot be created the system displays an appropriate error message or a validation report. The use case ends unsuccessfully.

Post-Conditions / Results[edit]

  • A new item version is created and validated in accordance with selected validation point.

Future development[edit]

  • possible use case for look-up of metadata triggered during edit item to serve for fetching specific set of metadata e.g. source metadata(book, conference paper, event)
  • file locator - possible use case to specify a file locator for a fulltext such as:
  • 8. (Optionally) The user adds one or more file locators (from where the full text can be downloaded by PubMan and be integrated into PubMan) to the item.
    • 8.1. The system sets default values for file attributes from the collection settings and displays an edit view for the file.
    • 8.2. The user enters a locator for the file, selects the visibility if not already set and the content type.
    • 8.3. (Optionally) The user changes the visibility, the content type, the mime type or enters a description.
    • 8.4. The user confirms the entries.
    • 8.5. The system links the file to the item

Allowed file types[edit]

pdf, rtf, txt,doc, xml, jpg, bmp, png

(has to be enhanced!)

UC_PM_SM_03 submit item[edit]

The user submits the last version of the item.

Status/Schedule[edit]

  • Status: in design
  • Schedule:R3

Triggers[edit]

  • The user wants to submit the last version of an item.

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • Last item version is selected.
  • The last item version is in state "pending" or "in rework".
  • Depositor user is the owner of the last item version

Flow of Events[edit]

  • 1. The user chooses to submit the selected item or the item was selected by a previous use case.
  • 2. The system checks if the collection of the item is in state "opened" and if the user has the privilege as Depositor.
    • a. The collection is in state "opened" and the user has the privilege as Depositor.
    • b. The collection is not in state "opened". The systems displays an error message (MSG_PM_SM_02_A). The use case ends without success.
    • b. The user has not the privilege as Depositor. The systems displays an error message (MSG_PM_SM_02_B). The use case ends without success.
  • 3. The system validates the item for validation point "submit".
    • 3.a. The validation report status is valid.
    • 3.b. The validation report status is invalid. The selected item is unaffected. The system displays an error message (MSG_PM_SM_03). The use case ends without success.
  • 4. (Optionally) The user enters a comment for the submission.
  • 5. The user finalizes the submission.
  • 6. The system sets the status of the item version to "submitted".
  • 7. The system displays a success message (MSG_PM_SM_04). The use case ends successfully.

Alternatives[edit]

  • None

Post-Conditions / Results[edit]

  • The item version is in state "submitted".

UC_PM_SM_04 fetch metadata from external system[edit]

The system fetches metadata from an external system providing an external identifier. These metadata are used to populate metadata for a new item.

Status/Schedule[edit]

  • Status: in design
  • Schedule:R3

Triggers[edit]

  • The user wants to fetch the metadata for an item from an external system.

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • None

Flow of Events[edit]

  • 1. The user chooses to harvest (meta)data from an external service.
  • 2. The system displays a list of all available ingestion sources which provide an ID fetch method.
  • 3. The user selects one ingestion source and specifies an external ID appropriate to the selected ingestion source.
  • 4. The system checks if the selected ingestion source enables fetching of available fulltexts and offers to the user the possibility to decide on fulltext fetching.
    • 4.a. (optionally) The user decides to fetch one or more available fulltexts from the selected ingestion source.
  • 5. The system queries for item metadata with the specified ID.
    • 5.a. The system receives item metadata for the specified ID.
    • 5.b. The query fails. The system does not receive item metadata for the specified ID. The system displays an error message (MSG_PM_SM_10). The use case ends without success.
  • 6. (optionally) If the user decided to fetch one or more available fulltexts from the selected ingestion source, continue with the use case UC_PM_EASM_02 fetch fulltext by identifier.
  • 7. Continue with use case UC_PM_SM_02 edit item with fetched metadata values (and optionally fulltexts) .

Post-Conditions / Results[edit]

  • Fetched metadata (and optionally fulltexts) are used to create a new item.

Constraints[edit]

No ingestion sources are defined, only Identifiers from arXiv are considered.

See https://dev.livingreviews.org/projects/epubtk/browser/trunk/ePubTk/lib/arxiv.py for an example of how to use arxiv's oai-pmh interface.

Future Development[edit]

  • Add identifier type DOI (consider SFX and OpenURL?)
  • Allow fetching Metadata and fetching fulltext
  • Definition of ingestion sources, see PubMan Ingestion

UC_PM_SM_05 create item from template[edit]

The user creates a new item by using another item as a template and provides item data.

Status/Schedule[edit]

  • Status: in design
  • Schedule:R3

Triggers[edit]

  • The user wants to create a new item.

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • One item is selected.

Flow of Events[edit]

  • 1. The user chooses to create a new item from the selected item. The metadata values are taken from the selected item.
  • 2. Continue with use case UC_PM_SM_01 create item

Post-Conditions / Results[edit]

  • none

UC_PM_SM_06 delete item[edit]

The user deletes an item which is not released.

Status/Schedule[edit]

  • Status: implemented
  • Schedule:R1

Triggers[edit]

  • The user wants to delete an item.

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state "pending" or "in rework".
  • No item version in state "released" exists.
  • The user is the owner of the last version of the item.

Flow of Events[edit]

  • 1. The user chooses to delete the selected item or the item was selected by a previous use case.
  • 2. The system prompts the user to confirm the item deletion.
  • 3. The user confirms to delete the item.
  • 4. The system deletes the item and displays a success message (MSG_PM_SM_05). The use case ends successfully.

Post-Conditions / Results[edit]

  • The selected item is deleted.

UC_PM_SM_07 change collection of item[edit]

The user moves the item from one collection to another.

Status/Schedule[edit]

  • Status: not implemented
  • Schedule:to be defined

Triggers[edit]

  • The user wants to move the item from one collection to another.

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state "pending" or "in rework".
  • The user is the owner of the item.
  • The user is in role "Depositor" for more than one collection.

Flow of Events[edit]

  • 1. The user chooses to change the collection.
  • 2. The system displays a list of all collections in state "opened" for which the user has the privileges as Depositor.
  • 3. (optionally) The user chooses to view the collection description.
    • 3.1. The system displays the collection description.
  • 4. The user selects a collection and confirms the choice.
  • 5. The system checks the item data against values and functionality allowed by the collection.
    • a. The item data is in accordance with the allowed values and functionality of the collection.
    • b. The item data is not in accordance with the allowed values and functionality of the collection. The system displays an error message (MSG_PM_SM_06). The use case ends unsuccessfully.
  • 6. The system checks the item data against the default values of attributes and metadata definitions of the collection.
    • a. The item data is in accordance with the default values of the collection.
    • b. The item data is not in accordance with the default values of the collection. The system prompts the user to confirm that the item data is not overwritten.
      • 6.1. The user confirms not to overwrite the item data.
  • 7. The system changes the collection of the item and displays a success message (MSG_PM_SM_07). The use case ends successfully.

Alternatives[edit]

  • 6.b.1.a. The user confirms to overwrite the item data.
    • 1. The system overwrites the existing attribute values of the item with the collection’s settings for attribute values.
    • 2. The system overwrites the existing metadata values of the item with the collection settings for metadata values.
    • 3. The system creates a new item version, stores it and displays a success message (MSG_PM_SM_08) Continue with flow of events step 7.

Post-Conditions / Results[edit]

  • The item has been moved to another collection.

UC_PM_SM_09 validate item[edit]

The user wants to validate the last version of an item for the given validation point.

Status/Schedule[edit]

  • Status: in design
  • Schedule:R3

Triggers[edit]

Actors[edit]

  • Depositor
  • Metadata Editor
  • Moderator

Pre-Conditions[edit]

  • Last item version is selected.
  • One validation point is selected by the system.

Flow of Events[edit]

  • 1. The user decides to validate the last version of the item.
  • 2. The system checks the data of the last version of the item for missing values for obligatory metadata and further constraints defined for the selected validation point.
  • 3. The system generates an overview that contains the validation report.
  • 4. Use case ends successfully.

Post-Conditions / Results[edit]

  • None

Future development[edit]

  • The system identifies possible duplicate items and proceeds further with handling of duplicates. (UC_PM_SM_10 handle duplicate items.)

UC_PM_SM_11 create new revision of item[edit]

The user wants to create an intellectually revised item.

Status/Schedule[edit]

  • Status: in design
  • Schedule:R3

Triggers[edit]

  • The user creates a new item with a relation "isRevisionOf" to an existing item

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • Last item version is selected.
  • Last item version is in state "released".

Flow of Events[edit]

  • 1. The user chooses to create a new revision for the selected item version.
  • 2. Continue with the use UC_PM_SM_05 create item from template with the following metadata and the relation "isRevisionOf" to the selected item version used as a template:
  • Genre
  • Creator
  • Title
  • Language
  • AlternativeTitle
  • Subject

If the genre, that should be populated is not an allowed genre for the collection, the genre will not be populated.

Future Development[edit]

  • 2. The systems checks for existing items with a relation of type "isRevisionOf" to the selected item.
    • a. At least one item with relation of type "isRevisionOf" to the selected item exists. The system displays the list of these item(s).
    • b. No item with relation of type "isRevisionOf" to the selected item exists.
  • 3. The system prompts for a description of the relation and confirmation of the new revision.
  • 4. (optionally) The user enters a description for the relation.
  • 5. The user confirms the new revision.

Post-Conditions / Results[edit]

  • None

UC_PM_SM_12_file_upload[edit]

The user uploads a file and defines the visibility of the uploaded file.

Status/Schedule[edit]

  • Status: in design
  • Schedule:R3

Triggers[edit]

  • The user wants to upload one or more files.
  • This use case is included by the use case UC_PM_SM_02_edit_item

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • One collection is selected.

Flow of Events[edit]

  • 1. The user starts to upload one or more files to the system or for an item
    • 1.1 The system prompts for the path of the file.
    • 1.2 The user enters the path to the file and confirms the input.
    • 1.3 The system uploads the file.
    • 1.4 The system checks the size of the file against the defined maximum file size.
      • a. The file size is less or equal to the maximum file size.
      • b. The file size is greater than the maximum file size. The system discards the file and displays an error message. Continue with 1.
    • 1.6. The system identifies the mime type of the file and sets the information to the file.
    • 1.8. The system sets default values for file attributes (i.e. the file visibility) from the collection settings.
    • 1.9. The system displays an edit view for the file.
    • 1.10. The user selects the visibility if not already set and the content type.
    • 1.11. (Optionally) The user changes the visibility, the content type or enters a description.
    • 1.13. The user finalizes the entry.
  • 2. (Optionally) The user modifies the attributes of one file.
    • 2.1. The system displays an edit view for the file.
    • 2.2. (Optionally) The user changes the visibility, the content type, name of the file or enters a description.
      • 2.2.1. The system checks the change of the visibility.
        • c. Other changes of the visibility were done or the visibility has not changed.
    • 2.4. The user finalizes the entry.

Post-Conditions / Results[edit]

  • The files are uploaded to the system

Further development[edit]

  • Virus checking for uploaded files
    • 1.5. [Not R3] The system checks the file against viruses.
      • a. No Virus is found.
      • b. At least one virus is found. The system discards the file and displays an error message. Continue with 7.
    • 1.7. The system checks the mime type of the file against the recommended mime types.
      • a. The mime type is recommended.
      • b. The mime type is not recommended. The system displays a warning message.
  • Extraction of metadata and language identification from uploaded files

Visibility "OrgUnit" not yet provided by the framework:

    • 1.12. If the user has chosen the visibility "Organizational unit" the system shows a list of all open organizational units.
      • 1.12.1. The user selects one or more organizational units and confirms the choice.
      • 1.12.2. The system sets the file to be visible by the selected organizational units.
      • 2.2.1
        • a. The visibility has changed from "Organizational unit". The system removes the setting of organizational units for the visibility.
        • b. The visibility has changed to "Organizational unit". The system shows a list of all open organizational units.
          • i. The user selects one or more organizational units and confirms the choice.
          • ii. The system sets the file to be visible by the selected organizational units.
    • 2.3. (Optionally) The visibility is "Organizational unit" and the user chooses to change the organizational units the file is visible to.
      • 2.3.1. The system shows a list of all open organizational units.
      • 2.3.2. The user selects one or more organizational units and confirms the choice.
      • 2.3.3. The system sets the file to be visible by the selected organizational units.


Discussion Functional Prototype[edit]

Meeting on Func. Prototype, 31.3.2008; Malte, Ulla and Nicole[edit]

Notes added that will be resolved in implementation. Reference only for Rupert --Natasa 09:52, 1 April 2008 (CEST)
  • If it is not complicated from a technical point of view, we would like to integrate "fetch MD" to full submission, as specified in the functional prototype. If this is the case the flow for create item has to be changed. The option to choose the submission method has to be added.
Not certain if the prototype was understood well: to my understanding "fetch MD" leads to "full submission" and that is already specified in the easy submission prototype. In submission prototype this is to my understanding only clarification on the page flow. --Natasa 09:52, 1 April 2008 (CEST)
  • Decision: The messages from the func. spec. have to be referenced in the prototype. In addition to that Rupert can specify additional messages.
  • re-name the menu entry "new submission" to "full submission"
Proposal: why not then calling only "Submission" and "Advanced submission" respectively? --Natasa 09:52, 1 April 2008 (CEST)
  • please make sure, that even if only one collection exists, the user has the possibility to view the collection description (is valid create item flow and page flow)
that is already included in edit item page. Is it meant that the user has the possibility to view the collection description in similar manner as in easy submission (if collectionNo=1 then display collection description and then continue to edit item?)--Natasa 09:52, 1 April 2008 (CEST)
  • add message if validation is not successful(?) not consistent - when only report, when report and message? (valid for page flow and flow submission and validate item flow)
In my understanding: the report contains several statements that point to minimum 1 invalid metadata, the message is a single statement. --Natasa 09:52, 1 April 2008 (CEST)
please specify if this is unclear because of previous message vs. report point or in other manner?--Natasa 09:52, 1 April 2008 (CEST)
  • message for successful save needs prototype message ID (as there is no message in the UC)
  • message for successful release is: MSG_PM_QA_08 please add to page flow
  • edit item page: remove all languages except for language of publication and please add "English" as default value, please remove "--"
  • edit item page: "cancel" leads to?
should not it cancel the process of create/edit item and it should go back to where it was i.e. either "view item version page" or "depositor workspace" - is that the case?--Natasa 09:52, 1 April 2008 (CEST)
  • please specify what happens if the user clicks on "add more Orgs." in prototype for edit item
as it may become very confusing using the Organization term for both "creators" and "affiliations" my proposal is to rename "Organization Name and Address" to "Affiliation Name and Address" and the button "Add more Orgs." to "Add Affiliations"--Natasa 09:52, 1 April 2008 (CEST)
  • typo file locator and remove MIME type
Should not also the File name be removed from the edit form? (It will be defaulted to the value of the locator in the data which goes to the FW) --Natasa 09:52, 1 April 2008 (CEST)
  • proposal to make the difference between source MD and non source MD more clear, please add source in front of all labels
Proposal: to add "Source" only in front of the "group labels" instead of every field (i.e. Source Details, Source Creators etc.)
  • identifier: please remove ID Type "escidoc"
Proposal: and specify the labels for identifier type and value correspondingly--Natasa 09:52, 1 April 2008 (CEST)
  • genre: default article, please remove "--"
  • please add ID type and value to source
But probably in this case "escidoc" identifier type can stay?--Natasa 09:52, 1 April 2008 (CEST)
  • add/remove forms:
    • please add to the 2nd title "alternative"
    • what means "the last form can not be removed? Is it not rather the first form?
    • please remove the "remove" icon from the first form
  • flow submit item:
    • it is always the action submit and release
    • analog to page flow 08_submission: connect submission comment and view item version(?)
Please do not make changes on this - users will not always submit. Proposal/Email sent to GUI team on this topic also for easy submission flow. --Natasa 09:52, 1 April 2008 (CEST)
  • flow create new revision:
    • please add reference to create item from template
    • please re-formulate the comment to create new revision as specified in the UC_PM_SM_11 create new revision of item
  • page flow (edit item)
    • successor and error message(s) are missing

Use Case

Publication Management

Portable Document Format

Filename Extension for Text Files

Identifier

Digital Object Identifier

OpenURL Link Resolver

Open Uniform Resource Locator

Central European Summer Time

Metadata

Quality Assurance

Multipurpose Internet Mail Extensions

Graphical User Interface

Retrieved from "https://colab.mpdl.mpg.de/mw010/index.php?title=Talk:PubMan_Func_Spec_Submission&oldid=27030"