Hi

I'd like to have a validation script run, whenever a portal row is commited, or more precisely: whenever a portal row loses focus AND was modified before.

I tried Portal::OnObjectSave, whicht unfortunately doesn't fire for known reasons.

I tried Portal::OnObjectExit, which fires too often, namely, even if the portal row data was NOT modified.

I tried PortalField::OnObjectSave, which fires too early, because validation can only be done on record level, but not on field level.

I have in mind to use Portal::OnObjectExit and there decide, whether a record needs validation based on a flag that was either set priorly using PortalField::OnObjectSave or by evaluating the record's modification timestamp in a way that I haven't figured out yet.

Either way, I'm afraid that my solution will lack of elegance and robustness.

I'm aware that the same question was posted earlier this year, but there was no sufficient answer (in my eyes).

Nevertheless, I reckon this problem is standard and me, being a script newbie, just blind to the appropriate solution.. :-)

Thanks for your trouble!

Jürg from Zurich

Hi Jürg,

I cannot grasp what you are attempting here. We need to visualize the process. What is the name of the parent table and the name of the portal table? And what is a User doing when you want this 'action upon commit' to take place, e.g. adding parent then child records, only changing a value in a portal field? And what is the specific validation which needs to fire?

Usually when I get into 'twists' it is because the logic has not yet been walked through sufficiently to clearly see the true need. Not to worry ... you are in the best place for assistance. So please walk through the visualization for us - not what you have tried but rather what you are doing and then why it is insufficient. If you wish to post a file or example to add clarification, it usually helps.

I reckon this problem is standard

I don't think so.

One of the features of editing records in a portal is that any modified row remains uncommitted - thus allowing ALL edits to be reverted. Conversely, you cannot selectively commit a specific portal row - it's an all (including the parent record) or none proposition. This is also why the script step is called Commit Records (plural).

I suspect that portal editing may not be best suited for your purpose. Still, it's possible to do what you requested, with only a small addition - see attached.

Another option would be to capture all relevant values into a variable upon entering a portal row, and comparing it to the current values upon exit. Note that looking at the record's modification timestamp is useless, as this will change only upon commit.

ModifiedPortalRow.zip

I would never have considered using Get ( OpenRecordState ) in this way!

Me neither. That's exactly the fun mentioned in the other thread:

http://fmforums.com/forum/topic/80942-relational-filter-or-portal-filter/page__view__findpost__p__377824

Indeed! :yep:

Thanks for the idea, and good example of OpenRecordState.

Holy cow, Comment, that's most impressive! :-) A lot of fun, indeed!

I would have never guessed that the flag that I was going to implement myself in humbling manner does already exist. Moreover, it even seems to be rock-solid (at least I couldn't make your solution misbehave in no way) and requires no maintenance, should ever fields be added to the child table.

All the more, I now wonder why portals shouldn't be the best choice for my problem (as you said). In terms of user-friendliness I reckon they are.

Thank you, Comment!

Thank you, LaRetta!

It seems lik you made me save a lot of time and trouble, since this situation occurs regularly in my projects (whenever its about complex user data validation) and, feeling very thankful, I browsed through your profile looking for sth like a 'Donate' button, because the service you provide is on the far side of self-evident. How can I show my gratitude?

Jürg

All the more, I now wonder why portals shouldn't be the best choice for my problem

I am thinking this problem wouldn't exist in List view, since there you cannot exit a record without committing it.

I browsed through your profile looking for sth like a 'Donate' button

Hmm. Something to think about - thanks for the idea.