Mediafiles - OpenSlides/OpenSlides GitHub Wiki

There are two types of mediafiles: meeting-wide mediafiles and organization-wide mediafiles, determined by the owner_id. They work basically in the same way, but each have some special functionality. If not further specified, the following applies to all mediafiles.

Mediafiles can be used to structure and store files inside a meeting or the organization. Mediafiles are ordered in a tree-like structure, where leafes can be actual files. All inner nodes must be directories. Since files and directories share a lot in common regarding metadata, one single model (mediafile) is used to represent both. Whether a mediafile is a file or directory is determinated by the method of creation (mediafile.create_director and mediafile.upload) and stored in mediafile/is_directory for quick access.

The difference between files and directories is that directories do not have data set for token, filesize, filename, pdf_information, and mimetype. Files can be accessed via the media service. When PDFs are uploaded, metainfo is saved to pdf_information, that is used, when projecting the PDF.

It must be asserted that the tree structure of each owner only contains valid mediafiles: A meeting can only have mediafiles belonging to it in its tree; the organization can only have organization-wide mediafiles in its tree.

Meeting-wide mediafiles cannot have the token field set.

There are access permissions for meeting-wide mediafiles. First note that there are exceptions disabling all access controls see below. Users must have mediafile.can_see to access any mediafile of the meeting. Each mediafile has access_group_ids. A user can access a mediafile if he is at least in one group (or the meeting's admin group). If no groups are set (access_group_ids=[]), the mediafile is accessible by everyone. Since mediafiles are tree-ordered, the access groups from a children also inherit the parent ones. The inherited_access_group_ids is the intersection of the access groups of the mediafile and all parent (grandparent, ...) ones. This results in the situation that [] can have two meanings:

1. Public to everyone
2. Some parent has access groups that have no intersection to the mediafile ones. So nobody (except the meeting's admin) can see the mediafile

In this case (inherited_access_group_ids==[]), is_public decides: If it is true, a user can access the mediafile.

Files (images/fonts) can be used as logos and fonts per meeting, see the used_as_logo_*_in_meeting_id and used_as_font_*_in_meeting_id relations. Valid mimetypes are defined in the client. These relations can only be used for meeting-wide mediafiles.

Organization-wide mediafiles follow the same basic structure, but cannot have [inherited_]access_group_ids and therefore neither is_public set, since there are no organization-wide groups. Instead, they can have a token. If a mediafile has a token, it is accessible by anyone, even users which are not logged in. This feature is necessary to provide dynamic control of the design, e.g. fonts and logos.

Also, all other meeting-specific relations like attachment_ids, used_as_logo_*_in_meeting_id cannot be set for organization-wide mediafiles.

Since organization-wide mediafiles don't have any other way to control permissions and visibility, every logged-in user can see them and no permission checks have to be done.