Is it possible to setup zulu to filter based on the user account so that each user only see there calendar info.
Example: I have several salespeople that use FM to enter notes, appointments, etc. If 'Jim' sets up a meeting with Customer A can that display on a cal dav associated for 'Jim' so that only he needs to subscribe to it? I would like to be able to subscribe to everyones but each salesperson only needs to see theres.
Lastly, does this turn each calendar into a read/write which would then allow others to change someone else's calendar?
Thanks in advance

Hi. The simple answer is that Zulu respects FileMaker's access privileges. So if your access privileges are such that users can see everyone's events but only edit their own, then Zulu will follow suit.

That is the simplest way to set it up, and perhaps suggest that users disable calendar's they don't need to see in iCal.

You can get more creative if you don't want users to SEE someone else's calendar. Again, you can do this with access privileges. Or you can apply access privileges to the CalendarList records instead of the Event records. (These CalendarList records contain one record for each calendar in Zulu) This can be faster since FileMaker only has to evaluate the visibility privilege calc once, instead of once per event.

Hope that helps,

John

I'm trying to set up access for one particular user (only) to view a certain calendar.

On the privilege set for this particular user, I set the "view" layout restriction to "limited" and used the following access privilege calculation:

zulu_filterValue = Get(AccountName)

Then in the "zulu_filterValue" field on the Calendar I want this user to "see", I put in this users account name.

But when syncing, I receive the following error:

Sync failed: java.io.IOException: Could not read file mappings from serialized data:

For testing purposes, I switched "view" access privileges to "full" for this user and I received no errors. Perhaps my understanding of this issue and subsequent calculation is in error.

Any ideas?

The field zulu_FilterValue is used somewhat differently. In conjunction with zulu_FilterKey it restricts this calendar to show only those event records where the event field described in zulu_FilterKey contains the value in zulu_FilterValue.

Read this to learn more: http://www.seedcode.com/pmwiki/pmwiki.p ... .Filtering

So the filters restrict which *events* show up for a given calendar. To restrict which *calendars* a user can see, you might do something like this. Say you only want users of a given privilege set to see only the calendar with a UUID of "rsts54sggsus8", you'd set the record's (not the layout's) view limit to be something like zulu_uuid = "rsts54sggsus8"

Hope that helps,

John

Thank you for replying. I am still receiving the same error when using the UUID as the privilege set calculation.

Here's the setup:

FileMaker & Google Accounts to Synchronize:

Filemaker User = test
Google User = test

In the Manage Security section of my database file I added a privilege set, called "test" specially used by the user "test".

I set the Records: to "Custom Privileges" and find the "ZuluCalendarList" Table. I set the "View" attribute to "limited" and then enter in the following calculation:

zulu_uuid = "00111TEST" <--- This is the calendar I want the user to see.

But I still receive the following error:
Sync failed: java.io.IOException: Could not read file mappings from serialized data: 00111TEST

Got it. I'm sorry, I didn't realize this was Google Sync: I thought you were using iCal.

So there is an issue currently when restricting the visibility of individual calendars using access privileges. There is no problem filtering event records using access privileges, so you can set this up so only this calendar has events (those are the only events the user is allowed to see) but you currently can't restrict the calendar's visibility using access privileges.

We're working on this and will post a fix here when we get it.

Sorry for the inconvenience!

- John

Any progress on this? Thanks

Hi Matt,

Sorry, we forgot to update this post, but we did resolve this in build 1.247. We're about to release 1.254 (today or tomorrow) so you may want to wait for that to upgrade.

Thanks,
Jason