Forum .LRN Q&A: Bugs in OpenACS Calendar Module - I would like to fix.

Collapse
1: Bugs in OpenACS Calendar Module - I would like to fix.
Posted by Richard Hamilton on 05/27/05 10:33 PM
Just want to check with everyone before making a change to the calendar module. I need to know if what I propose to do will upset anyone's current use of the module.

Issue
~~~~~

If you set up a calendar for a group of users and set permissions such that only parties within that group should be able to see related calendar items, the calendar module will show the 'Description' of the entries to all users who have access to the calendar instance irrespective of the permissions.

The detail of the calendar event is protected but the description is there for all to see.

This constitutes a security leak because:

1) People tend to give entries meaningful names which means that everyone can see what the event is even without having to read the detail.

2) You are revealing that there is an event there despite that event being permission restricted.

This is a clutter mongering pain because with a large group the calendar rapidly becomes unuseable because of the number of event descriptions being displayed.

There is currently no way for a user to filter out the descriptions that they are not particularly interested in.

Solution
~~~~~~~~

The obvious solution is to assume that this is not intended behaviour and 'fix' the permissions so that descriptions are only shown to those with 'read' permission on the event.

However, in the absence of an availability checking function, was it intended that you could see when time had been blocked out by someone even when you are not allowed to see the detail?

Should we therefore show time 'blocks' instead of the description? If we do this we still have clutter.

My preference is to only show item descriptions that the viewing party has 'read' permission on, to accept as a user that you only see a subset of other parties' the events (that other users actally want you to see) and then progress to create an availability checker/ meetings arranger in the near future.

The meeting arranger could utilise the planned internal site messaging module along with maybe a simple workflow driven process for setting up appointments and meetings.

Please let me hae any thoughts and let me know if I can 'do the deed' on the calendar permissions fix.

Also, maybe we should add a display filter function to allow a user to select which of the 'calendars' (or event types as they really are) to display. This should probably default to "all upon which I have 'read'" and allow for arbitrary de-selection of one or more.

Thanks

Regards
Richard

Posted by Richard Hamilton

Collapse
2: Re: Bugs in OpenACS Calendar Module - I would like to fix. (response to 1)
Posted by Andrew Grumet on 06/03/05 06:17 PM
Can you explain the use case a bit further?

As best I can tell, you're talking about the ability to set permissions on individual calendar items ("cal_item" object type), separately from the calendar itself.

The data model certainly permits this, though one would have to turn off permissions inheritance on the individual calendar item as well.

If this is in fact the use case, I'd be interested to hear more about situations where this would be desired behavior vs. creating a separate group or perhaps a subgroup.

Collapse
3: Re: Bugs in OpenACS Calendar Module - I would like to fix. (response to 1)
Posted by Richard Hamilton on 06/04/05 11:12 AM
Andrew,

Thanks for the reply. I think the best thing would be for me to explain again what is not happening and you could tell me whether this is in fact a function of incorrect use rather than a bug! 😊

1. Installs and mounts instance of Calendar package.
2. Creates two groups - group 'Family' and group 'Friends'
3. Grant permissions for both groups to use package instance.
4. Sets up in Calendar ui two 'Calendars' - 'Family' and 'Friends'
5. Sets permissions on Calendar 'Family' so that only members of group 'Family' have read and write permission.
6. Sets permissions on Calendar 'Friends' so that members of both group 'Family' and group 'Friends' have read and write permission.

Now we find that when a member of group 'Friends' visits the Calendar module they can see all the 'Family' calendar event titles! If they click on the event permission is refused but they are being shown the title which in most cases people have meaningful info in.

Also, in a large group you get an overcluttered display unless you could select in your ui that you only want to view for example 'Family' items instead of items for all groups to which you belong.

Am I missing something obvious here?

Thanks.
Richard

Collapse
4: Re: Bugs in OpenACS Calendar Module - I would like to fix. (response to 1)
Posted by Andrew Grumet on 06/06/05 06:31 PM
Ah, okay, this is helpful.

Yes, from your description it sounds like a bug. We haven't had a chance to explore the "multiple calendars per package instance" capability at Sloan. The simplest workaround is to set up separate instances of the calendar package --- one for Family and one for Friends.

However, if you'd like to fix it, the first thing to do is modify the queries on the main page to filter all listed calendar items by permission. There is a standard technique for doing this, which involves adding a clause that would look something like this (warning: I have not tested this for correctness or speed!):

and exists (
select 1
from acs_object_party_privilege_map ppm
where ppm.object_id = cal_items.cal_item_id
and ppm.party_id = :user_id
and ppm.privilege = 'read'
)

Andrew

Collapse
5: Re: Bugs in OpenACS Calendar Module - I would like to fix. (response to 1)
Posted by Richard Hamilton on 06/08/05 07:15 PM
Andrew,

Thanks for the reply. That is also extremely helpful and is exactly what I was proposing to do. Thanks also for the tip on how to do it - I have just been through the process of adding project and task level permissions to the Project Manager code so now is a good time to do this before I forget how! 😊

I'll make the changes and commit them to whichever version of OpenACS is now the current 'dev' version. I guess this would then be rolled into .LRN via the net release.

Regards
Richard