Is it possible / How To link a Version, already linked to Shot, also to an Asset?

[Cmq]

I’ve got Versions already linked to Shots, and also want them linked to Assets.
The goal is to be able to do this both manually and (preferrably) via SG’s REST API.

Curently I’m able to connect Versions to Shots via REST API as follows

curl -X PUT \
`${shotGridUrl}/api/v1/entity/versions/${versionId}` \
-H `Authorization: Bearer ${activeToken}`
-H `Accept: application/json` \
-H `Content-Type: application/json`
-d `${dataPackage}`

Where:

dataPackage={
	entity: { type: "Shot", id: shotId }
}

I’d like to simultaneously communicate something like the following

	entity: {type: "Asset", id: assetId}

[rob-aitchison]

Hi @Cmq ,

Do the Connection Entities help point you in the right direction for this?

https://help.autodesk.com/view/SGSUB/ENU/?guid=SG_Administrator_ar_site_configuration_ar_cross_project_asset_linking_html#using-connection-entities-to-track-cross-project-asset-linking

Let us know if that helps?
Thanks!

[Cmq]

@rob-aitchison Thanks. I checked enabled it, and the definitive answer is… MAYBE!
I’d already done a test in the REST API, which at first didn’t seem to work, but now shows that it did. I’m not sure if the success was something I missed earlier of if enabling cross-project-asset-linking made a difference somehow.

To be clear I’m not trying to track assets across multiple projects. The goal is to connect a Versions to both Shots and Assets.

The most important issue at the moment: How to use SG’s REST API to link a Version to a Shot and an Asset simultaneously. I haven’t been able to find anything in the documentation so far.

[Cmq]

@rob-aitchison Update: It actually did not help. So far I can only connect a Version to a Shot or to an Asset, but not both simultaneously.

via API I can push the id number into one of the two column in the attached screen grab, or the other, but not both.

Manually I can’t edit either

[nico.vandenbosch]

Your best recourse here would probably to add a new custom link field for the Asset link. Alternately, you might want to see if you can leverage the Task field to indirectly link to a task on the Asset (or Shot) since I don’t believe that SG enforces that Link and Task are on the same entity.

[Cmq]

@nico.vandenbosch Oh, interesting, in other words to do that is not baked into SG – not otherwise an option?

[nico.vandenbosch]

Hi @Cmq I can’t vouch for syntax in the rest api not having used it myself, but SG versions already support a Task field which itself is a separate entity that links back to either a shot or asset, so it could be hijacked to indirectly link the Version to another entity. This is stock functionality that doesn’t require any customization of the Version entity. If however you’re look for something a little more explicit and direct, you can also opt to make a custom new Entity field on version to hold the Asset link independently of the Shot link: Help

[rob-aitchison]

Thanks for jumping in as well @nico.vandenbosch !

@Cmq , I originally just wanted to point out that the

AssetAssetConnection and AssetShotConnection entities exist and may be something to look into more via the REST API.

If it is a workflow blocker, please do log a support ticket unless you find a workable solution.

Have a great day, thanks!

[Cmq]

@rob-aitchison AssetShotConection sounds intriguing though I think I’m after something else.

I tried the following on a lark:

Going back up to the top

curl -X PUT \
`${shotGridUrl}/api/v1/entity/versions/${versionId}` \
-H `Authorization: Bearer ${activeToken}`
-H `Accept: application/json` \
-H `Content-Type: application/json`
-d `${dataPackage}`

I tried

dataPackage={
	entity: [
		{ type: "Shot", id: shotId },
		{ type: "Asset", id: assetId }
	]
}

It didn’t work, but it didn’t error out either. It was just ignored.
In the world of databasing this kind of linking, where a single record from table A is linked simultaneously to tables B & C, is standard operating procedure. If SG doesn’t allow this by default, I imagine there’s a reason.

I’ll look into a support ticket and hopefully report back w/ progress

[parseyvfx]

I have been dealing with a similar issue myself, though doing it through the GUI rather than the API.

The default Link field “entity” that you’re trying to use, which is a SINGLE Entity Link field. Users cannot change this core default field in ShotGrid to my knowledge.

You need to create a custom Field of type Entity (single link) or Multi-Entity (multi-link) and then choose the Entity(ies) you want to be possible options for that link field (Asset in your case). I would name this field something useful like “Asset Link”, but I am admittedly archaic in being so simple and strict with field use.

