Skip to main content

Move Product naming profiles from ayon-core to project Anatomy

Maintaining naming conventions and product names in project Anatomy as well as ayon-core is a fragmented workflow. Product Names are used as actual tokens in the Anatomy, so it makes more sense that these live in the project’s Anatomy instead of the ayon-core.

Affects
Core
Status: Rejected5 comments

Log in to comment and vote

Comments5

  • Milan Kolar

    Team

    @Aleks Berland This will not be possible to move to anatomy. Apart from the reasons mentioned by Murphy, the biggest different between settings and anatomy is that settings allow us to be granular with profile targeting. Creating a different Product name for the same product type depending on what DCC or what task type it’s being published from is crucial for more complex workflows that AYON allows studios to build. Anatomy is dedicated to project configuration that doesn’t need to adjust often and where we don’t need more detailed filtering.

  • Martin Ličko (murphy)

    Team

    I would keep the generic, studio wide settings separate from Anatomy for sure. Can not imagine studio with hundreds of projects fiddling with naming profiles on a project level.

    Needles to say we have many fragmented settings in AYON and it should be streamlined for sure, but this particular one is there for a good reason imo.

  • Mustafa Zaky Jafar

    Team

    Adding my 2 cents, From my perspective if I’m not mistaken,
    This idea seems reasonable to have all of the bits of the naming convention workflow in one place.

    However, there are two reasons that may make it difficult:

    1. The project anatomy is used for defining configurations to use in your project either on the AYON server or via AYON Pipeline. e.g. link types, tags and statuses. but itself doesn’t specify how to use them.

    2. The system is deeply built considering the templates are defined in anatomy and they are used in core settings.

    • Aleks Berland

      @Martin Ličko (murphy) I offer these thoughts to consider, I hope they are helpful!

      • Anatomy is already per project. We are already expected to manage this through projects and a “studio-wide” ability to save presets… but this doesn’t affect anything, as its just a copy and paste.

      • Creating the templates for studio or project is a delicate process, difficult to test at scale, and complicated deeply by hybrid tokens like product names and the ayon-core’s Product Name profiles

      • There is a murky relationship between publish instance naming and product names / product name profiles. This tends to compound the issues and writing of the most common custom AYON development, the creation of create, load, and publish plugins and actions.

      • This adds yet another layer of under the hood complexity depending on the state of a host integration or during addon development in general, downloading responsibility to code that is intended to be agnostically using the template system instead of making esoteric logic to ensure tokens are correct etc.

      • Mustafa Zaky Jafar

        Team

        I believe what Murphy is trying to say that project anatomy is per project only.

        while settings can be studio wise and project wise.

        This means I can define the usage of templates in studio settings which will be automatically used for all of projects by default.