11 Replies Latest reply on Aug 4, 2015 5:23 AM by ninja

    Limiting "Create" access through portal


      Howdy all,


      Found a loophole that I'm trying to close and looking for ideas.  Someone has to have handled this before, surely.


      I have a table of inventory records as parent, and change records or "line items" as child


      Inventory --< Line Items


      During creation of an inventory record, it is stamped with the account name of the account creating it.

      Any person can VIEW all inventory records, but can only edit from the account under which it was created.

      Since they need to edit their own inventory LineItems, and Create new ones on their own sheets, CREATE access is set to "Yes" for the LineItem table.


      Line Item entry is done through a portal.  Layout based on Inventory, portal lines showing records from LineItems,


      The Problem:

      When I view someone else's Inventory record, I can enter info on the blank bottom portal line since I have CREATE access to the LineItems table...but the record isn't actually created until a commit action is taken...so I can enter an entire record while in "uncommitted llimbo" and since it is through the portal, it does not count as "Editing".

      Ideally, I would simply set CREATE privileges on the LineItems table and limit them...but Create Privileges are simply Yes/No.


      I've tried forcing a "commit" on the line item to make the record exist...but it trips all of the "not Empty" validations and freezes the system.


      Short of pulling the privileges out into a script, how do I close this loophole?


      Ideas and comments appreciated,


        • 1. Re: Limiting "Create" access through portal

          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.

          • 2. Re: Limiting "Create" access through portal

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

            • 3. Re: Limiting "Create" access through portal

              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.



              • 4. Re: Limiting "Create" access through portal

                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.

                • 5. Re: Limiting "Create" access through portal

                  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.

                  • 6. Re: Limiting "Create" access through portal

                    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.

                    • 7. Re: Limiting "Create" access through portal

                      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.

                      • 8. Re: Limiting "Create" access through portal

                        HI Guys,


                        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!

                        • 9. Re: Limiting "Create" access through portal

                          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.

                          • 10. Re: Limiting "Create" access through portal

                            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.

                            • 11. Re: Limiting "Create" access through portal



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