Jump to content

No 'Limited' Record Creation option . . .


Wickerman

This topic is 2762 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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?

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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' . . .?

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.  ?

Script.jpg

Link to comment
Share on other sites

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 by comment
Link to comment
Share on other sites

This topic is 2762 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.