FileMaker: Explore

Welcome to The Support Group's blog, where we hope we can contribute to the FileMaker community — experienced developers and beginners alike. We believe that whatever we're doing — whether it's designing a new system or teaching a training class — everything starts with dialog. We welcome your feedback and ideas.

Select Script Options by First Performing Them Manually

by .(JavaScript must be enabled to view this email address) on Jan 16, 2012, filed under: Tips & Tricks, General Tips

Sometimes, when writing a FileMaker script to do a find, sort, or export, doing it manually first can save you LOTS of time.

I was just tasked with creating a script to export all the fields on a layout. The layout, however, is non-trivial and contains fields from multiple different tables, and the relationship graph I inherited is very complicated and nearly impossible to decipher. It would have taken me HOURS to identify the table occurrence and field name of every field on this layout and then set up the export in a script.

What I did instead was first perform the export manually. When exporting manually, the Specify Field Order for Export dialog defaults to showing you all the fields on the current layout, including the related fields (when writing a script, the same dialog only allows you to choose each table, since there is no “current layout” for the script to use). I chose the Move All button to select all the fields on the layout, went back to editing the script, added the Export Records script step, and chose Specify export order. The last, just-performed export was already there by default. I was done in minutes.

You can use the same idea to speed up specifying a sort order (where you can again choose the current layout’s fields) or search (where it’s easier to find fields laid out on the screen, rather than hunting around for them in the Edit Find Request dialog).

0 comments

Understanding Line Indentation in Text Fields

by .(JavaScript must be enabled to view this email address) on Jan 10, 2012, filed under: Get ( Answers ), Tips & Tricks, General Tips

I recently had a student ask, “How do I get word wrapping to indent the second line, and all lines thereafter, for a standard [edit box] text field?”.

“That’s easy,” I said, and I proceeded to show the class by going into Layout Mode, selecting a large text field, turning on the text ruler and … uh… what? I suddenly remembered that the indent tools (i.e., the “first line indent”, “left indent”, and “right indent” sliders) are only activated when a text object (or merge field) is being edited … but cannot be leveraged at all for edit boxes.

I looked up and saw the entire class staring at me, waiting, with that same smug look on their collective face: “Let’s see you explain this one, smart guy.”

After a good cry, I finally found the answer by playing with the Paragraph menu (located in Format > Line Spacing > Other… or, using the Inspector tool, on the Appearance tab > Paragraph). By selecting the edit box and using this dialog, I set the “Left” indent to 8 pixels, and set the “First line” to -8 pixels. This is how we tell FileMaker, “Indent by 8 pixels all lines in this word-wrapping edit box; except the first line, have that one start right up against the left margin.”

Whew. Sometimes all we need is a good cry.

0 comments

Using Custom Extended Privileges

by .(JavaScript must be enabled to view this email address) on Dec 28, 2011, filed under: Tips & Tricks, Advanced Techniques

Over the years I have noticed that some beginner and intermediate level developers are not aware of the possible uses of extended privileges, other than as a means of controlling methods of sharing (such as through standard FileMaker Pro to Server networking, Instant Web Publishing, PHP, etc…). Extended privileges are probably one of the most underused features in FileMaker and at the same time incredibly simple and powerful with regards to enforcing security and access control. I have seen people write very complex scripts that attempt to manage or limit access to specific areas of a system, creating elaborate, complex security access levels or hard coding some of this security functionality within the data structure when they could have used custom extended privileges to do the same in a cleaner and most efficient manner.

What are extended privileges? Extended privileges are just permissions that can be attached to an existing access privilege set and are used to determine whether a user has access to certain elements within a system or not. The most common type of extended access privileges are used to determine if users can access files via FileMaker networking ([fmapp]), ODCJ/JDBC, or the web publishing options.

Why are they powerful? FileMaker allows developers with the ability to create custom extended privileges, which are basically keywords, that can be called from any script, calculation or custom function in your file. This simple feature gives you the ability to setup access control groups.

Read more ►

