SOGo webmail permissions
Inspired by Simon Willison, I have decided to sometimes post in more targeted ways to try and reflect quick, useful things I have picked up.
This post is about how to manage the permissions of a calendar within a SOGo installation when you can’t directly access the resource from a web interface. SOGo is the default webmail interface on Mailcow, a popular docker-based self-hosted email solution.
The situation of not being able to access the resource is commonplace for non-mailbox resources created in Mailcow (e.g. a meeting room type resource).
Mailcow Access
If using Mailcow, you will need to enter the docker image first and get a command prompt there:
docker exec -it -u sogo mailcowdockerized-sogo-mailcow-1 bash
Interrogating
Once in a position to run the command, you can interrogate existing permissions:
sogo-tool manage-acl get Resource-name@example.com Calendar/personal ALL
Calendar/personal is the default calendar, so this will be correct unless you have created other calendars under this resource (beyond the scope of this TIL).
Adding permissions
There are a range of permissions to add, made up from a combination between the following two sets:
(Public, Confidential and Private) and (DandTViewer and Viewer). For example, PublicDandTViewer allows only the blocks of availability to be seen by a user for Public events; ConfidentialViewer allows the user to view all details of a Confidential event.
Once you have decided on what to apply for a user (provided in the command below as me@example.com), the command uses the following format:
sogo-tool manage-acl add Resource@example.com Calendar/personal me@example.com '["PublicViewer", "ConfidentialDandTViewer"]'
Anonymous users:
sogo-tool manage-acl add Resource@example.com Calendar/personal anonymous '["PublicDandTViewer"]'
Defaults:
The documentation allows the specification ALL and <default> in place of the user field; I am not currently sure of the difference and determining this is left as an excercise for the reader.