/
40.Document Of Understanding

40.Document Of Understanding

1. Participating Applications

  • CITI (Collections Management System)

  • Jira Service Desk (JSD)

  • NETX (Digital Asset Management System)

2. Types of request(8 Types)

  • Object Type Photography(same workflow as Conservation Photography)

  • Gallery Rotation Photography request

  • Exhibition Photography request

  • Collections Labwork Request

  • Collections Archive Request 

  • Non-Collections Labwork Request

  • Non-Collections Archive Request 

  • Non-Object Photography

3. 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

    • Collections Labwork Request(For data in CITI)

    • Collections Archive Photography Request

  • From JSD Customer form (Pre-population from CITI is not required)

    • Non-Collections Archive Photography Request 

    • Non-Object Photography

    • Non-Collections Labwork Request

Note: CITI will only be passing the object ids or exhibition ids or asset ids in the URL. Rest of the information about the object will have to pulled from CITI’s captions api itself. For asset ids the information should be pulled from NETX post creation of the ticket

4. Steps for pre-population of data (Valid for Object, Exhibition,Gallery, Collections Archive and Collections Labwork photography only)

  • User will perform some action in CITI which will open up tab(tabs) in the user’s browser

  • CITI app will pass object ids or exhibition ids or asset ids in the URL

  • JSD will capture these ids in the url and will make calls to CITI’s caption api to get the details

  • JSD will populate the customer portal form with data pulled from captions api (For asset id/s the data should be pulled from NEXT rather than CITI api but this should happen post creation of the ticket in JSD)

  • User will now fill the rest of the form and will submit the ticket

5. Different Cases for Multi-Object and parent child scenarios -

Case Name(passed as parameter through url by CITI)

Case Details

Case Name(passed as parameter through url by CITI)

Case Details

parentChildType1

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

parentChildType2

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

mutiObjectType1

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

mutiObjectType2

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

multiAssetType1

Multi asset scenario with all assets having same field values (For Collections Labwork only)

multiAssetType2

Multi asset scenario with all assets having different field values (For Collections Labwork only)

galleryRotation

Gallery Rotation Photography (For Gallery Rotation Photography only)

exhibition

Exhibition Photography (For Exhibition Photography only)

mutiObjectType3

Multi object scenario with all objects having same field values (For collections archive Photography)

mutiObjectType4

Multi object scenario with all objects having different field values (For non-collections archive Photography)

archiveRequestForGalleryRotation

Collections Archive Request for Gallery rotation only

archiveRequestForExhibition

Collections Archive Request for Exhibition only

6. Ways in which request can be made from CITI -

The creation of sub-tasks depends on values of three fields. They are as follows
Description of View Or Details (Checklist control)
360 spin requested? (Radio control)
Image Capture light type (Checklist control)

6.1 Object Photography with multi object relationship

Type

Action

Details

URL to be called from CITI

Process of creation of tickets in JIRA

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
(There will be only one tab)

{base_url}?requestType=mutiObjectType1&ids=43243,434213,432143,45325432&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Create one ticket for the request on submission
Create N sub-tasks each for the combination objectid, light type, 360 spin and view type requested
Copy the information from parent ticket to each sub task
Filenames are generated for each sub-tasks but not for the parent ticket
Parent ticket should be closed when all the sub tasks are closed
Filenames are generated for each sub-tasks but not for the main ticket

RequestId = UUID identifier for identifying the request

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}?requestType=mutiObjectType2&id=43243&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Tab2 - {base_url}?requestType=mutiObjectType2&id=53743&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Create one ticket for each request submission(Each Tab)
Create N sub-tasks(for each ticket) each for the combination objectid, 360 spin, light type and view type requested
Main ticket should be closed when all sub-task tickets are closed
Filenames are generated for each sub-tasks but not for the main ticket

RequestId = UUID identifier for identifying the request

6.2 Object Photography with parent-child relationship

Type

Action

Details

URL to be called from CITI

Process of creation of tickets in JIRA

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}?requestType=parentChildType1&patentid=53432&childIds=43243,434213,432143,45325432&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

On submission creates a single ticket for all order information in it
For each object requested create a sub-task for the combination of ObjectId, 360 spin, view details and light type
Summary of the child sub-task should contain the summary of the parent + objectid + (the light type or view details or 360 spin)
Main ticket should be closed when all sub-task tickets are closed
Filenames are generated for each sub-tasks but not for the main ticket

RequestId = UUID identifier for identifying the request

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}?requestType=parentChildType2&parentId=43243&childId=65443&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Tab2 - {base_url}?requestType=parentChildType2&parentId=43243&childId=26553&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Create one ticket for each request submission(Each Tab)
Create N sub-tasks(for each ticket) each for the combination objectid, 360 spin, light type and view type requested
Main ticket should be closed when all sub-task tickets are closed
Filenames are generated for each sub-tasks but not for the main ticket

RequestId = UUID identifier for identifying the request

Note : Parent child relationship and multi-object scenarios are only valid for Object type photography

6.3 Gallery Rotation Photography

Action

Details

URL to be called from CITI

Process of creation of tickets in JIRA

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}?requestType=galleryRotation&id=54324&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

On submission create a single ticket with all order information in it
Create one filename for this ticket
No sub-tasks are required

RequestId = UUID identifier for identifying the request

6.4 Exhibition Photography

Action

Details

URL to be called from CITI

Process of creation of tickets in JIRA

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}?requestType=exhibition&id=54324&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

