Difference between revisions of "PubMan Func Spec Submission"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(181 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{PubMan_Funtional_Specification}}
{{PubMan_Funtional_Specification}}
==UC_PM_SM_01 create item==
The user creates a new item and provides item data. This use case starts the publication workflow for the new item.


'''[Start-Dev-QA]'''
==Submission Methods==
From the submission page, the user with depositor rights has the following options to create items in PubMan.
* via Easy Submission
** Easy Submission is a feature available for any user with depositing rights, ie. available for any collection.
** Easy Submission mask is divided into the following steps:
 
*** Genre, Title, Files
*** Authors and Affiliations
*** Source Details and Date
 


''Description is not very accurate. To consider: "The user selects a collection where she wants to create a new item and starts the publication workflow for the new item."''--[[User:Natasab|Natasa]] 12:40, 21 December 2007 (CET)
* via Full Submission
* via [[PubMan_Ingestion|Ingestion]]


''On the other hand, the use case create item has a very small difference to the use-case create item from template. A default metadata set inheritance can be always considered as a default item template. The user will always be able to have a choice to use  this default template (if it exists) or any other item as a template. ''--[[User:Natasab|Natasa]] 13:22, 21 December 2007 (CET)
'''


'''[End-Dev-QA]'''
==UC_PM_SM_01 create 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: '''implemented'''
*Schedule:'''R3'''
*Schedule:'''R3'''


===Triggers===
===Triggers===
*The user wants to create a new item.
*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===
===Actors===
Line 22: Line 35:


===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 and confirms the choice.
 
'''[Start-GUI-QA]'''
*''Select and confirm could be one action [[User:Rkiefl|Rupert]] 15:08, 28 December 2007 (CET)''
 
:''To my understanding, Rupert's proposal is not in conflict with the current use case because both actions are defined in one event. If usable "select and confirm" patterns are available we should use them'' --[[User:Inga|Inga]] 19:43, 30 December 2007 (CET)
 
'''[End-GUI-QA]'''
 
*5. The system creates a new item with the user as the owner in the selected collection. The item version is in state "pending" and 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.
 
'''[Start-Dev-QA]'''
 
*''Are pre-filled default metadata values genre independent?''
 
: ''We currently have no concrete example for default metadata values. The idea comes from our historical usage scenarios and concepts.'' --[[User:Inga|Inga]] 19:43, 30 December 2007 (CET)
 
*''Step 5 is actually internal creation of the value object and is not at all interesting for the user.''
 
:''This UC includes [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]] which is executed on an existing item. Therefore, an item is created in this UC, but not stored before UC_PM_SM_02 ends successfully. Please note that this approach is in sync with the naming of this UC. I believe that we all agreed to this split up before and would suggest to keep it.'' --[[User:Inga|Inga]] 20:12, 30 December 2007 (CET)
 
*''Another problem with Step 5 is that we do not define default metadata values in the metadata set. We may state for Step5: the system creates a new item with default values for attributes and metadata inherited from the collection settings. ''
 
: ''But we had the idea of default metadata values in relation to the metadata set before? If this is no longer the case, we indeed could make this and other sentences easier. The more complex description was only chosen to reflect the former concepts correctly. But why to delete the information about owner, selected collection and state?'' --[[User:Inga|Inga]] 19:43, 30 December 2007 (CET)
 
: ''Additional Note I: My suggestion would be to restrict QA to incorrect and incomprehensive terms only'' --[[User:Inga|Inga]] 19:43, 30 December 2007 (CET)
 
: ''Additional Note II: This way of inline commenting makes the use cases really hard to read. Shouldn't we consider to create a wiki page for each UC plus using the discussion page for comments?'' --[[User:Inga|Inga]] 19:46, 30 December 2007 (CET)
 
*''Step 5 may be specified as (in accordance with the comments in general use case description above): continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_05_create_item_from_template|UC_PM_SM_05_create_item_from_template]] with the default collection item selected as a template. The use case ends successfully (i.e. in this case no need for Step6)''
 
:''You mean that the default metadata values of a collection could be understood as default collection item? This is true, but brings another level of complexity because three UCs are called in sequence. This also would mean to select the collection twice. Actually, I'm quite fine with the current UCs, is it worth reworking?'' --[[User:Inga|Inga]] 21:32, 30 December 2007 (CET)
 
*''Is it mandatory that we provide default values for the users or allow them to choose? In this case Step 5 should be optional.'' --[[User:Natasab|Natasa]] 13:25, 21 December 2007 (CET)
 
:''This proposal is related to your comment above. If the creation of an item should no longer be described in "create item" then we could make step 5 optional. Anyway, I still would like to create the item here.'' --[[User:Inga|Inga]] 20:12, 30 December 2007 (CET)
 
'''[End-Dev-QA]'''
 
*6. 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.
 
'''[Start-Dev-QA]'''
 
''Step 6: The validation point is only known in the edit item use case i.e. if the user chooses to only save the item - validation point is not submit but "default". Only if users triggers the "submit" action, validation point "submit" is checked.'' --[[User:Natasab|Natasa]] 13:08, 21 December 2007 (CET)
 
:''The concept of a default validation point is new to me! In fact, the edit use case can be executed by various users at different stages in the publication and modification workflows. [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]] has an extension point "validate item" which should give users the option to check if the selected item already conform to the rules defined for the next workflow step. The relevant validation points are specified in the workflow diagrams (see Systemspecification_Pubman.doc). Therefore, we could delete the validation point information from here.'' --[[User:Inga|Inga]] 22:11, 30 December 2007 (CET)
 
:''BTW: If validation is not possible for a not stored item version, we should delete the extension point mentioned above from [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]]. It's quite reasonable that our users would be happy with an edit mask which has the required field marked as well. Anyway, this would be context/workflow stage dependent as well.'' --[[User:Inga|Inga]] 22:11, 30 December 2007 (CET)
 
'''[End-Dev-QA]'''


===Alternatives===
===Alternatives===
*2a If the user has Depositor rights for only one collection, the collection selection is automatically performed by the system.
*2a 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 5.
**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 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.
**1. Continue with Flow of Events step 5.
**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.


'''[Start-Dev-QA]'''
===Post-Conditions / Results===
 
*None
*''Note: There may be changes in user rights between the time user has stated the default depositing collection and the time of submission.''
 
:''Agreed and above description extended as suggested.'' --[[User:Inga|Inga]] 01:59, 31 December 2007 (CET)


*''Note: There is always a time lack between collection selection and the actual submission. We probably should extend step 2 in [[PubMan_Func_Spec_Submission#UC_PM_SM_03_submit_item|UC_PM_SM_03 submit item]] to check for user privileges again.'' --[[User:Inga|Inga]] 01:59, 31 December 2007 (CET)
===Future development===
 
*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.
*''Further Alternative:''
===Discussion===
**''Step4a: The user cancels the process of creating a new item. The use case ends without success.''
[[Talk:PubMan_Func_Spec_Submission#UC_PM_SM_01 create item]]
 
:''The functional team agreed not to explicitly describe each cancel action separately, but to assume that every started action can be canceled by the user. In fact, he/she can always close a browser window or use the browser buttons to return to the previous page. Could we make this note somewhere once instead of repeating the information in each UC?'' --[[User:Inga|Inga]] 02:33, 31 December 2007 (CET)
*''Further Alternative:''
**''Step5a.  Continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_04_fetch_metadata_from_external_system|UC_PM_SM_04_fetch_metadata_from_external_system]]. The use case ends successfully (i.e. in this case no need for step 6).  --[[User:Natasab|Natasa]] 13:15, 21 December 2007 (CET)
 
:''I agree that the fetch metadata trigger is 'closer' to [[UC_PM_SM_01_create_item]] then to [[UC_PM_SM_02_edit_item]]. We only put it to the second because we had the vision of a combined edit mask where you either could specify an identifier to fetch an existing record or enter the metadata manually... I guess we still have...'' --[[User:Inga|Inga]] 03:02, 31 December 2007 (CET)
 
'''[End-Dev-QA]'''
 
===Post-Conditions / Results===
*A new item with the user as the owner has been created.


==UC_PM_SM_02 edit item==
==UC_PM_SM_02 edit item==
Line 113: Line 63:
===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''R3'''
 
