84

Simple field validation

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.

60件のコメント

  • Avatar
    Nephi Sanchez 正式なコメント

    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

     

  • 4
    Avatar
    miker

    +10  We keep getting bit by the lack of this feature.  It's quite frankly a huge embarrassment for Shotgun that this highly requested and relatively simple request hasn't been addressed for NINE YEARS.  Please address it.

  • 4
    Avatar
    Edward Spencer

    from 8.2 release notes:

    "New entity forms can now be configured to include hint text to users during data entry. [SG-8641]"

     

    ..so close.

    Any advance on getting the actual feature we've been requesting for 10 YEARS?

  • 2
    Avatar
    Sam Richards

    The lack of this feature just bit me again. Any news on this?

  • 2
    Avatar
    Alon Gibli

    Putting in my vote for "any text field", we have non-name/code text fields that we want to validate since they correspond to parts of our path structure.

  • 2
    Avatar
    Alon Gibli

    A tale from production:

    "[...] there was an invalid character in the asset name that looked like a space, but was actually the unicode character U+00A0 (non-breaking space). So seems like a copy/paste gone awry."

    Just one of many ways in which lack of text field validation has bitten us.

  • 1
    Avatar
    Sam Richards

    Just being able to have a regex pattern for *any* text field would be huge, especially since we are sometimes constructing paths from more than just the name (or code). Another alternative is if its easier just to have client-side validation everywhere, that would be a start, since it feels like you need it:

    1: In the GUI for the +Entity buttons.

    2: In the excel import

    3: in the API.

    Just doing (1) and (2) for a start would be a big step forward...

    Sam.

  • 1
    Avatar
    Gary Chadwick

    Hey Brandon

    Would it be possible to make it a different type of field? "Validated text" or something like that? Given the option, we'd definitely like to create new fields with validation.

    However for sure, being able to have it on entity names would be our primary use for it. So having that would be definitely be very useful.

    Cheers

  • 1
    Avatar
    Travis Mosley

    +1

  • 1
    Avatar
    Darragh Duffy

    +1

  • 1
    Avatar
    Halil Mehmet

    Any recent official statement on this feature?

     

    This has always been on our wish list, but since moving to toolkit it's a must. Once toolkit registers a folder to an entity, renaming an entity for example involves more than just renaming the field. There are many solutions we can and have implemented to prevent this but really the best way is to fail the creation of the entity or edit of the field in the first place.

    For reference most entities are created or fields edited via CSV importing.

     

     

     

     

  • 1
    Avatar
    Christiaan Scholtz

    +1

    We just had the problem of some invisible character in the name screwing everything up. Please implement ASAP.

  • 1
    Avatar
    miker

    The lack of this feature has just caused another problem that took valuable time to track down and fix.

  • 0
    Avatar
    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.

  • 0
    Avatar
    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.

  • 0
    Avatar
    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

  • 0
    Avatar
    KP

    @Janos: I've added your comments to our internal feature ticket for this. We'll follow up when we tackle it.

  • 0
    Avatar
    Patrick Wolf

    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

  • 0
    Avatar
    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.

  • 0
    Avatar
    Patrick Wolf

    Thanks ben

  • 0
    Avatar
    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

  • 0
    Avatar
    Patrick Wolf

    Yes please. Have been waiting for it for a long time!

    Thanks,

    Patrick

  • 0
    Avatar
    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!

  • 0
    Avatar
    Jimmy Christensen

    Anything new on this? Could really use it.

  • 0
    Avatar
    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!

  • 0
    Avatar
    miker

    Just wanted to add that we could really use this feature also.

  • 0
    Avatar
    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.

  • 0
    Avatar
    Patrick Wolf

    Hi Jimmy,

    very interesting aspect that hosting shotgun locally allows tweaking these things :)

    Best,
    Patrick

  • 0
    Avatar
    Jimmy Christensen

    Yes, it has it's advantages :)

    Just a little more work to upgrade as the changes are lost.

  • 0
    Avatar
    Patrick Wolf

    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

ログインしてコメントを残してください。