As I’m sure everyone is aware, Shotgun has stated they are not planning to implement field validation at this time. Personally, I have not yet accepted this outcome, and am in the “bargaining” phase of my grief.
Is it possible we’re not getting this much-needed feature because we pushed for something too complicated? Perhaps it makes sense to go back to square one and request only the most basic possible thing – a fixed set of simple regex patterns for fields.
Here’s a list of useful validations I came up with:
url
ip address
email address
phone number
file path
folder name
file name
numeric
alphabetical
alphabetical with underscores
alphanumeric
alphanumeric with underscores
alphabetical, followed by numerical
numerical, followed by alphabetical
valid maya object name (probably need a name for this)
The key is that these patterns would be provided out-of-the-box by Shotgun, and not a user-customizable regex system, or an elaborate hook system with awareness of multiple fields. BUT, you could combine some of these with calculated fields to stretch it a bit further.
Don’t get me wrong – this is extremely limited. However, I don’t think we should settle for nothing, just because we can’t have everything. And if I’m being honest, for a lot of the more complex cases, it probably makes more sense to build custom front end tools, and this is easier now with a REST API.
I’m curious what people think about this, and what other patterns they would want. Would a system like this be beneficial, even if it doesn’t solve all of the problems?
I think more options here would be helpful. I like that Shotgun currently has the ability to prevent duplicate entity names within a project, and it’d be great if this could be expanded on even a little:
Even if one or two things was added, like “no spaces”, “alphanumberic” or forbidding specific characters, those could all nip some accidental naming mistakes in the bud.
For the sake of posterity I’ll try and sum up why this has been a particularly tough nut to crack on the Shotgun side:
We’re painfully aware that field validation is desirable, but when we did a deep dive on it last year we could not accept the tradeoffs in security and performance that would be required to deliver the different needs people have.
So that’s why we’ve not done it, and why it’s not our focus right now. But at the same time, I acknowledge that me saying that doesn’t make the need for this go away!
A big part of the problem is getting agreement on what field validation needs to look like, which situations it needs to work for. When we sent out a survey last year the results were overwhelming that people have different needs, such as regex or validation based on the values of other fields. Where I could see us getting somewhere is if we tried your approach of allowing people to choose preset (baked-in) criteria. For that to be viable, I think we’d have to pin down some small set of those that there’s broad agreement for.
Almost two years and still no validation support?
I think it is very important feature! For example currently i was solving an issue with an asset in our pipeline and the problem was that somebody has used a space in the asset name
could I ask for an extended explanation on the regex issues with security and performance? I can only assume this has something to do of showing hidden fields by mistake
While we now have some limited validation support in some entities, it has been deemed unusable for the cases we are interested in + it is only limited to validation steps of certain entities.
Actually I am quite interested in the topic of regex in general, not just validation. Are the same concerns you mentioned for validation also applied to Calculated fields?
For example:
Today I was creating a calculated field, which only needed to extract 2 or 5 characters out of the file suffix, so we could present localisation flags: EN, ES, ZH-TW …
In the end I found a working solution by combining IFs with MID and LEN matching specific border characters, BUT this resulted in an ugly unreadable 485 character line.
With REGEX matching (either TRUE/FALSE or extracted match) and some IFs it could have been much leaner and readable.
Worst thing is, I seemed to have almost approached the upper limit of characters, since I mistakenly did a double paste and there was no space left for 2 copies causing an error.
