Make list field project unique

I coun’d find smilar quesions here, so I’d like to ask that: Is it possible to make list filed project unique? Because, our shotgun users demands tend to change options with pull down menu, which is project unique(So we don’t want shotgun to share exactly same list contents with other projects).
If it’s not, how does anyone else solve it?

3 Likes

On the new feature request site, someone has requested exactly this. It’d be worth registering your interest on there

5 Likes

Thanks Gary. I missed the site items… I’ll send my request there.

4 Likes

Thanks for posting! As @Gary says it’s something we’re currently looking into. Would be good to hear about the kinds of things you’re hoping to be able to do here if you have a moment.

2 Likes

Since you asked @jack, our main issue with this is the Type field on Assets.

In general all of our Shotgun projects get customised differently, lots of stuff changes from one pipeline to another especially between films/shows/shorts. This causes trouble with our Type list field on Assets, because a tv series might want “01 Main Character, 02 Secondary Character, 03 Background Character” while a film might just have “01 Characters, 02 Props, 03 FX”. We could technically have these options side by side, (ie. Make “01 Main Character, 02 Secondary Character, 03 Background Character, 01 Characters, 02 Props, 03 FX” all options) but in practice that ends up being messy and confusing.

We usually end up having to make new project specific asset fields when a new project insists they have distinct Type options. But long term, we’re concerned this will be a messy solution if we end up having 10 different type fields for 10 different projects, all with unique names.

4 Likes

I’ll also mention that I’ve seen this be a common need amongst our games clients, since they might have one project with Asset Types like Player, Equipment and Arena, and another project with Asset Types like Human, Alien, Planet, and Spaceship. Of course these can be abstracted to some degree into more generic types, but then you get into the need for sub-type fields, which have even more of a need to customize per Project. The most common current solution is to make a bunch of Project-specific fields for sub-type and other project-specific metadata, which can get pretty messy to manage over time.

Thanks for the feedback all, keep it coming!

1 Like

Given this limitation with list fields, we use Custom Entities where we need per-project values.

For example our clients require specific terminology for Versions delivered to them. We made a custom entity called ‘Client Sub Type’ and added an entity-link field to Versions. Each project creates as many 'Client Sub Type’s as needed.

The trick is to get these entity-link fields to behave like a list, where all options are displayed
when the field is being edited. If you start by typing a dash ‘-’ then all entities for the current Project will be displayed. See example gif:

4 Likes