10 Replies Latest reply on May 17, 2010 8:22 AM by aammondd

    Just checking here unrelated global fields



      Just checking here unrelated global fields


      Ok I have a global table that captures some environment information Account Name for instance.

      I have a table that is linked to the global table of user name privildeges


      Before I get too far down the road with this concept I want to make sure its going to work


      Does the global record need to be related to the layouts main table in order for me to script trigger some validations based off the current user names privileges.


      For example 

      If ["Get (Account Name) = GlobalEnvironment::Current User and UserAdditional::Permissions::Override ="X"]

       do something


       show custom dialog "You do not have permission to perform that function

      End If


      Im pretty sure I need to link the current layout to the GlobalEnvironment table for this to work

      I have a field that is current layout field key which I populate with the main key on layout/record load.


      Do I actually need it 


      Its getting late in the day I may not be thinking clearly so pardon if this is really a dumb question.

        • 1. Re: Just checking here unrelated global fields



          What do you mean by a "global" table? A table of global fields? (Global storage is a field property--not a table property)


          On the other hand you can set up a table of records and relate it to any other tables as needed, using the cross product (X) operator instead of the = operator so that all the records in this table are accessible to any record in the other table. That what you have in mind?


          Note that global fields behave differently when you share the database over a network.


          ...and UserAdditional:: Permissions:: Override ="X"]

          Not sure what you have in mind here, but that sounds like something better handled through Manage | Security (Manage | Accounts & Privileges in older versions.)

          • 2. Re: Just checking here unrelated global fields

            One thing Phil did not mention is that global fields can be accessed from any context, you do not need a relationship.

            • 3. Re: Just checking here unrelated global fields

              Yes Phil I mean a table of all global fields


              I may use the cross product operator for part of this that would help.


              By adding those security functions I can setup processing rules that are more data driven than field driven it gives me some more flexibility with validations etc.



              • 4. Re: Just checking here unrelated global fields


                The problem is that the security table isnt linked except through the global table. By setting my primary tables cross product to this environment table it should do the trick so I don't have to keep the tables key in my environment record.


                Basically Im trying to replicate some functionality that exists in a much more expensive product (Peoplesoft) in FM. The two products are very similar in many ways.


                • 5. Re: Just checking here unrelated global fields

                  Like Tom said,


                  If the field's storage is set to global, it can be accessed from any table and/or layout in your system whether you define a relationship to it's table or not. I sometimes define a "globals" table to put all globals not used to define a relationship so that I have them all in one place. I don't normally link this table to anything as there's no need.

                  • 6. Re: Just checking here unrelated global fields

                    Also, keep in mind that when you share a database over a network. Client users can't see the changes another user makes to a global field and the changes they make won't persist, the values revert when the user closes the database.

                    • 7. Re: Just checking here unrelated global fields

                      Exactly Phil


                      Thats the reason I use them for user envrionment settings.


                      I link them to use them as portal keys pretty often.


                      It also allows me some ability to scroll a set of related fields as if they were in a portal.

                      • 8. Re: Just checking here unrelated global fields

                        this also alows me to create some security functions for a non filemaker person to be able to admin form a control panel.

                        That way they dont have to understand or be taught FM native security 

                        • 9. Re: Just checking here unrelated global fields

                          Howdy aammondd,


                          It sounds like you've got your plan pretty well laid out but if there's still a consideration left open,

                          I would put my two cents on the side of teaching FM native security.  It is pretty simple, and far more secure than fields in tables.


                          You know your app and your security needs, I don't.  I would, however, default to using the wheel provided instead of creating another one.  How long have you worked to make the second control system vs. how long would it take to use/teach the one provided...


                          Just one foot on the soapbox. ;)

                          Enjoy the day!

                          • 10. Re: Just checking here unrelated global fields

                            One of the things I am using this for is process/validation overrides.


                            At this point I can now call the script that serves as a function to check if this  user has access to overide the normal process and keep an audit trail as to when this occurs.

                            By moving this to a security like function like this I can add it ad-hoc to nearly any part of the database I wish and any process I wish.

                            This is part of why I need certain script  triggers to fire on a majority of fields.


                            Im trying to work up a custom dialog box scheme that is also table driven.


                            I realize the native security has value too. It just doesn't seem to have enough flexibility with what constitutes "access"


                            For instance we have a periodic checklist process that is generated for each vendor in the system which requires certain fields to be updated. The current process will not allow for a new checklist to be created until the current one has been completed. However managers want the ability to override this validation process.


                            In addition I can use this process and some others I was talking about to trigger a check for field level audit control and write out audit records.


                            Overall it just gives me the ability to be very flexible with how I implement security like features not only for FM native functions but for the business processes that the application is designed to handle.