*Schedule:'''R5'''


===Triggers===
===Triggers===
*The user wants to change or provide data for an item.
*The user wants to change or provide data for an item.


*This use case is included by the use cases:
*This use case is invoked by the use cases:
**[[PubMan_Func_Spec_Submission#UC_PM_SM_01_create_item|UC_PM_SM_01 create item]], validation point: default (or depending on publication workflow)
**[[PubMan_Func_Spec_Submission#UC_PM_SM_01_create_item|UC_PM_SM_01 create item]]
**[[PubMan_Func_Spec_Submission#UC_PM_SM_05_create_item_from_template|UC_PM_SM_05 create item from template]], validation point: default (or depending on publication workflow)
**[[PubMan_Func_Spec_Submission#UC_PM_SM_05_create_item_from_template|UC_PM_SM_05 create item from template]]
**[[PubMan_Func_Spec_Submission#UC_PM_SM_11_create_new_revision_of_item|UC_PM_SM_11 create new revision of item]], validation point: default (or depending on publication workflow)
**[[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]], validation point: default (or depending on publication workflow)
**[[PubMan_Func_Spec_Quality_Assurance‎#UC_PM_QA_11_modify_item|UC_PM_QA_11 modify item]]
 
*This use case includes the use cases:
:''Note: should be better precised and clarified in general. ToDo DevTeam+FE''--[[User:Natasab|Natasa]] 14:32, 21 December 2007 (CET)
**[[PubMan_Func_Spec_Submission#UC_PM_SM_12_file_upload|UC_PM_SM_12 file upload ]]
 
:: ''I have no clue who added the references to the validation points and what the default validation point may be. Please note that the workflow diagrams provide information which validation point is relevant'' --[[User:Inga|Inga]] 20:26, 30 December 2007 (CET)
 
'''[Start-Dev-QA]'''
 
''See also comment for the use case fetch_metadata_from_external_system. Proposal to include this use case by fetch metadata use case and not to extend it. ''--[[User:Natasab|Natasa]] 14:05, 21 December 2007 (CET)
 
'''[End-Dev-QA]'''


===Actors===
===Actors===
Line 140: Line 83:


===Pre-Conditions===
===Pre-Conditions===
*One item is selected.
*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
: ''Last item version is selected ?''--[[User:Natasab|Natasa]] 14:39, 21 December 2007 (CET)
 
*One validation point is selected.
*One validation point is selected.
*The last item version is in state "pending", "in rework" or "submitted".


===Flow of Events===
===Flow of Events===
*1. The user chooses to edit the selected item or the item was selected by a previous use case.
*3. The system displays an edit view with the metadata from the last version of the item or pre-filled metadata.
*2. If this use case was not triggered by another use case, the system creates a new item version with the same state as the state of the previous version.
 
'''[Start-Dev-QA]'''
 
Proposal: remove Step2 --[[User:Natasab|Natasa]] 13:49, 21 December 2007 (CET)
 
'''[End-Dev-QA]'''
 
*3. The system displays an edit view for the last version of the item.
*4. Extension point: '''''fetch metadata'''''
**4.1. If this use case is triggered by the use case [[PubMan_Func_Spec_Submission#UC_PM_SM_01_create_item|UC_PM_SM_01 create item]] and the user wants to harvest metadata from an external system include use case [[PubMan_Func_Spec_Submission#UC_PM_SM_04_fetch_metadata_from_external_system|UC_PM_SM_04 fetch metadata from external system]] with selected collection as target collection.
 
'''[Start-Dev-QA]'''
 
Proposal: remove Step 4, 4.1 --[[User:Natasab|Natasa]] 13:49, 21 December 2007 (CET)
 
'''[End-Dev-QA]'''


*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 one or more file locators. He has the option to (8.1.) Save the locator or to (8.2.) upload the file.
**8.1. Save locator
***8.1.1 The user enters the loctor attributes. (in the manual easy submission the content category can't be changed and is per default "supplementary material")
**8.2. Upload locator
***8.2.1. The system tries to upload the file from the given locator. (The system only allows [[ Talk:PubMan_Func_Spec_Submission#Allowed_file_types | predefined mimetypes]] to fetch)
****8.2.1.1 The file is uploaded successfully. The system sets default values for file attributes from the collection settings and displays an edit view for the file. (Optionally) The user changes the visibility, the content type, the mime type, enters a description, chooses a CC License, enters a rights statement or enters a copyright date. Additionally there is also the possibility for the user to enter an embargo date, in case of the visibility is set on "restricted". (in the manual easy submission the content category can't be changed and is per default "supplementary material")
****8.2.2.1 The file upload fails. The user get the corrsponding message ([[PubMan_System_Messages | MSG_PM_SM_08]])
*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.
**6.1. The system displays the collection description.
**6.1. The system displays the collection description.
*7. (Optionally) The user adds one or more files to the item.
*10. (Optionally) The user removes one or more uploaded files.
**7.1. The system prompts for the path of the file.
*11. Extension point: '''''validate data'''''.
**7.2. The user enters the path to the file and confirms the input.
**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.
**7.3. The system uploads the file.
*12.a. The user decides to finalize the editing of an item by submitting the item.
**7.4. The system checks the size of the file against the defined maximum file size.
**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]]
***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 (''visibility''--[[User:Natasab|Natasa]] 14:05, 21 December 2007 (CET)) from the collection settings.
**7.9. The system displays an edit view for the file.


'''[Start-Dev-QA]'''
**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.


Proposal: rework Steps 7-9.4 as separate use case(s) all steps regarding file-handling should be separate system use case --[[User:Natasab|Natasa]] 13:49, 21 December 2007 (CET)
===Alternatives===
 
*12.b. The user decides to finalize the editing of an item by saving the item without submitting.
'''[End-Dev-QA]'''
**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.
**7.10. The user selects the visibility if not already set and the content type.
**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.
**7.11. (Optionally) The user changes the visibility, the content type, the mime type or enters a description.
*12.c. The user decides to finalize the editing of an item by accepting the item.
**7.12. If the user has chosen the visibility "Organizational unit" the system shows a list of all open organizational units.
**12.c.1. The system validates the item data against the default validation rules for the validation point "submit".
***7.12.1. The user selects one or more organizational units and confirms the choice.
** 12.c.2. The system creates a new version of an item in status "submitted". Continue with use case [[PubMan_Func_Spec_Quality_Assurance#UC_PM_QA_03_accept_item|UC_PM_QA_03 accept item]].
***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.
 
: ''Does it mean the system stores the file locator only? If the system looks for the file/downloads it I would recommend to confirm right after typing the locator just to save work if the link is somehow wrong.'' [[User:Rkiefl|Rupert]] 07:10, 29 December 2007 (CET)
 
*8. (Optionally) The user adds one or more file locators 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.
*9. (Optionally) The user modifies the attributes of one file.
**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.
*10. (Optionally) The user removes one file.
*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.
*12. The user chooses to finalize the work process by saving the item data.
*13. The system checks if any edit changes were done.
**13.1. If any edit changes were done, the system creates and stores the item version.
**13.2. If no changes were done, the system displays an error message (MSG_PM_SM_09). Continue with step 3.
*14. The system displays a success message (MSG_PM_SM_01). The use case ends successfully.


===Post-Conditions / Results===
===Post-Conditions / Results===
*A new item version is created and validated in accordance with selected validation point.
*A new item version is created and validated in accordance with selected validation point.
===Future development===
*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)
===Discussion===
[[Talk:PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item]]


==UC_PM_SM_03 submit item==
==UC_PM_SM_03 submit item==
Line 239: Line 130:
===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''R3'''
*Schedule:'''R5'''


===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)


===Actors===
===Actors===
Line 250: Line 139:


===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?''
 
*''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 this specific exception in step 2 of the flow of event, see proposal below.'' --[[User:Inga|Inga]] 02:18, 31 December 2007 (CET)


===Flow of Events===
===Flow of Events===
*1. The user chooses to submit the selected item or the item was selected by a previous use case.
*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".
*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".
**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). 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.
*3. Include use case [[PubMan_Func_Spec_Submission#UC_PM_SM_09_validate_item|UC_PM_SM_09 validate item]] for validation point "submit".
**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.
*4. The system checks the validation report status.
*3. The system validates the item for validation point "submit".
**a. The validation report status is valid.
**3.a. The validation report status is valid.
**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.
**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.
*5. The system prompts for a confirmation of the submission.
*4.    Before the item is submitted an information message shows up: "You are going to submit/release an item with rights information. Please be aware that you have checked these information!"
*6. (Optionally) The user enters a comment for the submission.
**a.   These information message shows up only if the user provides rights information (CC License, rights statement, date copyrighted) for the submitted item and its component(s).
*7. The user confirms the submission.
*5. (Optionally) The user enters a comment for the submission.
 
*6. The user finalizes the submission.
'''[Start-Dev-QA]'''<br>
*7. The system sets the status of the item version to "submitted".
''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>
*8. The system displays a success message ([[PubMan_System_Messages|MSG_PM_SM_04]]). The use case ends successfully.
'''[End-Dev-QA]'''<br>
*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".


==UC_PM_SM_04 fetch metadata from external system==
===Discussion===
The system fetches metadata from an external system providing an external identifier. These metadata are used to populate metadata for a new item.
[[Talk:PubMan_Func_Spec_Submission#UC_PM_SM_03_submit_item]]


'''[Start-Dev-QA]'''


''Proposal: The "fetch" metadata is actually a single item ingestion. Should be excluded from UC_PM_SM_02_edit_item and included as separate start use-case (such as create item, create item from template) because it raises a lot of complexity in edit item.''--[[User:Natasab|Natasa]] 13:52, 21 December 2007 (CET)
==UC_PM_SM_04 create item from template==
 
The user creates a new item by using another item as a template and provides item data.
'''[End-Dev-QA]'''


===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''implemented'''
*Schedule:'''R3'''
*Schedule:'''R3'''
===Triggers===
*The user wants to fetch the metadata of an item from an external system.
*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]].  ''Proposal: remove the inclusion in edit item use case, but do it vice-versa.'' --[[User:Natasab|Natasa]] 15:16, 21 December 2007 (CET)
===Actors===
*Depositor
===Pre-Conditions===
*One item is selected.
*The item is not persistent.
*The user is the owner of the item version.
'''[QA-Dev-Start]'''<br/>
*''One collection is selected'' --[[User:Natasab|Natasa]] 15:32, 21 December 2007 (CET)
'''[QA-Dev-End]'''<br/>
===Flow of Events===
*1. The user chooses to harvest metadata 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. The user confirms the input.
*4. The system queries for item metadata with the specified ID.
**4.a. The system receives item metadata for the specified ID and transforms the received metadata to metadata values of the internal metadata set. These metadata values overwrite the existing metadata values of the item. The use case ends successfully.
'''[QA-Dev-Start]'''
''Proposal: Instead "use case ends successfully" use "Continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item|UC_PM_SM_02 edit item]] "'' --[[User:Natasab|Natasa]] 15:31, 21 December 2007 (CET)
'''[QA-Dev-End]'''
**b. The query fails. The system does not receive item metadata for the specified ID. The system displays an error message. Continue with step 2.
===Post-Conditions / Results===
*Fetched metadata are transferred to the item version.
==UC_PM_SM_05 create item from template==
The user creates a new item by using another item as a template and provides item data.
===Status/Schedule===
*Status: '''not implemented'''
*Schedule:'''to be defined'''


===Triggers===
===Triggers===
*The user wants to create a new item.
*The user wants to create a new item.
[Dev-QA-Start]
*''This use case is included by the use case [[PubMan_Func_Spec_Submission#UC_PM_SM_01_create_item|UC_PM_SM_01_create_item]]''--[[User:Natasab|Natasa]] 15:40, 21 December 2007 (CET)
[Dev-QA-Start]


===Actors===
===Actors===
Line 355: Line 185:


===Flow of Events===
===Flow of Events===
*1. The user chooses to create a new item 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. The system displays a list of all collections for which the user has the privileges as Depositor.
*2. Continue with use case [[PubMan_Func_Spec_Submission#UC_PM_SM_01_create_item|UC_PM_SM_01 create item]]
*3. (optionally) The user chooses to view the collection description.
**3.1. The system displays the collection description.
*4. The user selects a collection as target collection and confirms the choice.
*5. The system creates a new item with the user as the owner in the target collection. The item version is in state "pending" and default values for attributes are inherited from the target collection settings. The metadata values are taken from the selected item.
*6. 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.


===Alternatives===
===Post-Conditions / Results===
*2a If the user has Depositor rights for only one collection, the collection selection is automatically performed by the system.
*none
**1. Continue with Flow of Events step 5.
*2b 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 5.
 
'''[QA-Dev-Start]'''
''*2c  If the collection was already selected with a previous use-case continue with Flow of Events step 5.''--[[User:Natasab|Natasa]] 15:37, 21 December 2007 (CET)
'''[QA-Dev-End]'''


===Post-Conditions / Results===
===Discussion===
*A new item with the user as owner has been created.
[[Talk:PubMan_Func_Spec_Submission#UC_PM_SM_05_create_item_from_template]]


==UC_PM_SM_06 delete item==
==UC_PM_SM_05 delete item==
The user deletes an item which is not released.
The user deletes an item which is not released.


Line 399: Line 217:
*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==
===Discussion===
[[Talk:PubMan_Func_Spec_Submission#UC_PM_SM_06_delete_item]]
 
==UC_PM_SM_06 change collection of item==
The user moves the item from one collection to another.
The user moves the item from one collection to another.


Line 431: Line 252:
*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===
*6.b.1.a. The user confirms to overwrite the item data.  
*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.
**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==
===Discussion===
The last version of an item has to be validated.
[[Talk:PubMan_Func_Spec_Submission#UC_PM_SM_07_change_collection_of_item]]
 
==UC_PM_SM_07 validate item==
The user wants to validate the last version of an item for the given validation point.


===Status/Schedule===
===Status/Schedule===
*Status: '''implemented'''
*Status: '''implemented'''
*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


==UC_PM_SM_11 create new revision of item==
===Future development===
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 system identifies possible duplicate items and proceeds further with handling of duplicates. (UC_PM_SM_10 handle duplicate items.)
 
===Discussion===
[[Talk:PubMan_Func_Spec_Submission#UC_PM_SM_09_validate_item]]
 
==UC_PM_SM_08 create new revision of item==
The user wants to create an intellectually revised item.


===Status/Schedule===
===Status/Schedule===
*Status: '''in specification'''
*Status: '''implemented'''
*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 489: Line 321:


===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)
 
*At least one item version is in state "released".
*Last 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.
:*     Genre
*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) ''
*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 517: Line 336:
:* 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.
 
===Future Development===
*Pre-check for related revisions:
 
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.
 
*Possibility to explicitely relate revisions


''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) for 2 existing items and not only during creation of the new item - - UC_PM_SM_XX set item as revision of an item


===Alternative===
b) from easy submission, when user start to create item (either by ArXiv, bibtex upload or manual)
*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
===Discussion===
[[Talk:PubMan_Func_Spec_Submission#UC_PM_SM_11_create_new_revision_of_item]]
 
==UC_PM_SM_09 file_upload==
The user uploads a file and defines the visibility of the uploaded file.
 
===Status/Schedule===
* Status: '''in specification'''
* Schedule:'''R5'''
 
===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]]
 
===Actors===
*Depositor
 
===Pre-Conditions===
*One collection is selected.
=== 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, enters a description, chooses a CC License, enters a rights statement or enters a copyright date. Additionally there is also the possibility for the user to enter an embargo date, in case of the visibility is set on "restricted".
**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, enters a description, chooses a CC License, enters a rights statement or enters a copyright date. Additionally there is also the possibility for the user to enter an embargo date, in case of the visibility is set on "restricted"
***2.2.1. The system checks the change of the visibility and/or other metadata.
****c. Other changes of the visibility were done or the visibility has not changed.
**2.4. The user finalizes the entry.
 
===Post-Conditions / Results===
* The files are uploaded to the system
 
===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
 
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===
[[Talk:PubMan_Func_Spec_Submission#UC_PM_SM_12_file_upload]]


==Additional Information==
==Additional Information==
Line 539: Line 435:
To provide information for the metadata element "Organization" the user has to select an organizational unit from the organizational unit structure. In this case for every path of the selected organizational unit in the organizational unit structure (an organizational unit can have more than one parent organizational unit) a metadata value "Organization" is created by the system. If only one "Organization" is allowed, only one metadata value "Organization" is created for the path taken by the user to select the organizational unit. The "Name" value is derived from the organizational unit path, the "Address" value is copied from the selected organizational unit. Additionally a link to the selected organizational unit is created by copying the organizational unit id. Afterwards the user can edit the name and the address of the organization or delete a complete organization. The modified values are stored in the metadata set, the data in the organizational unit structure is unaffected.
To provide information for the metadata element "Organization" the user has to select an organizational unit from the organizational unit structure. In this case for every path of the selected organizational unit in the organizational unit structure (an organizational unit can have more than one parent organizational unit) a metadata value "Organization" is created by the system. If only one "Organization" is allowed, only one metadata value "Organization" is created for the path taken by the user to select the organizational unit. The "Name" value is derived from the organizational unit path, the "Address" value is copied from the selected organizational unit. Additionally a link to the selected organizational unit is created by copying the organizational unit id. Afterwards the user can edit the name and the address of the organization or delete a complete organization. The modified values are stored in the metadata set, the data in the organizational unit structure is unaffected.


[[Category:PubMan]]
===Workflows===
[[Category:Functional_specification]]
Please see [[PubMan_Workflows|PubMan Workflows]]
 
===File attributes===
 
Please see [[PubMan_File_Properties| PubMan File Properties]]
 
==HTML Prototype==
 
* The publicly available '''HTML prototype for submission''' and for other functionalities can be accessed from here: [[ESciDoc_Prototyping#PubMan_Prototype|eSciDoc Prototyping]].
 
[[Category:PubMan_Functional_Specification|Submission]]

Latest revision as of 09:24, 1 September 2009

PubMan Functional Specification

View · Browse
Full Submission · Easy Submission
Import · Export
Quality Assurance · Search
Collaboration · Copyright
Collection Administration
Organizational Unit Management
User Management
Feeding local webpages
History of affiliations


edit


Submission Methods[edit]

From the submission page, the user with depositor rights has the following options to create items in PubMan.

  • via Easy Submission
    • Easy Submission is a feature available for any user with depositing rights, ie. available for any collection.
    • Easy Submission mask is divided into the following steps:
      • Genre, Title, Files
      • Authors and Affiliations
      • Source Details and Date


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: implemented
  • 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.

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_01 create item

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 specification
  • Schedule:R5

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 one or more file locators. He has the option to (8.1.) Save the locator or to (8.2.) upload the file.
    • 8.1. Save locator
      • 8.1.1 The user enters the loctor attributes. (in the manual easy submission the content category can't be changed and is per default "supplementary material")
    • 8.2. Upload locator
      • 8.2.1. The system tries to upload the file from the given locator. (The system only allows predefined mimetypes to fetch)
        • 8.2.1.1 The file is uploaded successfully. The system sets default values for file attributes from the collection settings and displays an edit view for the file. (Optionally) The user changes the visibility, the content type, the mime type, enters a description, chooses a CC License, enters a rights statement or enters a copyright date. Additionally there is also the possibility for the user to enter an embargo date, in case of the visibility is set on "restricted". (in the manual easy submission the content category can't be changed and is per default "supplementary material")
        • 8.2.2.1 The file upload fails. The user get the corrsponding message ( MSG_PM_SM_08)
  • 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.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.
  • 12.c. The user decides to finalize the editing of an item by accepting the item.
    • 12.c.1. The system validates the item data against the default validation rules for the validation point "submit".
    • 12.c.2. The system creates a new version of an item in status "submitted". Continue with use case UC_PM_QA_03 accept item.

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)

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item

UC_PM_SM_03 submit item[edit]

The user submits the last version of the item.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:R5

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. Before the item is submitted an information message shows up: "You are going to submit/release an item with rights information. Please be aware that you have checked these information!"
    • a. These information message shows up only if the user provides rights information (CC License, rights statement, date copyrighted) for the submitted item and its component(s).
  • 5. (Optionally) The user enters a comment for the submission.
  • 6. The user finalizes the submission.
  • 7. The system sets the status of the item version to "submitted".
  • 8. 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".

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_03_submit_item


UC_PM_SM_04 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: implemented
  • 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

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_05_create_item_from_template

UC_PM_SM_05 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.

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_06_delete_item

UC_PM_SM_06 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.

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_07_change_collection_of_item

UC_PM_SM_07 validate item[edit]

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

Status/Schedule[edit]

  • Status: implemented
  • 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.)

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_09_validate_item

UC_PM_SM_08 create new revision of item[edit]

The user wants to create an intellectually revised item.

Status/Schedule[edit]

  • Status: implemented
  • 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]

  • Pre-check for related revisions:

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.

  • Possibility to explicitely relate revisions

a) for 2 existing items and not only during creation of the new item - - UC_PM_SM_XX set item as revision of an item

b) from easy submission, when user start to create item (either by ArXiv, bibtex upload or manual)

Post-Conditions / Results[edit]

  • None

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_11_create_new_revision_of_item

UC_PM_SM_09 file_upload[edit]

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

Status/Schedule[edit]

  • Status: in specification
  • Schedule:R5

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, enters a description, chooses a CC License, enters a rights statement or enters a copyright date. Additionally there is also the possibility for the user to enter an embargo date, in case of the visibility is set on "restricted".
    • 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, enters a description, chooses a CC License, enters a rights statement or enters a copyright date. Additionally there is also the possibility for the user to enter an embargo date, in case of the visibility is set on "restricted"
      • 2.2.1. The system checks the change of the visibility and/or other metadata.
        • 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[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_12_file_upload

Additional Information[edit]

Submission activities[edit]

https://zim01.gwdg.de/repos/smc/tags/public/PubMan/Submission_activities.gif

Figure: Graphical representation of the submission activities in PubMan

Creating organizations in Metadata[edit]

To provide information for the metadata element "Organization" the user has to select an organizational unit from the organizational unit structure. In this case for every path of the selected organizational unit in the organizational unit structure (an organizational unit can have more than one parent organizational unit) a metadata value "Organization" is created by the system. If only one "Organization" is allowed, only one metadata value "Organization" is created for the path taken by the user to select the organizational unit. The "Name" value is derived from the organizational unit path, the "Address" value is copied from the selected organizational unit. Additionally a link to the selected organizational unit is created by copying the organizational unit id. Afterwards the user can edit the name and the address of the organization or delete a complete organization. The modified values are stored in the metadata set, the data in the organizational unit structure is unaffected.

Workflows[edit]

Please see PubMan Workflows

File attributes[edit]

Please see PubMan File Properties

HTML Prototype[edit]

  • The publicly available HTML prototype for submission and for other functionalities can be accessed from here: eSciDoc Prototyping.

Publication Management

Use Case

Creative Common

Hypertext Markup Language

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