Editor’s note: Today I’m pleased to present a guest article by Michael Rocharde, author of FileMaker & Me, an interactive multimedia book focusing on FileMaker Interface Design.
FileMaker has always been an incredible tool for generating reports and for many years, I used to have a report screen with banks of buttons to generate all of the individual reports. In the last few years however, I’ve added a global field, to the footer of each module data entry screen, with a pop-up menu, listing all of the different report options for the module in question. To that global field, I’ve added an onObjectModify script trigger which sets the name of the report as the parameter that generates the report they want. Simple, very effective and it has the added advantage of giving the user all the reports that are relevant to where they are at the time.
Recently I had a project where some of the reports that were required were restricted to the different privilege sets and I was looking for a quick (and easy) way to accomplish this. I started thinking about whether I could use a related value list to solve the problem and came up with, what I think is, an elegant and very simple solution.
The first thing I did was create a Reports table with just two fields, Group (for the privilege set) and Report (for the name of the report itself).
The next thing was to create the privilege sets themselves (none of these privilege sets have any particular settings).
I then created a global field, GRepOptions…
…(which is going to display all of the different report options) in my module table and a calculated field PrivSet…
…which is used in the relationship to restrict access to certain reports.
(Note that this table is just for demonstration purposes but, in the real world, you would add the GRepOptions field to all of the tables that you want to report on).
We’ll now add our reports layout to list all of the different reports and add access to each of them.
As you can see, the Administrator group has access to all 6 reports, Office Staff has access to 4 reports and Staff only has access to 2.
The Group field…
…uses a value list that has the different privilege sets.
…which is all very well and good, but, as a developer, I need to have access to all of the reports and the relationship doesn’t allow that as I’m logged in as “[Full Access]”. For this reason, I set an auto-enter option on that field for each new record:
(Note that the user doesn’t see this value, is not aware that it exists, and cannot change it).
All that we have to do now is add our GRepOptions field to our screen and format it to display the related reports.
So with all done, let’s look at what our options are for each of the different privilege sets:
(Bear in mind, that on your screen the PrivSet field doesn’t need to be displayed.)
We’re almost done. We now just need to add a script trigger to the GRepOptions field…
…which runs the Report Options script…
…and that’s it. Just as a recap, the only reports that each user can choose from are the ones available for their specific privilege set. We don’t have to set up any complicated privileges or access or write lengthy conditionals, in the script, to restrict access.
If there is a downside, it is that you have to make sure that the report names are accurately typed in the script above but otherwise it is a really easy methodology to implement and use. (If you wanted to, you could add a simple integer number field to each report and then have a number field (in your reporting table) which looks up the value of the currently selected report and then uses that value as the script parameter).
One Last Thing
All of the work that you’ve done here could easily be undone if all users could access the Reports screen. For that reason, that layout is hidden and can only be accessed via a button that runs the following script:
The Else If line is shown in full below:
This means that only developers and Administrators can access the screen to add/delete reports and set privileges.
© Michael Rocharde, January 12, 2013
Michael Rocharde has been a professional FileMaker Developer since 1987. He has worked with Excelisys (www.excelisys.com) since 2002. He is also the author of FileMaker & Me, an interactive multimedia book focusing on FileMaker Interface Design. Available only for the iPad, this book is available at the iTunes store.
Michael currently lives in the south of France, just outside of Toulouse. He can be reached via email at rocharde@excelisys.com or michael_rocharde@me.com or via Skype michael_rochard or at 360-450-5583.
Very Nice!
I was trying to construct something similar and this will get me going in the right direction. Thanks for all the work that is done on this site.
Glad it helped.
Personally, I try to avoid putting interface related globals in my data tables. Your technique would also work if you had a separate “globals” table which had your privilege set global. The value list will evaluate properly if it is set to use the table “globals” as its starting place.
In that case, you would need to only set the global when opening the file in one place. If you had conextual repots, i.e., module dependent, there are a few techniques. One would be to set a global for the module in the globals table using an on layout enter script. and have your value list relationships also include that. Another would be to set up different value lists, per module, and dedicate global calculation fields to each module.
In all of these, there never need be a global in the data table.
You’re right, Carter; you could do it that way. For a single set of reports that are not contextual, it is probably the better way of doing it but for contextual reports, it is more work to set up doing it your way. Personally, since I don’t use, or like, the Separation module, I don’t mind having a few globals in my data tables but this is personal preference.
Michael, I’m totally for different ways to doing things. So the way most appropriate to them need of the moment is the way. However, if I might correct some mis-presumptions of my suggestion. This is really irrespective of the Separation model. The idea is that fields and tables should be specific to their purpose. So, if a data table has fields for interface, it mostly confuses things. (I especially cringe when I see a fields used to label a set of fields.) So, for me, it’s just a framework discipline, which can be broken for convenience.
I think the other thing I would point out, is that the method is less structure and work overall. It allows you to define the flexible list once, not once for each table. Sure, if it’s contextual you need to do the layout script triggers, to manage it, but if it’s not contextual, you don’t. You get the benefit just making relationship.
… I mean, “… just making the relationship and value list once.”
Carter, I appreciate your thoughts. As you say, there are many ways of doing things; not all of them are the best way all of the time. Thanks for taking the time to comment.
Hi,
You can accomplish this without the need for a new reports table where privilege sets and layout names must be hard coded. I’ve found that the design function ‘LayoutNames’ only returns the layoutnames to which a certain user has access. Just use some clever naming convention in the layout names. you already have one, mentioning ‘report’ in all report layout names. Then parse out to which reports access is allowed. To present this information as a value list, some more work is needed. Filling a global field with the parsed report names and linking to a table containing all report names could be one approach.
The advantages:
1) no need for duplicate hard coded information: deny access to reports by setting these options directly in the privilege sets dialog
2) real security: reports you’re not allowed to are really not accessible. No need to hide.
Best regards,
Joris Aarts
ClickWorks
Hi Joris
Yes, of course you can do it that way. This is just a simpler approach that is very easy to implement without having to figure your way around the privilege sets dialog which is, to a lot of people, very confusing. As to real security; is there truly any difference?
Easy to implement and elegantly done !!!
Thanks, Dom. Glad you liked it.
Hi Michael,
thanks for your answer.
Sorry to insist but to my opinion ease of implementation is a false friend as it leads too often to deployments that are hard to maintain. I prefer ease of maintenance (recurring) over ease of implementation (once).
You expect your developers to create privilege sets so they already need to figure their way around there. If they are already doing that, why not going that one step further down the road and link the report directly to the privileges?
Real security: you suggest to hide the layouts. That’s called security trough obscurity. Once again you rely on the developer to keep the overview layout and future report layouts hidden. That’s another task on the maintenance list.