Let’s say we are managing a system for a company that has three departments: Accounting, Production, and Sales. Each department has three levels of user privileges that need to be setup: a Manager level, a Supervisor level and a User level access. That’s a total of nine different privilege sets, not including development accounts.

We have a set of financial reports that must be accessible to all managers and to the accounting supervisors. For simplicity purposes, let’s pretend we have a script that runs all reports and at the beginning of this script we run a test to determine if the user running the script has access to these report; if not, the script should stop.

Without the use of extended privileges we could just setup the following script steps:

# test access
Set Variable [ $privilege ; Value: Get ( AccountPrivilegeSetName ) ]
If [ $privilege ≠ "Accounting-Manager" and $privilege ≠ "Accounting-Supervisor" and $privilege ≠ "Production-Manager" and $privilege ≠ "Sales-Manager" ]
   # User doesn't have access
   Exit Script
End If
# User has access, continue with reports…

A problem here could be if at one point in the future the developer decides to change the names of the access privileges, add more levels or departments or maybe revoke access to these reports to a certain group. He would have go into all the scripts that handle this restriction and make the changes.

The solution: we can create an extended privilege set called FinancialReports and assign it to the privilege sets that should have access to the reports. Defining a new extended privilege is as simple as specifying a keyword, giving it some sort of description, and then checking off which privilege sets should have it.

When it comes time to test for user access we can simplify our script steps with the following:

# test access 
Set Variable [ $privilege ; Value: Get ( AccountExtendedPrivileges ) ]
If [ IsEmpty ( FilterValues ( $privilege ; "FinancialReports" ) ) ]
   # User doesn't have access
   Exit Script
End If
# User has access, continue with reports…

The Get ( AccountExtendedPrivileges ) function returns a carriage return separated list of all the extended privileges associated with the privilege set the account is part of. In this case, if we were logged in as an accounting supervisor, it would return

[fmapp]
FinancialReports

The FilterValues function compares that list to the second input (“FinancialReports”), and shows all matching values. So, if the result of the FilterValues function is empty with no matches, the user does not have access to the reports, and the script aborts itself.

This way, if we rename, add, or remove privilege sets or revoke or grant access to certain groups, our test won’t have to change (unless we rename the extended privilege itself, so it will require some careful planning on your part). In this scenario we can control access to these reports using only the custom extended privileges we created.

The same solution could be applied to other scenarios were there we have access to areas of a system that overlap within different accounts. For example, you might want to show a Daily Production Report to users in either the Production-Manager, Production-Supervisor, or Sales-Manager privilege sets every time they log in into the system.

0 comments

Contract post ▲

Searching Across Relationships for “Empty” Fields

by .(JavaScript must be enabled to view this email address) on Dec 27, 2011, filed under: Tips & Tricks, General Tips

Have you ever wanted to find records where a certain field is empty? Suppose you are updating your contact database and trying to capture email addresses for as many people as possible. You need to find every person for whom you do not have an email address. When searching in FileMaker, the equal sign operator (=) is used to find an exact match; when used by itself in a field, with nothing else following it, it tells FileMaker to find records where the field is empty. So… easy enough, right? Just go to the contact detail view, enter Find mode, type an equals sign into the email field (or select the symbol from the Operators popup in the toolbar), and click the Perform Find button.

But… suppose you are tracking contacts that may have multiple emails. Such a setup probably requires a relational system where emails are stored in a separate table, with a relationship defined from the contact table to the email table. On your contact detail screen, a portal can show you the many related email addresses for each person.

In this scenario, typing the equal sign in the (related) email field isn’t going to work. The problem is that we are no longer trying to find contacts records where an email field is empty. Instead, we’re looking for contact records that do no have a related email address record. In other words, it’s not that the email field is empty (using the equal operator will find contacts where a related email address record was created but not filled in); it’s that the email record doesn’t exist. And finding a non-existent record is kind of hard. I mean, you can’t… it doesn’t exist.

FileMaker: Explore

Select Script Options by First Performing Them Manually

Understanding Line Indentation in Text Fields

Using Custom Extended Privileges

Searching Across Relationships for “Empty” Fields

Got Questions?

Log In

Categories

Most Recent Entries

Locations