...
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. | Unresolvedall 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? | UnresolvedMostly 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 |
...
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 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|