Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Participating Applications

  • CITI (Collections Management System)

  • Jira Service Desk (JSD)

  • NETX (Digital Asset Management System)

Types of request(6 Types)

  • 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 Customer form (Pre-population from CITI is not required)

    • Archive Photography

    • Non-Object Photography

    • Labwork(For data not in CITI)

Info

Note: Users are not allowed to input the id of the object and pull the information from CITI using the captions api rather CITI is going to make the GET call using the browser windows(tabs) and passed in the required parameters using URL itself.

Different Cases for Multi-Object and parent child scenarios -

Case Name(passed as parameter through url by CITI)

Case Details

case1

Parent and children having same values for fields except object ids (For Object Photography only)

case2

Parent and children having different values for form fields (For Object Photography only)

case3

Multi object scenario with all objects having same field values (For Object Photography and Labwork only)

case4

Multi object scenario with all objects having different field values (For Object Photography and Labwork only)

case5

Gallery Rotation Photography (For Gallery Rotation Photography only)

case6

Exhibition Photography (For Exhibition Photography only)

Ways in which request can be made from CITI -

Object Photography with multi object relationship

Type

Action

Details

URL to be called from CITI

Multi object scenario with all objects having same 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=case3&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&currentLocation=TX

Multi object scenario with all objects having different field values

User requests using the CITI app

Multiple tabs will be opened(limited to 10 per order) one for each object

Tab1 - {base_url}?type=case4&requestId=123&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&currentLocation=TX

Tab2 - {base_url}?type=case5&requestId=123&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&currentLocation=TX

Info

requestId - we need an identifier to link all these requests in JSD. This identifier should be common for all the requests across all the tabs.

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&currentLocation=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&currentLocation=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&currentLocation=TX

Info

Note : 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=case5&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=case6&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=case3&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

Tab 1 - {base_url}?type=case4&requestId=123&id=54324&title=Labwork%20title

Tab 2 - {base_url}?type=case4&requestId=123&id=54327&title=Labwork%20title1

Info

requestId - we need an identifier to link all these requests in JSD. This identifier should be common for all the requests across all the tabs.

Info

Note: For Archive photography, Non-Object photography 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 no need for pre-population of fields.

Types of Requests

Object

Exhibition

Gallery

Non-Object

Archive

Labwork(For Data in CITI)

Labwork(For Data not in CITI)

Parameters to be sent from CITI

Object Id
Title
Artist
Department
Object Type
Thumbnail Path
Parent Object Id
Dimensions
Current Location

Exhibition Id
Title
Opening Date
Closing Date
Curator
Place Id?Short Code in CITI
Place Name/Location

Exhibition Id
Title
Opening Date
Closing Date
Curator
Place Id?Short Code in CITI
Place Name/Location

NA(These requests will be initiated directly from JSD)

NA(These requests will be initiated directly from JSD)

title

NA(These requests will be initiated directly from JSD)

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

Other file naming suggestions -

  • Jira # combined with Linux Timestamp and without object id ex. JSD1_1604913106

  • Jira # combined with Linux Timestamp and with object id ex. JSD1_12345_1604913106 (This way we can trackback to the exact Jira ticket and Object Id)

  • Jira # combined with Linux Timestamp, object id and sequential numbers if there are more than one file name required under one ticket ex. JSD1_12345_1604913106#1, JSD1_12345_1604913106#2

  • Jira # combined with Linux Timestamp and sequential numbers if there are more than one file name required under one ticket ex. JSD1_1604913106#1, JSD1_1604913106#2.

We can mask the jira ticket number with some values so that we do not reveal the underlying JIRA ticket number for ex. JSD-1 can be masked to 101941 where 10, 19 and 4 are the position of the letters J, S and D respectively in the English alphabet system

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
 ]
…..
}