On submission create a single ticket with all order information in it
Create one filename for this ticket
No sub-tasks are required

RequestId = UUID identifier for identifying the request

6.5 Collections Archive Photography(For Data in CITI)

Action

Details

URL to be called from CITI

Process of creation of tickets in JIRA

Multi object scenario with all objects having same field values

User will perform an action in CITI app which will open a browser and a GET request will be made to JSD customer portal using 'Archive Request' menu item in CITI

{base_url}?requestType=mutiObjectType3&ids=43243,434213,432143,45325432&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Create one ticket for the request on submission
Create N sub-tasks each for the combination objectid, light type, 360 spin and view type requested
Copy the information from parent ticket to each sub task
Filenames are generated for each sub-tasks but not for the parent ticket
Parent ticket should be closed when all the sub tasks are closed
Filenames are generated for each sub-tasks but not for the main ticket

RequestId = UUID identifier for identifying the request

Multi object scenario with all objects having different field values

Multiple tabs will be opened(limited to 10 per order) one for each object (Action from CITI = 'Archive Request')

Tab1 - {base_url}?requestType=mutiObjectType4&id=43243&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Tab2 - {base_url}?requestType=mutiObjectType4&id=53743&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Create one ticket for each request submission(Each Tab)
Create N sub-tasks(for each ticket) each for the combination objectid, 360 spin, light type and view type requested
Main ticket should be closed when all sub-task tickets are closed
Filenames are generated for each sub-tasks but not for the main ticket

RequestId = UUID identifier for identifying the request

User requests using the CITI app (CITI menu = Archive request)

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}?requestType=archiveRequestForGalleryRotation&id=54324&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

On submission create a single ticket with all order information in it
Create one filename for this ticket
No sub-tasks are required

RequestId = UUID identifier for identifying the request

User requests using the CITI app (CITI menu = Archive request)

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}?requestType=archiveRequestForExhibition&id=54324&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

On submission create a single ticket with all order information in it
Create one filename for this ticket
No sub-tasks are required

RequestId = UUID identifier for identifying the request

6.6 Collections Labwork Request

Case

Action

Details

URL to be called from CITI

Process of creation of tickets in JIRA

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}?requestType=mutiAssetType1&ids=54324,54645,6543743,343254&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Create one ticket for the request on submission
Create N sub-tasks each for the combination objectid, light type, 360 spin and view type requested
Copy the information from parent ticket to each sub task
Filenames are not generated for the sub-tasks
Parent ticket should be closed when all the sub tasks are closed

RequestId = UUID identifier for identifying the request

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}?requestType=mutiAssetType2&id=54324&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Tab 2 - {base_url}?requestType=mutiAssetType2&id=54327&requestId=6948DF80-14BD-4E04-8842-7668D9C001F5

Create one ticket for each request submission(Each Tab)
Create N sub-tasks(for each ticket) each for the combination objectid, 360 spin, light type and view type requested
Main ticket should be closed when all sub-task tickets are closed
Filenames are not generated for the sub-tasks

RequestId = UUID identifier for identifying the request

 

7. Fields which should be pulled from CITI using captions api

Types of Requests

Object

Exhibition

Gallery

Non-Object

Collections Archive

Non-Collections Archive

Collections Labwork

Non-collection Labwork

Parameters to be pulled 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
Gallery

Exhibition Id
Title
Opening Date
Closing Date
Curator
Place Id?Short Code in CITI
Gallery

NA(These requests will be initiated directly from JSD)

Object title / exhibition title

NA(These requests will be initiated directly from JSD)

assetId

NA(These requests will be initiated directly from JSD)

 

8. 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

  • filenames will be created

    • For Object type photography and Labwork Phtography

      • JSD will create N number of sub tasks for each combination of following fields

        • Object Id

        • Description of views or details (Checklist. add a view for each option checked)

        • 360 spin needed? (Radio button. If yes, add a view)

        • Image capture light type (Checklist. add a view for each option checked)

      • JSD will generate a unique filename for each of these sub-tasks by taking into account the sub-task ticket number and prepending ‘J' to it for ex. if sub-task ticket number is IMAGEREQ-22 then the generated filename will be 'J22’

      • JSD will push this filename information in “File Information“ field for the corresponding sub-task

    • For Exhibition, Gallery Rotation and Collections Archive Photography request

      • JSD will generate a single file name for the ticket using the ticket number and character 'J', ex. if the ticket number is IMAGEREQ-78 then the generated filename will be 'J78’

      • JSD will push this filename information in “File Information“ field for the ticket

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

10. Mapping between Jira and NETX fields to be used while pushing the data to NETX

Jira Field

NETX Field

Jira Field

NETX Field

Filename assigned by Jira

Preferred title

Filename assigned by Jira

Imaging UID

Photographer assigned

Creator

Production staff assigned

Contributor

Description of views or details

Image view

Treatment status of conservation

Treatment status

Image capture light type

Image capture light type

Jira Ticket number

Jira order number

Jira customer request type

Document type

Description

Description

Staff models

Individual(s) depicted

Original source

Original source

Analog asset creation date

Analog asset creation date

Setup

Setup

Composite?

This image is a composite

Composite type?

Primary method of composite

Permissible use

Permissible use

Download requirements

Download requirements

Reviewed

Reviewed

Jira timestamp for QC status

Reviewed date

Publish status

Publish status

Note :- Field may not be required. This can be generated dynamically at the time of NETX push

Incoming Relationship Data