View Issue Details

IDProjectCategoryView StatusLast Update
0001242SOGoBackend Calendarpublic2011-10-14 14:49
Reporterwimmer Assigned Toludovic  
Status closedResolutionfixed 
Product Versionnightly v2 
Target Version1.3.9Fixed in Version1.3.9 
Summary0001242: Setting of all ACL to None

Users cannot set ALC of all categories (public/confidential/private) of events to "None".

When users set them to "None", Public is set to "View the Date & Time".
It is the same by using WebGUI and Lightning.
I'm using:
sogod SOGoCalendarDefaultRoles '(

I tried to use:
sogod SOGoCalendarDefaultRoles '(
and it worked fine in this case - users can set all ACL to "None".

TagsNo tags attached.


Christian Mack

Christian Mack

2011-05-06 14:21

developer   ~0002437

Tested with SOGo 1.3.7 in the Webinterface.
While giving rights to another user on a calendar with "Sharing..", you have to give this user some right!

You can set all levels "Public", "Confidential" and "Private" to "None", but you have to set either "This person can create objects in my calendar." or "This person can erase objects from my calendar.".

You only can set all but one of "Public", "Confidential" and "Private" to "None" while "This person can create objects in my calendar." and "This person can erase objects from my calendar." are not set.

If you try to set all to "None", then after "Update" security levels "Public" and "Confidential" get set to "View the Date & Time".
So you not only can't set all three to "None", you even get a totally wrong setting!

A user who wants to revoke all rights will be surprised to see the result.
There should at least be an error message in this case.

Delete the user in question from the calendar sharing list to remove all rights from her.



2011-10-13 20:40

administrator   ~0002892

Try to restart memcached between tests. I'm pretty sure the cache isn't updated properly right away.



2011-10-13 20:49

administrator   ~0002893

Try the following patch:

--- SoObjects/SOGo/SOGoGCSFolder.m 075ea8f10b351cafb9c69aab74512b16a263f9c8
+++ SoObjects/SOGo/SOGoGCSFolder.m 00268a7356b2255bd9d593b990a0c053fbf3f7ee
@@ -1637,11 +1637,13 @@ static NSArray *childRecordFields = nil;
[newRoles removeObject: SOGoRole_AuthorizedSubscriber];
[newRoles removeObject: SOGoRole_None];
objectPath = [objectPathArray componentsJoinedByString: @"/"];

  • [self _cacheRoles: newRoles forUser: uid

  • forObjectAtPath: objectPath];

  • if (![newRoles count])
    [newRoles addObject: SOGoRole_None];

  • [self _cacheRoles: newRoles forUser: uid

  • forObjectAtPath: objectPath];

  • [self _commitRoles: newRoles forUID: aUID forObject: objectPath];



2011-10-14 08:10

reporter   ~0002894

Yes, this patch solves problem on my server.




2011-10-14 14:49

administrator   ~0002906

Fixed with:

Issue History

Date Modified Username Field Change
2011-04-06 19:30 wimmer New Issue
2011-05-06 14:21 Christian Mack Note Added: 0002437
2011-05-06 14:54 ludovic Status new => assigned
2011-05-06 14:54 ludovic Assigned To => ludovic
2011-08-22 19:57 francis Target Version => 1.3.9
2011-10-13 20:40 ludovic Note Added: 0002892
2011-10-13 20:49 ludovic Note Added: 0002893
2011-10-14 08:10 wimmer Note Added: 0002894
2011-10-14 14:49 ludovic Note Added: 0002906
2011-10-14 14:49 ludovic Status assigned => closed
2011-10-14 14:49 ludovic Resolution open => fixed
2011-10-14 14:49 ludovic Fixed in Version => 1.3.9