Security
How do I secure SeedCode Calendar?
For most of the solution, standard FileMaker security practices are fine. For an introduction to this topic search FileMaker’s built-on help for “Security” and read the section titled “Planning Security for a File”.
A few areas of the software require special consideration, however. For these areas we’ve put a custom menu in place to control deletions and orphans. This menu is very unobtrusive and easily removed (even without FileMaker Advanced). You can read all about this in Deleting Contacts.
Remember, frequent backups are essential to protecting your file. Its worthwhile to take the time to setup a backup schedule that doesn’t require any intervention on your part. Serving multi-user files with FileMaker Pro Server is often essential for this.
How Do I Let a User See Only Their Records?
Overview.
This is very easly done; you’ll use FileMaker’s built in Access Privileges to create rules as who which records a logged in user can see, which they can edit etc. You can restrict which layouts they can see and even which specific fields they have access to.
If you haven’t worked with FileMaker’s Access Privileges before, take a moment and read the overview in FileMaker's built in help, check out Contents > Protecting databases with accounts and privilege sets > Creating and managing privilege sets > Editing record access privileges.
For more information about limiting which records a user can see, continue to the "Editing record access privileges" page: you're interested in the "Limited" option under number 4.
Tips & Tricks.
The only tricky part here is finding some attribute of the user’s log in to tie that login to a record in the calendar’s User table. The items you have at your disposal are Get ( AccountName ) and Get ( PrivilegeSetName ). The privilege set name is probably going to be used for general things like “administrator” or “sales rep” and may be used in FileMaker’s Access Privileges to limit what a user can see or edit. You may, for example, craft access privileges so that sales reps can’t access the admin tabs on the calendar.
So you’ll probably be using Get ( AccountName ) in your access privilege calculations to compare a logged in user with the user linked to an appointment. There are two basic approaches here:
1. You can make the user’s Account Name match a field already in the database. So you could make sure all your accounts are created with the Account Names being real first and last names of your users. Account names would be things like “Bill Smith”. If you did that, an access privilege calc that would let the logged in user only see their appointments would look like this:
Not isempty ( FilterValues ( List ( CalDailyApptUsers::UserNameFirstLastCalc ) ; Get ( AccountName ) ) )
Make sure this calc is set to evaluate from the context of CalDailyAppointments. So there are a couple things to note about this calc. The first is that it just returns a 1 or 0; a 1 if the Account Name is one of the names of the users linked to the appointment, a 0 if it is not. That is how all your access privileges calcs should be written: to return a 1 (ie. be true) if the user can see, edit, etc. the record. The second thing to note is that we don’t use the = sign. This is because an appointment can have more than one user, so its user will never be “equal” to any one user. Instead we use FilterValues to see if the Account Name “is a member” of the users on the appointment.
2. The second approach is to create your own field in our users table to match the account name; you’d essentially be recording the account name in FileMaker. Do not, of course, record the user’s password in FileMaker as that would not be very secure. In this case you’d use the same kind of calculation as the one above but would substitute the name of our field for the field “CalDailyApptUsers::UserNameFirstLastCalc” used in the calc.
Now of course you may want to have some users that can see everyone’s appointments: you don’t have to mess with the calc above to do this, simply assign these “power users” to a different privilege set that doesn’t limit the appointments they can view at all.
Why Are There “Demo” Accounts & Privilege Sets.
As you may know, we offer a locked demo of the calendar so that folks can get their hands on the file before they purchase it. In order to make sure the demo is up to date, we use the same code base for the demo and for the actual file. That’s why you’ll also see a “Demo Date” script in the list of scripts. None of these objects do anything unless you log in as a demo use.
You can simply delete the demo accounts and privilege sets.
