Bypass Validation When Running A Script

[Ron Cates]

I have a field in a layout that has validation set to "Not Empty". On the same layout I have a field with a script trigger to run a script on modification. The script goes to another layout and deletes all related records in order to replace them with the new selection. Now, when a user triggers the script before populating the field with the validation the script proceeds to delete all records without leaving the current layout. Not a good thing. I remember seeing somewhere that a script can be set to bypass validation. Is this correct and how would I set it?

Thanks

[bcooney]

Hi Ron,

Well, I have to tell you I'm a bit suspicious of your need to delete and replace all related records requirement. Anyway, how about if your trigger script does a gtrr in a new window (offscreen) perhaps you can avoid the commit that is tripping the validation.

I always use this construct, esp. if I gtrr and delete:

Gtrr Destination New Window

If (get lasterror) = 0 ) and if (get(layouttablename) = "destination") //sometimes I check the table

delete all

close window

endif

[Ron Cates]

Thanks for the suggestion Barbara.

I can certainly understand your concerns. The words "Delete All" tend to make my but clench a little bit. The situation is this. Each invoice has a field for who sold the ad. There is also a related table for who gets paid commission on the sale. This is usually the same person, but sometimes the commission is shared or in some cases set to "house". When the sales person is set on the invoice record, the script triggered goes to the related commission table, deletes any records that are there and creates a new record for the new selection. So the "Delete All" is actually only deleting 1 to 3 records. Not too dangerous when it's working right. But in this case when the validation prevents the script from going to the commissions table it proceeds to delete all the invoice records. That's not good. It's a ******* good thing I have a good backup setup. :

I was pretty sure that I saw on a post somewhere the ability to bypass validation. If this is not possible, I was thinking that I would just test for the current layout before proceeding with the delete all. If still on the invoice layout then I will trigger a popup to let the user know that they must set the status before setting the sales person.

[mleering]

There are certain script steps (ex. commit record) that can bypass validation.

If the step that you're trying to perform does not support this type of feature, then the way that I would go about bypassing the validation would be by setting a global variable as a flag.

(ex. $$skipValidation)

You could probably set $$skipValidation equal to 1 at the beginning of your script, do what you need to, and then set it back to 0 or NULL.

Taking advantage of something like this would also require you to change how you configure your validation of course. Instead of simply requiring "Not empty", you would want to change your validation to "Validated by calculation"

Something along the lines of:

Case

(

not $$skipValidation;

	not IsEmpty ( Self );

//else

	1

)

and you'd probably need to uncheck "Validate only if field has been modified" so that it takes effect on new records too.

PS --> Even if you do choose to take this approach, I would still recommend that you check the layout, check for errors, and potentially (if possible) the found count etc. first prior to ever performing a delete-all.

[Ron Cates]

I like it! Thanks Barbara. I will use this approach and include additional checking as well.

You Rock!!

:

[bcooney]

Ron,

The very detailed how to avoid getting trapped by validation was not provided by me, but by mleering.

It's very nice to see you here, mleering. Thanks for adding a great post.

-Barbara

[mleering]

Good to see you here as well Barbara,

and to be honest, I hadn't seen your post at the time of my response.

I would recommend that the OP use your suggestion (instead of mine) for simplicity's sake, and for the fact that it circumvents the need to override validation.

I've read quite a number of your posts, and like how you both bring up concerns you have about particular approaches, and also directly answer the questions posed by various posters.

Keep up the good work!

Matt

[Ron Cates]

Wow! My apologies Matt. I got so excited about implimenting your suggestion I never even took a second glance to see who had posted it. I guess I'm so use to getting assistance from Barbara. LOL

Thank you both. As always, all input is welcome and appreciated.

:

[Ron Cates]

I'm just a little stuck. I have the script setting a global but I'm not sure what the calculation would be in the validation dialog.

[bcooney]

Notice, Ron, the script must set a global variable, $$skipValidation. Then, you validate by calculation using the calc Matt posted above.

[mleering]

No worries Ron;

She's very helpful, so I certainly understand.

If you named your global variable the same as I did ($$skipValidation), then you can use the exact validation calculation that I'm using.

 Case

(

not $$skipValidation;

    not IsEmpty ( Self );

//else

    1

) 

*Self returns the current field that is being calculated

It basically says:

"If we're not skipping validation right now, then make sure that this field is not empty, otherwise... skip validation alltogether".

Other considerations:

• set $$skipValidation to 1 before your GTRR
• set $$skipValidation to 0 immediately after you don't need to skip anymore
• uncheck "Validate only if field has been modified"
• check for errors etc...

Also remember, that this might not be the best approach to solve your solution, however, it is accomplishing what you had asked for help with.

Other workarounds:

-Instead of ignoring validation, you could check for the contents of the field that has its validation turned on for "Not empty". If it's empty, then you could Halt the script or something to that effect... make sure that you're not in that situation in the first place

-Alternatively, if you're deleting ALL of the related records, and not just the related records from one particular related table occurrence, then what you could do is to set up cascading deletes, duplicate the record you're on, and then delete the original.

There are many different ways to tackle this.

Regards

Matt

[Ron Cates]

I'm definitely a bit skatter brained today. I just realised the calc was in your previous response. Too much going on today I guess.

I have the script setting the Variable to 1 before GRR and back to 0 after. I am also chacking the field with the validation before that in the script. If the field is empty it pops up a dialog and exits the script before the GRR. This is really just for added security.

In addition I am checking the layout before the Delete All so really I have 3 levels of tests to make sure all is well before exicuting the Delete All step.

Thanks again for the help.

Ron

Edited November 5, 2010 by Guest

[Ron Cates]

Hmm. Well, this may not work after all. When testing I found that it does skip the validation to run the script but after the script is run the validation does not seem to kick back in. In other words, a user starts off with a new invoice. The validation on the status field is supose to prevent them from leaving the record unfinished. But if they select the sales person drop down and exicute the commission script, they are then able to leave the invoice with the status field empty.

At this point I'm thinking that this might be overkill. After all, as I mentioned, I am checking the field in the script before GRR and checking the layout after, so I think that should be solid enough to prevent any problems.

[comment]

When testing I found that it does skip the validation to run the script but after the script is run the validation does not seem to kick back in.

The validation does not kick in because the record is committed. You need to re-open the record in order for the validation to execute when the record is committed again - this time by the user.

if they select the sales person drop down and exicute the commission script, they are then able to leave the invoice with the status field empty.

Well, you cannot validate by "did a script run". If the script leaves some evidence behind, you can validate by that. If the validation is not just "required value" but "required under some circumstances", then you should validate by calculation saying so.

I'm thinking that this might be overkill.

I tend to lean towards the same opinion:

SkipValidation.zip

[Ron Cates]

Thanks for the input Comment.