No 'Limited' Record Creation option . . .

[Wickerman]

I have a Film program database set up where a STUDENT table (name, address, ID #, personal info)  is connected to a child table of FILMS.  The Film layout has many fields describing the film, and includes various sub-tables of its own for things like actors, thematic keywords, etc.

I'm trying to create privilege sets that allow a Student to View and Edit only his own Student record, and to View *all* Film records but edit only his or her own films.  I've got this mostly working okay.  I have a hidden Field in the Student Table that holds the Student's 'AccountName', so that I can use that to restrict access where 'Accountname' = Get(AccountName).  This is working well up to a point.  I've used this authentication tactic to restrict Viewing/Editing/Deleting records in both tables . . . but I'm stymied by the fact that you can't limit record CREATION -- it's Yes/No option.

So, when a Student is viewing another student's Film record, he is properly unable to edit any of the fields in the FILM table . . .  but while he is also properly unable to Edit or Delete any of the sub-records, he IS able to *create* sub-table records.  For instance, if a film has a Keyword record in the portal window that reads 'Comedy', he can't delete or edit that word . . .but he *can* enter any additional keywords, like 'Tragedy' or 'Doofus' -- which I don't want to allow.

So, how do I restrict the creation of these sub-table records for Films not belonging to the currently logged-in Student?

 

[comment]

Could you not use field validation in the Keywords table?

[Wickerman]

Ah - so enter a "Validate by Calculation" with my ::Student:Accountname' = Get(AccountName) equation, right?  I can do that in any single field in the sub-table and it will bar record creation, yes?    Thanks for the suggestion.

[comment]

3 minutes ago, Wickerman said:

 so enter a "Validate by Calculation" with my ::Student:Accountname' = Get(AccountName) equation, right?

Yes, I believe so (if I followed your description correctly).

 

4 minutes ago, Wickerman said:

and it will bar record creation, yes?

No. But it will bar the created record being committed. As with all validation procedures, you may want to supplement this with triggered scripts to make the user experience more pleasant.

[Wickerman]

Ah -- I see what you mean -- but then maybe using a script trigger is the way to go to begin with?  Would it be a solid practice to use an "On Object Enter" script trigger to throw the user back out of the field if he doesn't pass the authentication test?  

I'm trying this and it seems to work okay, but there's a sort of annoying 'flash' because a drop-down list flickers before the user gets the custom dialogue I set up to inform him he's not allowed to edit the field.  

[comment]

How about OnObjectModify?

[comment]

22 hours ago, Wickerman said:

but then maybe using a script trigger is the way to go to begin with?  

You may begin with it, but you cannot stop there. Script triggers work at layout level only.  They cannot replace data-level measures to ensure data integrity.

[Wickerman]

When I use OnObjectModify it doesn't 'bar' the action until after the record has been added in the portal . . . so then I wind up with the addition looking like it's been accepted until the user leaves the record. 

Did you have a different approach in mind when you suggested "you may want to supplement this with triggered scripts to make the user experience more pleasant." ?  I feel like I'm hammering at this from two ends and it just gets clunkier - the validation and the OnEntry trigger . . . as you say it seems best to bar the record creation at the Field validation level, but how best to make the denial message immediate and relatively 'pleasant' . . .?

[comment]

44 minutes ago, Wickerman said:

so then I wind up with the addition looking like it's been accepted until the user leaves the record. 

That's not my experience: the script should run as soon as user starts typing into the field.

Another option would be to use both enterable and non-enterable fields and hide one of the sets conditionally. But IIRC this requires version 13 or higher. Still, you could use two layouts or two tab panes for similar effect.

 

[Wickerman]

I'm probably just not scripting it right, leaving out something everyone else knows to do. . . I'm really new to managing this aspect of layouts. 

 

I'm setting a script trigger 'OnObjectModify" to trigger in Browse mode, on a Field placed in a Portal to a sub-table that allows record creation via the relationship, like so. The field has a drop-down value list.   Basically, if you have the right privileges, the script just exits, allowing you to go ahead with the entry while if you don't satisfy the test, the script takes you to the first field on the layout.  When I try it out, the dialogue box appears *after* the new record has been created in the portal row.  ?

[webko]

I generally do not allow creation across relationships - I open a modal window or popup to directly access the child table instead, and script the addition of the foreign key....

[comment]

8 hours ago, Wickerman said:

The field has a drop-down value list.  

Sorry, I didn't realize that. That will make it slightly awkward, because even when using 'OnObjectModify" there will be a flash of the record being created and the value being selected before the script steps in.

Perhaps you should make the field itself a button, and have the attached script go to the field if the credentials are right.

 

Edited September 29, 2016 by comment

[Wickerman]

Okay thanks fellas -- that gives me plenty to chew on for now . . .