Enforcing project and shot naming convention?

[keyframe]

Heya everyone,

Apologies for the rudimentary question.  Is it possible to enforce a naming convention for projects at creation time?  Ideally i'm hoping to use something like this as a filter:

re_valid_project_name = re.compile(r'^[0-9a-z_-]+\_\d{6}$')

For a brief time, I thought maybe http://ftrack.rtd.ftrack.com/en/3.5.0/developing/events/list.html#ftrack-validate would be what i'm after, but it seems that this event isn't published to the python api.

Any thoughts would be greatly appreciated.

Cheers,

G

ps: running 3.5.9 on a local deployment, in case it matters.

[Mattias Lagergren]

For a local deployment it is possible to override the create project dialog with your own - and make the validations that way.  You can find more information here: http://ftrack.rtd.ftrack.com/en/stable/administering/managing_local_installation/configuring_server_options.html#override-the-default-create-project-behavior

Other alternatives are to setup an event listener and validate the project name. If not valide you can change it or ask the user to change it via a triggered action interface.

[keyframe]

Thanks for the link.  It's just what we were looking for.

G

[keyframe]

Heya Mattias,

Thanks for the hint regarding the ftrack.create_project_action_identifier.  It works perfectly for our needs.

Any chance that such a facility exists for other entity types such as shot and sequence?
The closest I've been able to get thus far is listening for ftrack.update events and retroactively removing 'badly named' entities using

session.delete(pooly_named_entity)
session.commit()

Ideally, these entities would be prevented from being created in the first place.

G

[Eric Hermelin]

Hi,

Currently this does not exists for other entities, we are however discussing different approaches for allowing this in the future. In the meantime you could perhaps ( provided the entity was created through the web interface ) create send back some feedback to the user with something like:

        session.delete(
            task
        )

        event = ftrack_api.event.base.Event(
            topic='ftrack.action.trigger-user-interface',
            data={
                'type': 'message',
                'success': False,
                'message': 'Your task was incorrectly named'
            },
            target=(
                'applicationId=ftrack.client.web and user.id={0}'.format(
                    event['source']['user']['id']
                )
            )
        )

        session.event_hub.publish(
            event
        )

        session.commit()

 

cheers

Eric

[keyframe]

Thanks for the feedback Eric,

This is the path that I ended up taking, but, imo, it results in fairly poor UX.  the asset gets created, the 'green' notification fires', then a 'red' notification fires, and then the user is asked to refresh their browser.

If there's a vote being held anywhere, please put me down for a smoother UX option.

Cheers,

G

[John]

I did some googling and end up here. Sorry for bumping this two years old thread up.

It's an essential feature request we need to keep names under control as we just cannot count on the human hands to be typing correct names all the time. For now we are going to use the solution @Eric Hermelin provided(thanks) but as @keyframe  said considering the UX it would be nicer to have a better solution.

[dannydd]

Big vote for this feature. We are validating a lot of inputs and renames and its a horrible UX experience to see the change applied but reverted only after the refresh. Even if an error message appears

[JPrydz]

Hi there,

Thanks for the feedback.
This has been discussed and we have a feature request for it.
Added your input to that task.

Regards,
Johan

[Chandler]

I'm a bit confused as to the the ftrack.validate event subscription seems to remain in the documentation. I won't have a chance to test this for a while, but Project Code validation is a huge need for us, and the current docs seem to indicate this is possible...?
https://help.ftrack.com/en/articles/1040479-events
Scrolling to the bottom, I see the ftrack.validate topic listed. Are we saying if I set up an event listener for this topic I won't get anything?

[Mattias Lagergren]

Hi and thank you all for your feedback. We understand the motivation for validating input and will take this into consideration for future development. As I understand it and what I've heard from other customers is that the project code, but also shot / asset / task names should be validated.

A suggestion in the first post is to have a regexp to control this, what do you think about this? Would that be enough for your use-cases?

 

Quote

I'm a bit confused as to the the ftrack.validate event subscription seems to remain in the documentation. I won't have a chance to test this for a while, but Project Code validation is a huge need for us, and the current docs seem to indicate this is possible...?
https://help.ftrack.com/en/articles/1040479-events
Scrolling to the bottom, I see the ftrack.validate topic listed. Are we saying if I set up an event listener for this topic I won't get anything?

Thank you for highlighting this. The ftrack.validate event is deprecated and we will make sure to remove it from the documentation.

[Chandler]