Good luck!

P.S. @shotgrid_managers:

1. it is confusing that that the default underlying field name for the Link field on Versions is “entity” when Entities are a whole class unto themselves.

2. All Entity (linking) fields should probably be limited to a single Entity TYPE but allow multiple entries of that type. Multi-Entity fields that allow more than one TYPE of Entity are confusing and lead to convoluted schemes in the backend that, of course, we cannot see in a visual map form (like in FileMaker).

[Cmq]

@parseyvfx Yeah, so I did create a second Entity field (call it, for example, LinkVersionsToAssets), and used that to successfully link any given Version to both a Shot and an Asset.

The trick to making this work on the Asset side involved changing the filter detail page of the Assets table. By default that page filter sees versions related to the Current Asset. You have add an additional Filter Condition where LinkVersionToAssets is Current Asset and above Find Versions which match ANY of the following conditions

This, however, created a secondary problem:
When clicking to play a Version, results in a popup player overlay, in optional the right-side sidebar (aka “Show Details”), there’s a list of “Related Versions”. I’m not 100% sure what determines a “Related Version”, but it does not match the results of the above-described filter.

That’s an issue for a post sup. we’re working with who expects the Assets Detail’s list of versions to match the player’s sidebar list of “Related Versions”, so that’s the next step: Is there a way to control “Related Versions”

Posted this question as a separate thread.

[Ricardo_Musch]

I would be interested in understanding the “why” of this choice of workflow where 1 version related to an Asset and a Shot at the same time.

[Cmq]

Yeah, that’s good question. The VFX sup wanted to use Assets in a non-traditional way – as a means of viewing categories of media according to an evolving set of distinctions. We’re still at an early stage, before lock, where some shots are getting named and a few versions are getting turned in, others are unnamed and still in flux.

So what we’ve evolved toward is using Assets as way to create a certain amount of order from chaos: We can set up a category of any kind, throw any version, any files we want in there, named or not, give them a sort order (also in flux on a daily basis) so at his fingertips he can see what he wants in the way he wants.

[Ricardo_Musch]

Why not create “previz” or “concept” shots in this way?
At least if things are for Shots.
You can also create/use tools to copy versions from one shot/asset to the other so the related versions will be logical, but this creates duplicates which I’m not sure you want.

Doing things in a way the system was not designed for will run you into all these other issues.

[Cmq]

Why not create “previz” or “concept” shots in this way?

We could have, but the sup. didn’t want that. Assets was “what we have done in the past”, and in practice, in spite of the inappropriate use of the term “asset”, the system works pretty well.

At least if things are for Shots.

Often they are not. Over in Assets we have previz for scenes or episodes, lens grids and other camera tests, machine learning results, etc etc, even an Asset entry dedicated to “WTF is it this badly-labeled media for anyway?” where files are temporarily held while we sort things out.

It turns out linking a Version to both a Shot and an Asset is relatively easy to set up:

• Using an additional entity Field Versions whose relationship is to Assets (Call it LinkVersionsToAssets)
• Then in Assets Detail (as opposed to List) page, you define the Versions tab’s Filter to show both the default “Find Versions” where the Link is Current Asset AND where the LinkVersionToAssets is Current Asset.

You can also create/use tools to copy versions… but this creates duplicates which I’m not sure

Indeed, we didn’t want duplicates. By linking one Version both a Shot and Asset any Notes written to a particular Version is available in both contexts

Doing things in a way the system was not designed for will run you into all these other issues.

True enough, hence the questions posted here. Basically early on as things are more chaotic, yet-to-be defined and in flux, our mis-use of SG’s Assets gives us an ability to wrest order from chaos. As things fall into place, and we migrate towards a more Shots-centric way of organizing, we increasingly work in Shots. Having Versions that can simultaneously appear in both contexts makes the transition more coherent.

[Ricardo_Musch]

For sure, I’m not doubting the usefullness.

It would be nifty to know how Sg defines “Related Versions”.

[Cmq]

I’m pretty sure it’s the same as / similar to the default filter for the Shots Detail page’s Versions tab: ‘Show Versions whose value in Link matches Current Value in Link’

The only problem is it’s not editable