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.)
One thing Phil did not mention is that global fields can be accessed from any context, you do not need a relationship.
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.
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.
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.
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.
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.
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
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!
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.