remove the ability for anyone to create records via the empty portal row. Then create your own "new line" global fields and script outside (above or below) the portal. This way you can control privileges, validation and even visibility of those fields completely.
I usually have a set of global fields and a special relationship just for creating related records. That gives me full control over what happens when they try to create a record. Including hiding the fields and displaying a text box that says they don't have permission to enter inventory items for this record ( or something less accusatory ).
Assuming you are running version 13 or later of Filemaker, you can change the fields on the portal so they are not editable from the portal, by unchecking 'field entry' in browse mode, on the data tab via the inspector.
Next create a pop-over button with the same fields but with 'field entry' checked in browse mode to edit the data.
Then use a script trigger to test if the user has edit rights before the pop-over opens up. If not, you can either do nothing or script it to display a dialog explaining that they do not have permission to change data on this related record.
Appreciate the fast and consistent answers.
I've thought of this approach as well...but it essentially pulls security out to the script level.
Is there a better way that leaves security application in the Privileges area?
Short of that, I'll have to script it all, but that's exactly what I'm trying to avoid.
Our suggestions don’t change your security settings at all, just your UI and the method records are created. If they didn’t have the correct privilege set, it would still fail.
One thing to note, you have to be careful with script triggers and pop-overs.
1. Sometimes they don't fire when you think they should. An "Enter" trigger sometimes doesn't fire until you are effectively "exiting".
2. I've seen a few instances, if you don't address it, where you can tab into a pop-over and circumvent the script trigger.
Yes, I see you point. Then you could add the script trigger on the fields on the pop-over, to check permissions before allowing access to the field data. Then you could add more fields to the pop-over than show in the portal row too. That way your clients could access the pop-over but only be able to change data if allowed.
Thank you again for your input. It's a bit frustrating to have to "work around" it, when VIEW has limited access by calc, and EDIT has limited access by calc...but CREATE does not (Why?)...but so goes the imperfect world...
What I'll do in this case is make temporary holding fields on the Inventory record for the LineItem info, then create the related record with that data on commit, as well as wiping the temp fields.
By doing it this way, I don't have to script a security check...the entry of data into the fields will be on the Inventory parent record which is already limited by calc for EDIT within the native FMP security schema...and thus any improper try will get flagged right there before the 'child create' process even starts.
Simply adding to the bottom line of a portal is the most simple UI...simpler than a popup...so I've made the popup look as much as possible like the bottom portal row.
I appreciate your input and the discussion...Thanks!
Actually...I changed my mind and found a cleaner way...
Just posting here in case it gives someone else another option later...
Since it is just the "limbo" state when a portal row is being typed in...but the record is not actually created yet...I force the record create only, then let them edit it in the UI they are all used to already.
A "New line" button is put on the layout which runs a script:
1. Set variable $ID to the UniqueID on the parent record
2. open a new window at 2px x 2px
3. go to a blank layout based on the LineItems (child table)
4. Make a new record
5. Set the new record's ID to the variable in Step 1
6. Commit the record (skip validation)
6. Close the current window
7. Resize the layout to orginal proportions
A slight window flicker on PC, but not horrible.
Now the line item is created...the "Not Empty" validations are suppressed, and the new line can be edited through the portal within the "EDIT" access privileges.
Works well for what I'm trying to control...hope it helps someone else...or at least gives another option to consider if you need it.
I don't consider using global fields and a special creation-relationship...a "workaround". But instead, "best practice". It is easy to setup, and control. With a little forethought, you can repurpose the layout objects and scripts to use anywhere you need to create a record.
Having to scroll to, or jump via script, to the bottom of a portal to create a record doesn't feel very natural or modern. But maybe that's just me.
With the advent of pop-overs, and slide-panels, you can create a very slick integration of record creation that doesn't involve "new windows" or layout-swapping.
If I had originally built it this way, I likely would have gone with a popover or set of globals on the layout itself.
There are additional benefits in the circumstances to this as well that I won't go into.
Like the "access privilege subsets" thread, however, this is a long standing dbase that is evolving through cross-training of employees...and feedback from my beta-test group says convincingly that the change in UI is a bigger negative than the improvement in UI is a positive. It may be better or the same...but it's different and that's not OK.
When originally built, there was a mandate that no one would ever see anyone else's inventory...this whole "loophole" showed up when that policy changed and folks could now see selected others' inventories.
Globals and scripted create can be quite simple and easy to control, but then require retraining and complaints from the majority of the staff.....oh to scrap it all and start over....