...
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? | UnresolvedWe 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 new object photography request type. Waiting for others now. | Unresolved | Whats a briefcase in CITI app? | In one of the mails it is 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 | Transitions of requests through different workflows and process to follow for each workflow | Unresolved | Communication NETX api | Unresolved |
Scenarios for handling multiple objects from CITI app (Applicable for New Object Photography, )
Briefcase Scenario(One JSD request with multiple objects)
...
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
...
A single fields should be there to capture different object ids in the form of some delimited values ex. Textbox(43243,54254,65433)
...
Details of each object has to be passed in separate tab
...
Ideas for implementation
...
It opens a single JSD form
It captures the object ids in the text box as delimited values and rest of the data remains same
...
It will open one JSD forms in each tab for each corresponding object id
User has to enter multiple details pertaining to each object in each tab separately
...
Request parameters
...
type=case4 ids=343432,54353,32133214,54325,432421(in single tab)
...
type=case5 id=65436 (tab1)
type=case5 id=65437 (tab2)
...
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)
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 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 in and which parent has have the same values for all of the fields in the JSD form as a subset children while the remaining children have different values for at least some of the JSD form fields | Conditions | Only the object ids differ and rest of the data remains same | 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
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|