Enforcing project and shot naming convention?
2 2

12 posts in this topic

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
2 2