It would be great to be able to specify simple validation for fields. Ranges for numbers, regexp for text (for example). This would help enforce naming conventions that our workflows depend on.
Date
Votes
60 comments
-
Nephi Sanchez Official comment Hi Halil,
Thanks for the ping! I will revisit this with the team to see if there is a way to make something happen sooner, rather than later, and report back.
cheers,
Nephi
-
János Sziliczi I think it is possible many times that we need more difficult validation than regexp like things.
I think it's a good idea to introduce hook/callback functions.
If a callback function is assigned to a changing field it will be automatically called before the change committed with the old and new values. After that we can do various checks on the those values and if the new value appears invalid we can either raise an exception or return an error message from the function to prevent the change event.
-
KP Definitely good ideas. I can see the benefit of both of these. How would a callback function work? What would you write it in? I think that probably the more bulletproof way to go would be to implement some sort of logic you could build with the query builder to create a set of validation rules that would return true or false based on the old and new values.
We'll see what we can do when the time comes.
-
János Sziliczi Hi Guys,
I'd like to write "validation rules" in the body of a callback function. If at least one rule is not satisfied, the callback will raise an exception to prevent the data change to be requested.
However the callback function is just a "border" of validation rules, the meaning of our request is the validation.
I don't insist on introducing callback functions into Shotgun, I'd like to check new data before the change is committed.
IMHO the validation rules have to support the following validation possibilities:
1. Comparing the old and new values of the changing fields
2. Checking unmodified fields of the affected entity (e.g.: a field can be changed from 'A' to 'B' only if an other - unchanged - field contains 'B' too)
3. Checking linked entities (e.g. the status field of the project entity can be changed from 'Bidding' to 'Active' if at least one 'Artist' person is linked to the project and/or at least one task is assigned to the project)
One more idea: it's obvious that if at least one validation rule returns false, the operation will be canceled. But the user must know why his/her modification has been rolled back. I think you should define an error descriptor field in the validation rule "entity", which contents will be displayed to the user after a rule failed.
Thanks in advance!
Bye Jana
-
KP @Janos: I've added your comments to our internal feature ticket for this. We'll follow up when we tackle it.
-
Permanently deleted user While building call back function is a longer project I would like to see regex validation on text fields and ranges on numbers introduced much earlier as it's a very important feature to be able to enforce a naming convention.
Thanks,
Patrick -
Ben Hadden @Patrick: Looks like we're aiming to include in an upcoming release. It's close!
I added your comments to the ticket, so we'll be in touch when we embark on this feature.
-
Permanently deleted user Thanks ben
-
Botros Gerges Has this been implemented in shotgun 2.4? I don't see anything in the release notes regarding the ability to do regex validation on entered data.
Thanks
Botros
-
Permanently deleted user Yes please. Have been waiting for it for a long time!
Thanks,
Patrick
-
Ben Hadden @Botros, not yet, but I'll rekindle the discussion since this seems to be a popular request. Thanks for your patience on this one!
-
Jimmy Christensen Anything new on this? Could really use it.
-
Ben Hadden Hi everyone,
Sorry for the delay on this, it's still on the roadmap, but isn't in a development sprint just yet. I'm curious if anyone has come up with a temporary solution for this that's been working well and you can share. It's definitely something we want to support, but it's a big project. It'd also be useful to hear a few more use cases from everyone so we can see if there's a smaller version of the big feature we can focus on in the short term. Let us know!
-
miker Just wanted to add that we could really use this feature also.
-
Jimmy Christensen I made a small modification to our installation that strips out anything which is not a-z or 0-9 :
nodeType = this.record.get_type();
columnName = this.column_name;
if((nodeType == "Asset" && columnName == "code") || (nodeType == "Project" && columnName == "name") || (nodeType == "Sequence" && columnName == "code") || (nodeType == "Shot" && columnName == "code") || (nodeType == "Task" && columnName == "content")) {
e.getTarget().value = e.getTarget().value.replace(/[^a-zA-Z0-9]+/g,"");
}Not pretty, but works wonders :)
It's a modification of the client side javascript. This way people will get instant feedback if the system does any changes to their naming.
-
Permanently deleted user Hi Jimmy,
very interesting aspect that hosting shotgun locally allows tweaking these things :)
Best,
Patrick -
Jimmy Christensen Yes, it has it's advantages :)
Just a little more work to upgrade as the changes are lost.
-
Permanently deleted user I would love to pick up the ticket again with the original request from Rob:
"It would be great to be able to specify simple validation for fields. Ranges for numbers, regexp for text (for example). This would help enforce naming conventions that our workflows depend on."
Would be so helpful to have even this basic data validation to ensure data entered into shotgun is consistent.
It looks like this would be all that is needed:
1) Additional validation tab in the shotgun UI (field editor dialog) with
- regular expression field (drop down with predefined ones would be helpful)
- optional error message field in case validation fails
2) Code on server side which runs the regular expression as field validation policy before a value is set
3) If a validation error occurs an exception is thrown and the UI would reject the entry and display the error message (as its already happening right now in shotgun)
4) If a API call triggered the error a server side exception would be thrown which would reach back to the caller (like its happening already right now)
Thanks!
Patrick -
Hugh Macdonald Someone I work with mentioned this feature request recently, as we had some badly named assets which were causing issues. What Patrick said would be very useful, if not border-line essential in my opinion.
-
Permanently deleted user I agree that its essential Hugh. So lets vote it up to raise awareness.
Just click on the "xx people like this [Me too!]" at the top of the page! -
Hugh Macdonald Done!
-
Hugh Macdonald I had a conversation with Mason about this on Thursday...
While having some kind of reg-ex based validation would be incredibly useful, I could see a subset of this also being very useable. Even if we had the ability, per field, to specify either a list of characters that are allowed, or even checkboxes for lowercase, uppercase, numbers, whitespace, and then certain punctuation split out...
The specific case that I'd want is the ability to restrict the field to only allow filesystem characters - basically characters that SGTK isn't going to change when creating folders on disk. For me, I'd probably say alphanumeric plus _ and - only...
Anyway, that's a cut down version that would be very useful if the full system isn't practical - a bit like you guys did with the "Latest Version Per Shot" idea.
Also, to avoid serious issues, I'd probably suggest that the validation is only done on data storage, so it shouldn't invalidate any earlier records that don't comply.
-
Alexey Borzykh +1 for this feature as we also have a lot of (daily) troubles with asset/shot/naming/renaming as well as some extra fields filled in manually by users.
-
Alexey Sadrutdinov +1. Definitely we need this feature! Since a lot of pipeline scripts depends on shotgun data, it's very easy to break things down just by simple typo. How i see this feature implementation:
In the Site Preference page, add some controls to specify 1)Rule name 2)Regexp pattern. Then on Fields page, we can just select what rule we want to apply to particular field.
Can't wait for this. Guys, i know you can do it! =)
-
Permanently deleted user @Alexey +1 for setting up Regex in Site Preferences that would make it very simple for everybody and would allow shotgun to deploy pre-build regex and would cover @Hugh versions of simplified idea.
What is essential is that the regex isn't running in JavaScript on the client side but that its server side and the same regex gets applied to GUI updates and API updates. This is the only way we can trust that we never get wrong values into the DB
-
Jacob Medendorp +1 for this feature!
For instance, I'd like to prevent users from naming Shots with underscores in their names. I have our form creation for Shots set up so users enter a shot "short name" a la "0010" and pick a Scene. When the Shot is created, an Event Trigger runs that finds the Scene Short Name and Sequence Code and fills out the "code" field for them, like "TST_010_0010." My current workaround is that shots which are named incorrectly have their short name reverted to a blank entry. This prevents folders being created on disk with bad names through SGTK, but returns an inelegant error for the user. It would be better if they were prevented from actually creating the shot with a bad name in the first place.
-
Ben Hadden Hey everyone, time to dust this one off and get some requirements. Before we get into implementation details, I'd love to gather all your use cases. To keep things simple and consistent, could you all send me as many real rules that you can think of using the below survey? If you're using these in production, even better (through trigger scripts, for example):
http://goo.gl/forms/ZsZFyEIygc
I'll be sure to post a summary of the results once we have them.
Cheers,
Ben -
Craig Barnett Another +1, also submitted the google form.
-
David Moulder Another +1
1st thing our non technical people asked when in SG. How do we make sure assets are 1) Unique, 2) Match our naming convention, 3) Doesn't already exists in our asset archive library (custom tool and Db) that we could just restore to the project.
3 - This is more difficult - local install guys could get over this perhaps. -
Russel Rehmund +1 as well
Please sign in to leave a comment.