Participating Applications
CITI (Collections Management System)
JIra Service Desk (JSD)
NETX (Digital Asset Management Sytem)
Types of request which can be made from
Object Type Photography(same workflow as Conservation Photography)
Gallery Rotation Photography request
Exhibition Photography request
Labwork Request
Archive Request
Non-Object Photography
Ways to initiate a request for a asset through CITI for each request type
From CITI(Pre-population from CITI is required through GET request URL)
Object Photography
Exhibition Photography
Gallery Photography
Labwork(For data in CITI)
From JSD(Pre-population from CITI is not required)
Archive Photography
Non-Object Photography
Labwork(For data not in CITI)
Object Photography with multi object relationship
Type | Action | Details | URL to be called from CITI |
Multi object scenario with all children having same citi field values | User requests using the CITI app | User will perform an action in CITI app which will open a browser and a GET request will be made to JSD customer portal | {base_url}?type=case4&ids=43243,434213,432143,45325432&title=my%20object&artist=Bon%20Jovi&department=Imaging&objectType=2D&thumbnailPath=https%3A%2F%2Fblog.snappa.com%2Fwp-content%2Fuploads%2F2018%2F01%2Fyoutube-thumbnail-size.png&domensions=test¤tLocation=TX |
Multi object scenario with all children having different field values | User requests using the CITI app | Multiple tabs will be opened(limited to 10 per order) one for each object Do we have to link all of the resultant tickets in the backend? | Tab1 - {base_url}?type=case5&id=43243&title=my%20object&artist=Bon%20Jovi&department=Imaging&objectType=2D&thumbnailPath=https%3A%2F%2Fblog.snappa.com%2Fwp-content%2Fuploads%2F2018%2F01%2Fyoutube-thumbnail-size.png&dimensions=test¤tLocation=TX Tab2 - {base_url}?type=case5&id=53743&title=your%20object&artist=Picaso&department=Imaging&objectType=2D&thumbnailPath=https%3A%2F%2Fblog.snappa.com%2Fwp-content%2Fuploads%2F2018%2F01%2Fyoutube-thumbnail-size.png&dimensions=test¤tLocation=TX |
Object Photography with parent-child relationship
Type | Action | Details | URL to be called from CITI |
Parent and children having same values for fields | User requests using the CITI app | User will perform an action in CITI app which will open a browser and a GET request will be made to JSD customer portal | {base_url}?type=case1&ids=43243,434213,432143,45325432&title=my%20object&artist=Bon%20Jovi&department=Imaging&objectType=2D&thumbnailPath=https%3A%2F%2Fblog.snappa.com%2Fwp-content%2Fuploads%2F2018%2F01%2Fyoutube-thumbnail-size.png&domensions=test¤tLocation=TX |
Parent and children having different values for form fields | User requests using the CITI app | Multiple tabs will be opened(limited to 10 per order) one for each object | Tab1 - {base_url}?type=case2&parentId=43243&childId=65443&title=my%20object&artist=Bon%20Jovi&department=Imaging&objectType=2D&thumbnailPath=https%3A%2F%2Fblog.snappa.com%2Fwp-content%2Fuploads%2F2018%2F01%2Fyoutube-thumbnail-size.png&dimensions=test¤tLocation=TX Tab2 - {base_url}?type=case2&parentId=43243&childId=26553&title=your%20object&artist=Picaso&department=Imaging&objectType=2D&thumbnailPath=https%3A%2F%2Fblog.snappa.com%2Fwp-content%2Fuploads%2F2018%2F01%2Fyoutube-thumbnail-size.png&dimensions=test¤tLocation=TX |
Parent child relationship and multi-object scenarios are only valid for Object type photography
Gallery Rotation Photography
Action | Details | URL to be called from CITI |
User requests using the CITI app | User will perform an action in CITI app which will open a browser and a GET request will be made to JSD customer portal | {base_url}?type=case6&id=54324&placeId=Houma&location=Louisiana&title=Exb%20title&openingDate=2020-11-20&closingDate=2020-11-24&curator=John |
Exhibition Photography
Action | Details | URL to be called from CITI |
User requests using the CITI app | User will perform an action in CITI app which will open a browser and a GET request will be made to JSD customer portal | {base_url}?type=case7&id=54324&placeId=Houma&location=Louisiana&title=Exb%20title&openingDate=2020-11-20&closingDate=2020-11-24&curator=John |
Labwork(For Data in CITI)
Case | Action | Details | URL to be called from CITI |
Single order for object asset labwork, Exhibition asset labwork or gallery rotation asset labwork | User requests using the CITI app for data present in CITI app | User will perform an action in CITI app which will open a browser and a GET request will be made to JSD customer portal | {base_url}?type=case4&id=54324,54645,6543743,343254&title=Labwork%20title |
Multiple orders for object asset labwork, Exhibition asset labwork or gallery rotation asset labwork | User requests using the CITI app for data present in CITI app | User will perform an action in CITI app which will open a browser and a GET request will be made to JSD customer portal. All tickets should be related after submission How are we going to connect these requests? | Tab 1 - {base_url}?type=case4&id=54324&title=Labwork%20title Tab 2 - {base_url}?type=case4&id=54327&title=Labwork%20title1 Can we expect any other parameter in URL? |
For Archive, Non-Object and Labwork(For data not in CITI) users will directly visit JSD customer portal form and will fill in the details manually. For these there won’t be any data in CITI so there is not need for pre-population
File name generation process (For all the request types other than Labwork)
User will create a ticket in JSD using one of the request types
JSD will generate a file name using the following process
JSD will consider the ticket number of the current ticket for ex. JSD-1
JSD will also generate a string which will be equivalent to the Linux timestamp for ex. 1604906024
JSD will combine the ticket number JSD-1 with the linux timestamp → JSD-11604906024 or JSD11604906024 or 101941604906024(using positions of letters in English Alphabet system)
If there are more than one unique file name to be generated under each ticket than we can simply add _1, _2 after the filename generated in the above step
This process will help us track back the files by their names to the tickets in JSD
JSD will push this information to the field like “File Information“ or any other custom field/fields
Process for ingesting data in NETX
At the end of the workflow we can send the data over to NETX. Here JSD will search for the attachment with name ending with “-int“. This will be the final version of the asset which should be pushed to the NETX for ingestion. JSD will also update the NETX field “Incoming Relationship Data“ with json payload that will cover all the cases. for ex.
{ “JSDNumber": “JSD-11“, "timestamp": "2020-11-04T16:58:04.095Z”, “exhibition": [ 45, 32 ], “object": [ 12, 13, 14 ]…..}