 |
I would like just to clarify this issue so to be more obvious for other users. This issue explains behavior only when you configure SOGoEnablePublicAccess in your sogo config. So, if if you enable SOGo public access with SOGoEnablePublicAccess config item, it should be up to users to select if they really want to share their calendars publicly (for anonymous users) or not. In any case, such anonymous access should have entry in ACL. Bottom line is that SOGoEnablePublicAccess should only give possibility that some (e.g Public and/or Confidential and/or Private) events from user's calendar could be accessible for anonymous users. But, by default, for anonymous access following should be in place "SOGoCalendarDefaultRoles=None". For the time being, it would be good if SOGo team puts "Anonymous access" ACL entry in case SOGoEnablePublicAccess is configured in sogo config. In this way, it will prevent accidental publishing of users calendars in case SOGo admin accidentally (?) adds SOGoEnablePublicAccess. Personally, I am not using SOGoEnablePublicAccess, but since there is such option, lets see how we can improve it. |
 |
Here's what we suggest. When you enable SOGoEnablePublicAccess, it won't inherit the SOGoCalendarDefaultRoles for "public accesses". The default role will be "None" unless the user has specified otherwise. |
|
|
We won't introduce yet an other configuration parameter, there's already too many in SOGo! |
|
|
It sounds good for me. Please consider still this possibility - to use the same configuration parameter SOGoCalendarDefaultRoles and to implement new strings for PublicAccess. It would be understandable for all and it gives good sense - users can set their own rules for Authenticated Users and for Public Access, and administrator can set default rules for Authenticated Users and for Public Access. |
|
|
Fix pushed and doc updated: https://github.com/inverse-inc/sogo/commit/2370ecb089e9824eeb55a8e92a6007bd0219e034 |
- Anonymous
