Calendar Package Permissions

Note: This document will be rolled into the Design Doc in the very near future.

First, the cal_item permissions:

1. read: can view the item
2. write: can add and edit the item
3. delete: can delete the item
4. invite: can allow other parties to see the item

Second the calendar permissions:

1. public: everyone have read permission, and can see the items, registered and un-reg-ed users alike. This implies applying read privilege to group "Public."
2. private: only the member of the party can see the items. This implies granting read privilege to the owner group. I would say read only 'cause it might be undesirable for group members to edit or delete items.

There three conditions for a calendar:

1. by default, all items are public
2. by default, all items are private
3. by default, no conditions defined.

The major assumption here is that the Permissions of the Cal_item can overwrite the Permissions of the Calendar.

Under the first two conditions, when a new cal_item is generated, it will by default inherit either public or private. If there are no default conditions (3), then the user would need to define what kinda of permission is going to be associated with the cal_item.

In generation, the owner of the calendar would need to:

1. assign calendar admin. This implies granting read, write, delete, invite permissions to some party.
2. assign default calendar permissions (optional).

The calendar admin can grant or any combinations of read, write, delete and invite) to other member of the party which uses the particular calendar on a item specific basis and on a calendar level. Once more, permisssion assigned to specific items can overwrite those of the calendar.