20.Function Requirement Analysis
Prerequisites to start the development
From Jira ServiceDesk
While Creating Jira Servicedesk Issue what are the mandatory fields and the maximum size of the attachment.
Exploring the Servicedesk API for creating the issue and adding the attachment.
Details of communication between different systems
CITI app API and fields details
Need to be communicated.
Jira API details and field details
While Creating issues the mandatory field is Summary
There are other fields also added in the create issue screen. But nothing is marked as mandatory. (Need to be checked what and all other fields are mandatory)
The Attachment file Size (while Creating issue it is mentioned as a note in that field)
Minimum Size | Maximum Size |
---|---|
10MB | 2GB |
Note: The Size of the attachment file can be changed.
4. API
Create customer request POST /rest/servicedeskapi/request
Request
EXAMPLE
{
"serviceDeskId": "10",
"requestTypeId": "25",
"requestFieldValues": {
"summary": "Request JSD help via REST",
"description": "I need a new mouse for my Mac"
},
"requestParticipants": [
"john"
]
}
Create attachment EXPERIMENTALPOST /rest/servicedeskapi/request/{issueIdOrKey}/attachment
Request
EXAMPLE
{
"temporaryAttachmentIds": [
"temp910441317820424274",
"temp3600755449679003114"
],
"public": true,
"additionalComment": {
"body": "Please find the screenshot and the log file attached."
}
}
NETX API and field details
put contents over here(also add a limit for attachment size/sync or async)
API
Authentication:
Hit the below endpoint URL with parameters to get sessionKey
URL: https://netxtest.artic.edu/external/api/json
Body Parameters (required):
id
method
params
dataContext
jsonrpc
Example:
Request:
{
"id":"13576991614322",
"method":"authenticate",
"params":["username", "password"],
"dataContext":"json",
"jsonrpc":"2.0"
}
Response:
Create Asset: 2 step process
Step 1: Upload files to NetX server using below endpoint URL and parameters:
Body Parameters (required):
Filename: file
sessionKey : sessionKey
categoryId : categoryId (folder id)
Filedata: file.jpg
Response from Postman:
<exogen>done</exogen> with 200 status code
Step 2: Hit the create asset API using the below endpoint URL
Body Parameters (required):
sessionKey : sessionKey
Filedata: file.jpg
categoryId : categoryId (folder id)
Example:
Request
Response
Get Asset:
Hit the below endpoint URL to get assets from specific folders
URL: https://netxtest.artic.edu/external/api/json
Body Parameters (required):
id
method
params
dataContext
jsonrpc
Example:
Request:
Response:
CITI to Jira Fields
CITI Fields | Jira Fields | |
---|---|---|
1 | Object ID | Object ID |
2 | Object title | Object title |
3 | Department | Object Department |
4 | Location/Place Name | Location/Place Name |
5 | Artist | Artist |
6 | Object Type | Object Type |
7 | Thumbnail path | Thumbnail path |
8 | Place ID/Place shortcut codes | Place ID |
9 | Exhibition ID | Exhibition ID |
10 | Exhibition Title | Exhibition Title |
11 | Exhibition Opening Date | Exhibition Opening Date |
12 | Exhibition Closing Date | Exhibition Closing Date |
13 | Exhibition Curator | Exhibition Curator |
Jira Fields to NetX
Jira Fields | NetX Fields | |
---|---|---|
1 | Object ID | Ryerson call number |
2 | Object ID | CITI relationships |
3 | Photographer assigned | Creator |
4 | Production staff assigned | Contributor |
5 | Description of views or details | Image view |
6 | Treatment status of conservation | Treatment status |
7 | Image capture light type | Image capture light type |
8 | Ticket number(Not in the Jira Test Instance) | Jira order number |
9 | Filename assigned by Jira(Not in the Jira Test Instance) | Preferred title |
10 | Filename assigned by Jira(Not in the Jira Test Instance) | Imaging UID |
Approaches for collecting data from CITI app
Using JSD forms
Steps | User clicks on the link in the CITI app to raise the request |
Pros | JSD will handle the creation of tickets through its internal mechanism and will take care of attachments if any automatically as a part of same form submission |
Cons | Pre-filling of fields is not supported. User will have to fill all the necessary details manually |
Using JSD create request api
Steps | User clicks on the link in the CITI app to raise the request |
Props | JSD will handle the creation of tickets through its internal mechanism and the caller app(CITI) will have full control over the entire process of redirection of the user after request is created in JSD |
Cons | -- |
Doubts and Clarifications
Questions | Details | Clarification | Status |
---|---|---|---|
What kind of mechanism do we want to use for making the request from CITI to JIRA? | Do we want to use JSD customer portal forms or do we want to use JSD create customer request api or both? Does it depend on the request type? | There maybe some scenarios in parent child relationship where we may have to go ahead with request apis but for most of the scenarios we will be using the JSD form with pre-filled values from CITI | Resolved |
On what event do we have to send data from JSD to CITI app? | After creation of a request? | We have to send the data from JSD to CITI at the end of the workflow when the ticket is closed. | Resolved |
What are the different types of scenarios we will encounter while making a request from CITI app to JSD for each request type? | parent/child relationship in orders | We have received the clarifications for all the request types | Resolved |
How are we going to capture different values for same field in a parent child relationship scenario? | For parent child scenario if the data for parent and child is passed in single tab and for some field/s if a parent has a different value than child then how are we going to handle this scenario? | Mostly the parent and child values remain same they differ in ids only and that should be captured in different text box in a csv delimited values | Resolved |
Whats a briefcase in CITI app? | In one of the mails it is mentioned that a briefcase in CITI app can be used to make an imaging order. Are there any other such features that we should know about? | Briefcase in CITI app is nothing but clubbing multiple objects from CITI into one request in JSD | Resolved |
What do you mean by dynamic functionalities of the form fields? | There are some places in mail chain where it mentions the term dynamic functionalities wrt JSD form fields. | Dynamic functionalities of the form means the ability of the JSD forms to validate the input or to pull the list of Users or list of issues and display them in the Issue picker or user picker respectively | Resolved |
Are the data points sent from CITI to JSD remain the same for different request types? | Object ID, Object title, Artist, Department, Object Type, Thumbnail path, Place ID/Place shortcut codes, Location/Place Name, Exhibition ID, Exhibition Title, Exhibition Opening Date, Exhibition Opening Date, Exhibition Closing Date, Exhibition Curator | They remain the same (only the actual values will differ). Also for one request type some proportion of these data points may be sent over to JSD and for other request type the remaining may be sent over for ex. for object photography the CITI app may send Object ID ,Object title, Artist, Department and Object Type, Thumbnail path but for conservation photography the CITI app may send Place ID/Place shortcut codes and Location/Place Name only | Resolved |
What logic we have to use to generate the file names for image records | The old phoenix used to generate file names based on image records. We have to confirm this logic while creating the ticket in jira |
| Unresolved |
What processing do we have to do for each step of the workflow for different request types? | There are seven request types each with its own workflows. We have to get a confirmation on what processing we have to do at each step of the workflow |
| Unresolved |
Do we have to handle the attachments at all? | Do we have to handle the upload,download, moving of attachments or will we be only involved in generating the names of images and pushing updates to and from JIRA? |
| Unresolved |
On what event do we have to send the information to NETX? | We have to confirm the event on which we have to send the data to NETX app |
| Unresolved |
Get confirmation on fields from and to NETX | We will have to get confirmation on which fields we will have to send to NETX and which fields we will be receiving from NETX and also how are we going to use this piece of information. |
| Unresolved |
Scenarios for handling multiple objects from CITI app
Briefcase Scenario(One JSD request with multiple objects) (Applicable for New Object Photography, Conservation Photography, Labwork)
Scenario | Each Object has same values for all fields in the JSD form | Each/Some Object/Objects has/have different field values in the JSD form |
Description | There should be a way for the CITI app to create multiple requests(tickets in JSD) using the JSD form for objects which have same values for all the fields in jsd form except the object ids which come from CITI app | There should be a way for the CITI app to create multiple requests(tickets in JSD) using the JSD form for objects which have different values for some or all of the fields on the JSD form. |
Conditions |
|
|
Ideas for implementation |
|
|
Request parameters | type=case4 ids=343432,54353,32133214,54325,432421(in single tab) | type=case5 id=65436 (tab1) |
Comments | Use the creation event to create the tickets in the JSD using the info from JSD form and different Object Ids | NA |
Parent/Child relationship(One JSD request with multiple children)(Applicable for New Object Photography, Conservation Photography)
Scenario | Parent and child objects have same values for all fields in the JSD form | Parent has different values for some or all fields when compared to children | Parent has same values for all fields as subset of children |
Description | There should be a way for the CITI app to create multiple requests(tickets in JSD) using the JSD form for objects which have parent child relationships and which have the same values for all the fields in the JSD form | There should be a way for the CITI app to create multiple requests(tickets in JSD) using the JSD form for objects which have parent child relationships in which parent has different values for some or all of the fields in JSD form while children themselves have same values for all the fields in the JSD form | There should be a way for the CITI app to create multiple requests(tickets in JSD) using the JSD form for objects which have parent child relationships in which parent has same values for all of the fields in JSD form as a subset children while the remaining children have different values for at least some of the JSD form fields |
Conditions |
|
|
|
Ideas for implementation |
|
|
|
Request parameters | type=case1 p=4232 c=43243,43214,4443,6543 (in single tab) | type=case3 p=4342 c=65436 (tab1) | type=case3 p=4342 c=65436 (tab1) |
Comments | Use the creation event to create the tickets in the JSD using the info from JSD form and different Object Ids | Use the creation event to create the tickets in the JSD for parent and child using the data from JSD form | Use the creation event to create the tickets in the JSD for parent and child using the data from JSD form |
Single request Scenario for each request type
Request Type | Object Photography/Conservation Photography | Gallery rotation | Exhibition | Labwork | Archive | Non-Object Photography |
Condition | There should be a text field in customer portal to capture the object id | There should a text field in customer portal to capture the object id | There should a text field in customer portal to capture the object id | There should a text field in customer portal to capture the object id | NA | NA |
Action | It opens a JSD(customer portal) form and pre-populates the data coming from CITI | It opens a JSD(customer portal) form and pre-populates the data coming from CITI | It opens a JSD(customer portal) form and pre-populates the data coming from CITI | It opens a JSD(customer portal) form and pre-populates the data coming from CITI | NA | NA |
CITI Metadata | title | Place ID/Place shortcut codes | Place ID/Place shortcut codes |
| NA | NA |
Comments | NA | NA | NA | NA | Out Of Scope as far as CITI integration is concerned | Out Of Scope as far as CITI integration is concerned |
Process for creating request by Manual entry of object ids in JSD portal (applicable for all request types)
Request Types | All request types except Non-Object Photography and Archive |
Process |
|
Implementation Details | We can make the call to the custom JSD api from Customer portal. The custom JSD api then can call the CITI’s caption api and return the response to the client code in the customer portal. |
Comment | Artic is yet to confirm this process as of 6th Nov 2020. They will be discussing with imaging team internally and will come with the confirmation. |
Process for generating file names (Awaiting confirmation from ARTIC as of 6th Nov 2020)
Ticket (job) is created
Jira autogenerates a filename starting with J (to be confirmed with Imaging team) and going up sequentially for each ticket submitted
First ticket should be J000001
It was noted during today's Imaging meeting that the autogenerating of filename happens at the time the Phoenix job is created. Phoenix creates a filename (sequentially based on time of job creation), stores it as a value in a field, and the Imaging team copies and pastes that value when naming the file on their server.
Autogenerated filename is added as a value in a field in Jira called "Filename information" or something like that
Imaging staff names the RAW file with the value provided in "Filename information" by copy and pasting (same as Phoenix currently) the field value when naming the file
Imaging staff uploads named RAW file to Jira to share with customer
Imaging staff names the final file to be uploaded into NetX "Filename information"-int For example, J000001-int
Jira pushes the final file (and relevant data) into NetX once the ticket is complete. Only files with "-int" included will be pushed to NetX. Imaging team to determine where they will be storing RAW and edited files.
Jira Issue Task List