...
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.CITI will only be passing us the object ids in the URL. Rest of the information about the object will have to pulled from CITI’s captions api itself |
Steps for pre-population of data (Valid for Object, Exhibition,Gallery and Labwork(For data in CITI) 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 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
User will now fill the rest of the form and will submit the ticket
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) |
...
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 | {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¤tLocation=TX | Create one ticket for the request and for each object in the request create a sub-task for the main ticket and copy over all the details from main ticket. Main ticket should be closed when all sub-task tickets are closed Filenames are generated for each sub-tasks | ||
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¤tLocation=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¤tLocation=TX
| One main ticket will be created and all the tickets will be sub-tasks for the main ticket Main ticket should be closed when all sub-task tickets are closed Filenames are generated for each sub-tasks |
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}?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 | Create one main ticket for the request. For parent and each child object in the request create a sub-task under the main ticket. Main ticket should be closed when all sub-task tickets are closed Filenames are generated for each sub-tasks |
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 | Create one main ticket for the request. For parent and each child object in the request create a sub-task under the main ticket. Main ticket should be closed when all sub-task tickets are closed Filenames are generated for each sub-tasks |
| Info |
|---|
Note : Parent child relationship and multi-object scenarios are only valid for Object type 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 |
|---|
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. |
| Info |
|---|
For all labwork orders we will pull in the following fields from NETX on initiation of request - File Size, dimensions, Resolution, Color Profile, Digital Asset, Creation Date, Original Source, Make, Model, Modified date, MIME type, Focal Length, Aperture and Document Type |
| Info |
|---|
When an ticket is completed we will have to pull the NETX link of the asset into one of the fields in JIRA |
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 | Exhibition Id | Exhibition Id | NA(These requests will be initiated directly from JSD) | NA(These requests will be initiated directly from JSD) | title assetId | NA(These requests will be initiated directly from JSD) |
...
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 part of the current Jira ticket for ex. JSD1234 in IMAGEREQ-11234
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.
...
prepend 'J' to the start of the number part. for ex J1234
Now for each option selected in the below fields, JSD is going to generate a unique filename by generating sequential number prepended by '_'
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)
For ex. Let us assume that there are three options checked in ‘Description of views or details', yes for ‘360 spin needed?’ and two options checked for 'Image capture light type’ then there will be six filenames generated as follows J1234_1, J1234_2, J1234_3, J1234_4, J1234_5, J1234_6
JSD will push all the generated filenames in the “File Information“ Jira Field in the CSV format
Process for ingesting data in NETX
...
{ “JSDNumber": “JSD-11“, "timestamp": "2020-11-04T16:58:04.095Z”, “exhibition": [ 45, 32 ], “object": [ 12, 13, 14 ]…..}
Mapping between Jira and NETX fields to be used while pushing the data to NETX
Jira Field | NETX Field |
|---|---|
Filename assigned by Jira | Preferred title |
Filename assigned by Jira | Imaging UID |
Object ID (for Ryerson content) | Ryerson call number |
Object ID | Object ID |
Exhibition ID | Exhibition ID |
Place ID | Place ID |
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 |