ShotGrid has released new Input Validation capabilities for system created Entity Name Fields (e.g. Shot Code, Sequence Name, Asset Name, and etc.). This workflow allows users to configure validation rules i.e. define specific input requirements that need to be met in order for the data to be accepted into ShotGrid. Once a validation rule is created, it can be applied to the desired projects on a site.
Check out our blog post on AREA for more information
seeing field validation is a great addition, even though we have our internal validation happening on an Event Listener.
But it would not hurt to warn users upfront instead of having the Event Listener nagging a few seconds later.
While I was testing the validation it confused me very much that (it seems) I can define those rules only per project, and even more confusing can’t set them up on a template project (so they will be picked up automatically for newer projects).
As most studios have rules and naming conventions for all projects, I guess this must be something of great interest.
Could it be that I just overlooked something?
How can I define validation rules for all (future) projects?
Hi @pixelconductor, thanks for your interest in the new Input Validation feature! To answer your question, there isn’t a way to add validation rules for all (future) projects. You can apply an existing validation rule to a new project by launching the Configure Field dialog from a page where the rule is enabled. Then navigate to the Validation tab in the dialog and add additional projects by following these steps.
We are continuing to collect feedback for potential future improvements on Input Validation, and have taken note of this request. For us to better understand your requirements, may I ask how many projects you are creating and how many validation rules you are trying to apply to these projects?
thank you for your response!
We are creating about a project per month. Going through all neccesary validations and re-applying them to a new project would be cumbersome, prone to errors and might be forgotten on a regular basis.
Being able to apply the rules via the API would kind of solve the problem as we would let the Event Listener take care of the rules then.
I actually don’t see a single validation rule usecase (for us) which I want to apply that should not be globally working. In general its about covering naming conventions to make sure that downstream pipeline tools will work, or field formattings (check if its a valid email).
Both of theses things are very much global defauls for me.
Your validation rule options are powerful enough to make these things globally working for me, even though I would have liked regex support to show up.
Consider this a feature request to either create global rules or at least to be able to apply them to template projects.
Thanks for the the additional information Tobi!
Is there any way to specify a space as a special-character, to use as a separator?
For example to enforce a space-separated RGB hex value like “A1 B2 C3”.
Thanks for your question.
Currently we do not support space characters in the special character list for input validation rules. We have added this to our list of requests for consideration in future enhancements.
@slewery I’d like to add to @taiello 's request that this would be a useful addition. We’re trying to validate a Description field and spaces are to be expected in its contents. I see no reason why the space character shouldn’t be an option for someone to use. I’d personally like to see the new-line or carriage-return character available as well - more options gives the existing validation system more utility and less need for users to build solutions circumventing its limitations.
Thanks for adding your weight behind this @scl-mschroeder!
We’ve created a ticket for the ‘space’ special character and we’ll also look into the carriage return idea. I can’t commit to when this work will be done, but our team is looking at it and I’ll lat you know when it’s available.
Appreciate the response @warren.trezevant - I’ll keep my eyes peeled for whenever that may be! Validations are super handy for a large number of things already, so hopefully this will just add to the list of useful stuff you can do with it.
This input validation looks super helpful @warren.trezevant, I have few queries around the same.
- Validation tab is not available in configure field window.
- How can I restrict user from adding same entity multiple times in a “multi entity field”?
Thanks for your anticipation…!!
Thanks for your suggestion. We have added space character support to our list of upcoming enhancements and will take a look at whether we can include newlines with this.
Thanks for your questions!.
Validation should be available in the configure field window. Please note, that you won’t see the tab displayed for demo or template projects or when viewing a project based entity in a global (non-project) context. Validation is currently supported for text, currency percentage, float and number types.
We don’t currently support validation for mult-entity fields but we will add this to the list of features for consideration.
Would it be possible to add validation for linked entity code for example, make sure a shot code contains the sequence code ?
How can we check for the validation rules within our REST/python API calls? When doing the
schema_field_read command in python on the entity field where the rules are set, I’m not seeing an entry with the specified rules, just whether or not it’s editable, unique etc. Is there a different command that is used for this?
Thanks for your question! We currently don’t support returning the validation rule with schema fetch calls in our apis. We are currently working on improving the experience of using validation with the APIs and I have added your request to our items for consideration for future releases.
You should actually currently be able to retrieve some information on the rule with your schema call.
Will return a block indicating the message, description, enforcement type and rule type.
Thanks for the info Stefan, I was under the impression based on this that it was supported:
But, I’ll keep an eye out for any further updates, thank you!