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:
alphabetical with underscores
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:
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