New post
11

Project specific customization (entities, fields, statuses, and steps)

Avatar
Ben Hadden
Completed
Follow

The goal is to allow clients to go ahead and build out some project customization w/out breaking the "core" configuration. Often specific projects will require workflows and custom fields/entities that others do not. It's nice to allow for that w/out cluttering up the rest of the site. It's also a way for people to migrate away from legacy that they're iterating on w/out feeling they need a new instance.

In v1 of project specific customization we will include:

- Ability to enable/disable entity types per project

- Ability to enable/disable custom fields per project

- Ability to enable disable pipeline steps per project

- Ability to enable disable specific statuses in status fields per project




Tracking - Fields.jpg
Tracking - Steps.jpg
Tracking -Statuses.jpg
Date Votes

14 comments

  • 0
    Avatar
    Avi Katz

    Hi Ben,
    Would it be possible to have fields displayed by user classes in the UI? I.e. a field important to an Artist would not be seen by an Artist.

     

  • 0
    Avatar
    Ben Hadden

    Hi Avi,

    Have you explored using "Permissions" to do this? In the User Settings menu -> Permissions area you can hide fields from specific permission groups. This prevents those permission groups from seeing those fields in any project. What this feature would do is hide fields within a project, so any permission group, regardless of whether they can see the field globally, would not see the field in the UI.

    Let me know if that's right.

  • 0
    Avatar
    Permanently deleted user

    A couple more thoughts:
    - admin's should be able to globally mark fields/status/steps as turned off by default for new projects to allow migration from legacy
    - when a project configuration is pushed or a project is created based on a templates the per project customization should be included
    - fields/status/steps should just be hidden in the UI (ie a user can't choose to add them as a field to a view/filter) but still be fully accessible via the API so that existing code doesn't break

    Thanks
    Patrick

  • 0
    Avatar
    Ben Hadden

    Hey Patrick,

    That all makes sense. Thanks for adding those details!

    About this one:

    - admin's should be able to globally mark fields/status/steps as turned off by default for new projects to allow migration from legacy

    Do you guys create your projects from the same Layout Template each time? If you turn fields/steps/statuses off in that template, any new project would have them off. Curious if that would be a solution to this issue.

  • 0
    Avatar
    Permanently deleted user

    Most of the time projects are actually generated based on old projects and not based on templates as the templates tend to get out of date.
    So you are correct. Making a proper template and encourage users to base new projects of it would mean that the admin option isn't needed.

    The reason for the idea was my concern how to sync these changes across many active projects and how to keep an overview.
    How about this idea:
    Status/Fields/Steps are all entities. So you could add two fields to them "Include Projects" / "Exclude Projects".
    All the UI in your screenshots is doing is filling in these fields.
    This allows Admin's to manipulate these fields directly for many projects at once.
    And this allows everybody to get an overview which fields are used where etc.
    If both fields are empty the Status/Fields/Steps  are shown in all projects.

  • 0
    Avatar
    Ben Hadden

    Status/Fields/Steps are all entities. So you could add two fields to them "Include Projects" / "Exclude Projects".

    Exactly! I was thinking along those lines. For Fields and Steps, that makes sense. Might get tricky for Statuses. "In Progress", for example, might be both in the Status field and Delivery Status field on the Shot. But we'll think through that one a little more.

    I think supporting this on list pages of Fields and Steps would make sense for sure, though.

  • 0
    Avatar
    Permanently deleted user

    Great. The association status <> projects could just mean if a status could be picked in the status configuration dialog within the project (see screen shot)

     

  • 0
    Avatar
    Ben Hadden

    Great, makes sense. Would we also remove it from any Status type fields where it was configured?

    Also, our original plan was to just have this setting control the official "Status" field on each entity, rather than custom Status fields. That would have made this a lot simpler, and would allow for your idea to work both in the field itself and the status picker. At your studio (and anyone else in this thread), do you add additional Status type fields to records? Would you need per-project control over them?

  • 0
    Avatar
    Permanently deleted user

    Yes if a status field is removed it disappears from all fields were it was used. I guess it boils down to: "With great power comes great responsibility" :)

    We do have a "custom status" fields here and there but we for sure would not need per project settings for these in the first iteration and maybe ever.

  • 0
    Avatar
    Alexandra Lefève-Gourmelon

    Hi Ben,

    Would it be possible to set User Roles by Project too ?

    For example, a user can be Manager on a Project but only Graphist on another Project. It would be very useful for companies with numerous Commercial projects.

     

    Cheers,

    Alex

  • 0
    Avatar
    Ben Hadden

    Hi Alexandra,

    That request has come up, so you're definitely not alone in wanting this. Our design team has some concerns on this one, mainly that a user might get confused about what they can do in one project vs in another. Imagine you're a manager with full editing rights in one project, but then you switch to another and find that you can't do nearly as much. It might be jarring, so we'll need to work that issue out.

    But to get the full picture, can you give me some examples of what you'd expect the Graphist to do in Project A and the Manager to do in Project B?

  • 0
    Avatar
    Alexandra Lefève-Gourmelon

    Hi Ben,

     

    Actually, our users are used to have less permissions in our other applications when they're not Managers, and they don't complain about it, so I guess they find it more secure. When somebody needs more permissions, we set his role to Manager and he knows he must be careful (as Patrick said ;) ).

    Here aresome examples :

    What the Graphist can do in Project A :

    - add Time Log to Tasks

    - update a Task status (but ideally, some statuses should be excluded for Graphists, like cmpt, for example)

    - add Notes to Tasks

     

    What the Manager can do in Project B :

    - assign Tasks

    - add people to his Group

    - create/update Assets/Shots/Sequences/Tasks

    - add Notes to Assets/Shots/Sequences/Tasks

  • 0
    Avatar
    Ben Hadden

    Hey everyone,

    I'm pleased to announce that v1 of project-specific customization is now available!

    https://support.shotgunsoftware.com/entries/103872613-5-4-Release-Notes

    In v1, we allow you to hide entities, fields, steps, and statuses. We know there's more to do (framerate, permissions, etc), so we encourage you to create new feature requests for each of those so we can track / discuss them.

    Hope you enjoy the new features in 5.4!

  • 0
    Avatar
    Alex Meddick

    I'd like to suggest a next step for project specific customisation in this feature request:

    https://support.shotgunsoftware.com/entries/104218933-Project-Specific-List-Fields

    Please add your support if you think it is a good idea :D.

Please sign in to leave a comment.