By expanding roles from the given ACL to have these values as flags
inside the OpenChange library. This only applies to Calendar and
Tasks folders which stored four different access rights to three
different types of events/tasks.
As the events and tasks are stored in the same table, I have added
two new classes to manage permissions in the same way and this
avoids the code duplication called MAPIStoreCalTask(Folder|Message).
Instead of treating all the message either as alternative or mixed with
this changeset the MIME type of the parent part is used.
This allows a correct disposition of the message in the cases when
nested multiparts elements are used.
Also in mixed parts we convert between plain text and HTML as needed.
If we have multiple parts with different encodings we recode
all HTML parts to UTF-8 and we use it as message charset.
This is neccesary because Outlook assummessa single charset
for all the message.
Also we convert the end of line in text/plain to <br/> tag
when showing them as HTML in multipart/mixed parts.
It was using MAPIStoreDBFolder class instead of specialised version
MAPIStoreNotesFolder and thus the shared subfolders where set to create
messages as normal messages instead of notes.
By storing these custom MAPI roles in the ACL. Take into account that
a task folder is shared with a calendar folder with the same name, therefore
permissions are shared and overwritten from different Outlook sections.
The extension 'X-SOGO-COMPONENT-CREATED-BY' is used to store the task
creator in both Outlook and SOGo Webmail.
The PidLidTaskOwner is not yet properly managed and we are always returning
the folder owner but to effects of sharing that extension is used by now
which matches a little more with what the user expects until we fix
the task ownership defined in [MS-OXOTASK].
By storing these custom MAPI roles in the ACL.
An extension field called 'X-OPENCHANGE-CREATOR' is created in the vcard
to validate the creator/owner of the contact in the shared folder.
By storing these custom MAPI roles in the ACL.
The extension field 'X-SOGO-COMPONENT-CREATED-BY' is used to store the
event creator when it is done from Outlook. It is the same field SOGo
uses when an event is created from a shared folder in the webmail.
The creator and the organizer/owner of the event can be different and it can
be used from external sources by checking the organizer field. This matches
the specification from [MS-OXOCAL] Section 1.1 which defines the organizer
as the owner or creator of the event.
And returning back PidTagCreatorName.
This is done by checking the owner of the resource if the given
permission is restricted to edit/delete own items.
This requires a52bc3b to work in calendar folders as it requires to store and retrieve
the MAPI custom permissions in the ACL.
This is a security issue that allowed a user to read the number
of messages and its subjects when it does not have any permission to read.
Now the user cannot see other's folder without asking for me to the owner.
Instead of asking general container. This gives the possibility to
perform the deletion depending on the data from the message, for instance,
the user creator.
As specified by [MS-OXCPERM] Section 3.2.5.2, the ModifyPermissions ROP
is only possible to users which have this right.
After this changeset, we check the active user can modify permission
list. This is a security fix.
Instead of using the connected active user.
Although this provides no changes in the result, it could be depending
on changes from the backend so it'd better have it accurated to what
the OpenChange DB API offers.
Instead of using connected active user because the fmids are related
to the root folder (context) owner. This avoids returning back incorrect
identifiers which mostly collide with already associated URLs.
This specifies a little the scope of the variable to make it
more realistic with the actual values it may have. We do have
a static typed compiled language, why don't we use it?
Instead of keeping only the highest access roles. This reverts
2c678101 to fix handling of ACLs with multiple groups.
This is done because OpenChange library stores other roles/permissions
in the ACLs that have limited scope to the MAPI protocol and it
maintains an homogeneous returned data with other folders by returning
the actual data is stored in the DB.
By sorting the roles, we give the ability to callers to validate
permissions more efficiency (less loops) and keep the right highest
access level. As an example, check
[SOGoApppointmentFolder:roleForComponentsWithAccessClass:forUser]
for details.
Using LDAP as source, the group entry must have a valid
group objectClass such as posixGroup or group and have a
valid UIDField which does not include the domain.
With this changeset, SOGo is aware of these groups when it has
an email and you can share a component such as a calendar with
the member of the group.