Thanks for the quick fix on the docs, certainly clears up some confusion I had, haha.

Regex would be very appreciated and powerful.  I am also facing a need to validate statuses though, so I wonder if there's a way for a regex to apply to that field as well. It would be a little more abstract than than naming validation I guess, but I could see it still working. That may be out of scope though, if the discussion here is determined to be focused purely on validating text fields or something.

The way that old validate function worked seems to be the right idea implementation-wise. I understand if the new API ruled out that type of event interception though. Overall the need seems to be having the chance to validate an event before it actually happens. That's the common thread with all of these issues - the fact that currently ANY validation needs to be the product of detecting a change and reverting it, as well as completely custom logic, is quite daunting and taking up a decent amount of my development time.

I'm not familiar enough with the API yet to be thinking about performance, but I'm sure that would increase too when we aren't reverting so many changes.

[JPrydz]

Hi,

You mentioned statuses - could you elaborate on that?
Depending on the use case, there might be other possible feature enhancements involved.

Regards,
Johan

[Chandler]

Sure. I have actually already created this in a way the way I want, but it would still be improved by a way of 'intercepting' a change rather than 'reverting' it as we have to now.

I wrote a script that essentially determines the 'allowed statuses' for a Task or Milestone based on Incoming links. A Task/Milestone with any incoming links is first forced into a special status called "Locked". It is not allowed to be changed away from this status. If all of the incoming entities are marked as completed, then this changes from "Locked" to "Open". The script then finishes up by trickling down this configured status check to any outgoing links.

This all works great, but there's a huge processing and usability problem with having to detect and revert these changes. As of right now, the user is told their status changes are all successful, and then they watch them slowly change to their allowed statuses where applicable. Sometimes these changes lag long enough that a full refresh is necessary. These status changes also persist in the history, which I may need to depend on for other logic later. This also rules out the ability for me to program any logic for when a Task first unlocks and obtains an "Open" status.

So back to the regex thing - I imagine the same logic being used to deny a name change based on regex, could also apply to a status change and prevent that from happening. Just like a name change might be compared against the regex, the status name could simply be compared as well.

What logic did you guys have in mind to actually set the regex for naming validation? Would it be stored within the entity itself and changed via the API or something? This would allow a script to dynamically change the approved regex's for a given field, which would be really sweet. Maybe even the field itself could support a 'validation' key with the regex directly in it??

[Erik]

Regexp for project and any created entities would be great. We got listeners for fixing most things but it would give better feedback to the people that inputted weird things instead of magically changing the name on them.

[altarak]

Hello,

 

We are currently evaluating ftrack (trial period of ftrack Studio)

I agree that we can't count on human hands to be typing correct names (sanitized, and using a custom syntax).
We should have a way to use python (or at least regex) to customise name validation for projects, shots, assets, tasks, and also when publishing versions.

This discussion was held here from 2017 to 2019.
Has this feature been added to ftrack since then ?  (for ftrack Studio, we do not want to install on-premise with Enterprise)

 

Thanks.

[altarak]

Hi Andrew,

 

Thanks for your answer.

 

I attach here an image of my ideal UI, I think it is easy to use and understand by end users.
It's a field in which the user enters his text (for the name of the new project / shot / asset / task).
Below that field, another field automatically displays (in real-time, as you type) the cleaned validated version of the text (this field is read-only, greyed-out). This is the version that is used as real name.

So, you don't need to display a popup that says "your name is wrong", as the cleaned name is already displayed in the main UI, and will be used.
 

Cheers.

[altarak]

So that others may also comment, here is some information about what rules we would like to enforce (in ftrack's web interface and in ftrack Connect, using python for example).

We need to make sure projects, shots, assets, tasks, and also publishing versions, follow these rules :

            

Names must begin with a letter, and they should not contain any of these : spaces, non-english accents, non-unicode characters, special characters, dash -
The above sentence can be explained the other way around : names must begin with a letter, and must only contain standard english letters, numbers, and underscores.

      

As a side note, we also make sure that folder and file names (which come from entities names) also follow this :

-Folder names are all uppercase.

-File names are all lowercase.

         

I have worked for several companies that have chosen these same rules (because less strict rules often cause compatibility problems in softwares and scripts), but of course I guess other companies may prefer other rules.

 

[Mohammadreza Hashemizadeh]

Hey there, 

Just a little bump to see if there is any news about this feature ?

Cheers,
Mo.