mirror of
https://github.com/mediacms-io/mediacms.git
synced 2025-11-21 22:07:59 -05:00
feat: bulk actions API
This commit is contained in:
@@ -168,8 +168,6 @@ By default, all these services are enabled, but in order to create a scaleable d
|
||||
|
||||
Also see the `Dockerfile` for other environment variables which you may wish to override. Application settings, eg. `FRONTEND_HOST` can also be overridden by updating the `deploy/docker/local_settings.py` file.
|
||||
|
||||
See example deployments in the sections below. These example deployments have been tested on `docker-compose version 1.27.4` running on `Docker version 19.03.13`
|
||||
|
||||
To run, update the configs above if necessary, build the image by running `docker compose build`, then run `docker compose run`
|
||||
|
||||
### Simple Deployment, accessed as http://localhost
|
||||
@@ -502,6 +500,16 @@ By default `CAN_COMMENT = "all"` means that all registered users can add comment
|
||||
|
||||
- **advancedUser**, only users that are marked as advanced users can add comment. Admins or MediaCMS managers can make users advanced users by editing their profile and selecting advancedUser.
|
||||
|
||||
### 5.26 Control whether anonymous users can list all users
|
||||
|
||||
By default, anonymous users can view the list of all users on the platform. To restrict this to authenticated users only, set:
|
||||
|
||||
```
|
||||
ALLOW_ANONYMOUS_USER_LISTING = False
|
||||
```
|
||||
|
||||
When set to False, only logged-in users will be able to access the user listing API endpoint.
|
||||
|
||||
|
||||
## 6. Manage pages
|
||||
to be written
|
||||
@@ -967,4 +975,4 @@ Visiting the admin, you will see the Identity Providers tab and you can add one.
|
||||
|
||||
## 25. Custom urls
|
||||
To enable custom urls, set `ALLOW_CUSTOM_MEDIA_URLS = True` on settings.py or local_settings.py
|
||||
This will enable editing the URL of the media, while editing a media. If the URL is already taken you get a message you cannot update this.
|
||||
This will enable editing the URL of the media, while editing a media. If the URL is already taken you get a message you cannot update this.
|
||||
|
||||
@@ -4,10 +4,10 @@ There is ongoing effort to provide a better developer experience and document it
|
||||
## How to develop locally with Docker
|
||||
First install a recent version of [Docker](https://docs.docker.com/get-docker/), and [Docker Compose](https://docs.docker.com/compose/install/).
|
||||
|
||||
Then run `docker-compose -f docker-compose-dev.yaml up`
|
||||
Then run `docker compose -f docker-compose-dev.yaml up`
|
||||
|
||||
```
|
||||
user@user:~/mediacms$ docker-compose -f docker-compose-dev.yaml up
|
||||
user@user:~/mediacms$ docker compose -f docker-compose-dev.yaml up
|
||||
```
|
||||
|
||||
In a few minutes the app will be available at http://localhost . Login via admin/admin
|
||||
@@ -37,7 +37,7 @@ Django starts at http://localhost and is reloading automatically. Making any cha
|
||||
If Django breaks due to an error (eg SyntaxError, while editing the code), you might have to restart it
|
||||
|
||||
```
|
||||
docker-compose -f docker-compose-dev.yaml restart web
|
||||
docker compose -f docker-compose-dev.yaml restart web
|
||||
```
|
||||
|
||||
|
||||
@@ -62,9 +62,9 @@ In order to make changes to React code, edit code on frontend/src and check it's
|
||||
### Development workflow with the frontend
|
||||
1. Edit frontend/src/ files
|
||||
2. Check changes on http://localhost:8088/
|
||||
3. Build frontend with `docker-compose -f docker-compose-dev.yaml exec frontend npm run dist`
|
||||
3. Build frontend with `docker compose -f docker-compose-dev.yaml exec frontend npm run dist`
|
||||
4. Copy static files to Django static folder with`cp -r frontend/dist/static/* static/`
|
||||
5. Restart Django - `docker-compose -f docker-compose-dev.yaml restart web` so that it uses the new static files
|
||||
5. Restart Django - `docker compose -f docker-compose-dev.yaml restart web` so that it uses the new static files
|
||||
6. Commit the changes
|
||||
|
||||
### Helper commands
|
||||
@@ -81,7 +81,7 @@ Build the frontend:
|
||||
|
||||
```
|
||||
user@user:~/mediacms$ make build-frontend
|
||||
docker-compose -f docker-compose-dev.yaml exec frontend npm run dist
|
||||
docker compose -f docker-compose-dev.yaml exec frontend npm run dist
|
||||
|
||||
> mediacms-frontend@0.9.1 dist /home/mediacms.io/mediacms/frontend
|
||||
> mediacms-scripts rimraf ./dist && mediacms-scripts build --config=./config/mediacms.config.js --env=dist
|
||||
|
||||
@@ -17,7 +17,7 @@ to be written
|
||||
|
||||
## 3. API documentation
|
||||
API is documented using Swagger - checkout ot http://your_installation/swagger - example https://demo.mediacms.io/swagger/
|
||||
This page allows you to login to perform authenticated actions - it will also use your session if logged in.
|
||||
This page allows you to login to perform authenticated actions - it will also use your session if logged in.
|
||||
|
||||
|
||||
An example of working with Python requests library:
|
||||
@@ -50,8 +50,8 @@ Checkout the [Code of conduct page](../CODE_OF_CONDUCT.md) if you want to contri
|
||||
To perform the Docker installation, follow instructions to install Docker + Docker compose (docs/Docker_Compose.md) and then build/start docker-compose-dev.yaml . This will run the frontend application on port 8088 on top of all other containers (including the Django web application on port 80)
|
||||
|
||||
```
|
||||
docker-compose -f docker-compose-dev.yaml build
|
||||
docker-compose -f docker-compose-dev.yaml up
|
||||
docker compose -f docker-compose-dev.yaml build
|
||||
docker compose -f docker-compose-dev.yaml up
|
||||
```
|
||||
|
||||
An `admin` user is created during the installation process. Its attributes are defined in `docker-compose-dev.yaml`:
|
||||
@@ -65,16 +65,16 @@ ADMIN_EMAIL: 'admin@localhost'
|
||||
Eg change `frontend/src/static/js/pages/HomePage.tsx` , dev application refreshes in a number of seconds (hot reloading) and I see the changes, once I'm happy I can run
|
||||
|
||||
```
|
||||
docker-compose -f docker-compose-dev.yaml exec -T frontend npm run dist
|
||||
docker compose -f docker-compose-dev.yaml exec -T frontend npm run dist
|
||||
```
|
||||
|
||||
And then in order for the changes to be visible on the application while served through nginx,
|
||||
And then in order for the changes to be visible on the application while served through nginx,
|
||||
|
||||
```
|
||||
cp -r frontend/dist/static/* static/
|
||||
```
|
||||
|
||||
POST calls: cannot be performed through the dev server, you have to make through the normal application (port 80) and then see changes on the dev application on port 8088.
|
||||
POST calls: cannot be performed through the dev server, you have to make through the normal application (port 80) and then see changes on the dev application on port 8088.
|
||||
Make sure the urls are set on `frontend/.env` if different than localhost
|
||||
|
||||
|
||||
@@ -90,7 +90,7 @@ http://localhost:8088/manage-media.html manage_media
|
||||
After I make changes to the django application (eg make a change on `files/forms.py`) in order to see the changes I have to restart the web container
|
||||
|
||||
```
|
||||
docker-compose -f docker-compose-dev.yaml restart web
|
||||
docker compose -f docker-compose-dev.yaml restart web
|
||||
```
|
||||
|
||||
## How video is transcoded
|
||||
@@ -113,7 +113,7 @@ there is also an experimental small service (not commited to the repo currently)
|
||||
|
||||
When the Encode object is marked as success and chunk=False, and thus is available for download/stream, there is a task that gets started and saves an HLS version of the file (1 mp4-->x number of small .ts chunks). This would be FILES_C
|
||||
|
||||
This mechanism allows for workers that have access on the same filesystem (either localhost, or through a shared network filesystem, eg NFS/EFS) to work on the same time and produce results.
|
||||
This mechanism allows for workers that have access on the same filesystem (either localhost, or through a shared network filesystem, eg NFS/EFS) to work on the same time and produce results.
|
||||
|
||||
## 6. Working with the automated tests
|
||||
|
||||
@@ -122,19 +122,19 @@ This instructions assume that you're using the docker installation
|
||||
1. start docker-compose
|
||||
|
||||
```
|
||||
docker-compose up
|
||||
docker compose up
|
||||
```
|
||||
|
||||
2. Install the requirements on `requirements-dev.txt ` on web container (we'll use the web container for this)
|
||||
|
||||
```
|
||||
docker-compose exec -T web pip install -r requirements-dev.txt
|
||||
docker compose exec -T web pip install -r requirements-dev.txt
|
||||
```
|
||||
|
||||
3. Now you can run the existing tests
|
||||
|
||||
```
|
||||
docker-compose exec --env TESTING=True -T web pytest
|
||||
docker compose exec --env TESTING=True -T web pytest
|
||||
```
|
||||
|
||||
The `TESTING=True` is passed for Django to be aware this is a testing environment (so that it runs Celery tasks as functions for example and not as background tasks, since Celery is not started in the case of pytest)
|
||||
@@ -143,13 +143,13 @@ The `TESTING=True` is passed for Django to be aware this is a testing environmen
|
||||
4. You may try a single test, by specifying the path, for example
|
||||
|
||||
```
|
||||
docker-compose exec --env TESTING=True -T web pytest tests/test_fixtures.py
|
||||
docker compose exec --env TESTING=True -T web pytest tests/test_fixtures.py
|
||||
```
|
||||
|
||||
5. You can also see the coverage
|
||||
|
||||
```
|
||||
docker-compose exec --env TESTING=True -T web pytest --cov=. --cov-report=html
|
||||
docker compose exec --env TESTING=True -T web pytest --cov=. --cov-report=html
|
||||
```
|
||||
|
||||
and of course...you are very welcome to help us increase it ;)
|
||||
|
||||
166
docs/media_permissions.md
Normal file
166
docs/media_permissions.md
Normal file
@@ -0,0 +1,166 @@
|
||||
# Media Permissions in MediaCMS
|
||||
|
||||
This document explains the permission system in MediaCMS, which controls who can view, edit, and manage media files.
|
||||
|
||||
## Overview
|
||||
|
||||
MediaCMS provides a flexible permission system that allows fine-grained control over media access. The system supports:
|
||||
|
||||
1. **Basic permissions** - Public, private, and unlisted media
|
||||
2. **User-specific permissions** - Direct permissions granted to specific users
|
||||
3. **Role-Based Access Control (RBAC)** - Category-based permissions through group membership
|
||||
|
||||
## Media States
|
||||
|
||||
Every media file has a state that determines its basic visibility:
|
||||
|
||||
- **Public** - Visible to everyone
|
||||
- **Private** - Only visible to the owner and users with explicit permissions
|
||||
- **Unlisted** - Not listed in public listings but accessible via direct link
|
||||
|
||||
|
||||
## User Roles
|
||||
|
||||
MediaCMS has several user roles that affect permissions:
|
||||
|
||||
- **Regular User** - Can upload and manage their own media
|
||||
- **Advanced User** - Additional capabilities (configurable)
|
||||
- **MediaCMS Editor** - Can edit and review content across the platform
|
||||
- **MediaCMS Manager** - Full management capabilities
|
||||
- **Admin** - Complete system access
|
||||
|
||||
## Direct Media Permissions
|
||||
|
||||
The `MediaPermission` model allows granting specific permissions to individual users:
|
||||
|
||||
### Permission Levels
|
||||
|
||||
- **Viewer** - Can view the media even if it's private
|
||||
- **Editor** - Can view and edit the media's metadata
|
||||
- **Owner** - Full control, including deletion
|
||||
|
||||
## Role-Based Access Control (RBAC)
|
||||
|
||||
When RBAC is enabled (`USE_RBAC` setting), permissions can be managed through categories and groups:
|
||||
|
||||
1. Categories can be marked as RBAC-controlled
|
||||
2. Users are assigned to RBAC groups with specific roles
|
||||
3. RBAC groups are associated with categories
|
||||
4. Users inherit permissions to media in those categories based on their role
|
||||
|
||||
### RBAC Roles
|
||||
|
||||
- **Member** - Can view media in the category
|
||||
- **Contributor** - Can view and edit media in the category
|
||||
- **Manager** - Full control over media in the category
|
||||
|
||||
## Permission Checking Methods
|
||||
|
||||
The User model provides several methods to check permissions:
|
||||
|
||||
```python
|
||||
# From users/models.py
|
||||
def has_member_access_to_media(self, media):
|
||||
# Check if user can view the media
|
||||
# ...
|
||||
|
||||
def has_contributor_access_to_media(self, media):
|
||||
# Check if user can edit the media
|
||||
# ...
|
||||
|
||||
def has_owner_access_to_media(self, media):
|
||||
# Check if user has full control over the media
|
||||
# ...
|
||||
```
|
||||
|
||||
## How Permissions Are Applied
|
||||
|
||||
When a user attempts to access media, the system checks permissions in this order:
|
||||
|
||||
1. Is the media public? If yes, allow access.
|
||||
2. Is the user the owner of the media? If yes, allow full access.
|
||||
3. Does the user have direct permissions through MediaPermission? If yes, grant the corresponding access level.
|
||||
4. If RBAC is enabled, does the user have access through category membership? If yes, grant the corresponding access level.
|
||||
5. If none of the above, deny access.
|
||||
|
||||
## Media Sharing
|
||||
|
||||
Users can share media with others by:
|
||||
|
||||
1. Making it public or unlisted
|
||||
2. Granting direct permissions to specific users
|
||||
3. Adding it to a category that's accessible to an RBAC group
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Media Listing
|
||||
|
||||
When listing media, the system filters based on permissions:
|
||||
|
||||
```python
|
||||
# Simplified example from files/views/media.py
|
||||
def _get_media_queryset(self, request, user=None):
|
||||
# 1. Public media
|
||||
listable_media = Media.objects.filter(listable=True)
|
||||
|
||||
if not request.user.is_authenticated:
|
||||
return listable_media
|
||||
|
||||
# 2. User permissions for authenticated users
|
||||
user_media = Media.objects.filter(permissions__user=request.user)
|
||||
|
||||
# 3. RBAC for authenticated users
|
||||
if getattr(settings, 'USE_RBAC', False):
|
||||
rbac_categories = request.user.get_rbac_categories_as_member()
|
||||
rbac_media = Media.objects.filter(category__in=rbac_categories)
|
||||
|
||||
# Combine all accessible media
|
||||
return listable_media.union(user_media, rbac_media)
|
||||
```
|
||||
|
||||
### Permission Checking
|
||||
|
||||
The system uses helper methods to check permissions:
|
||||
|
||||
```python
|
||||
# From users/models.py
|
||||
def has_member_access_to_media(self, media):
|
||||
# First check if user is the owner
|
||||
if media.user == self:
|
||||
return True
|
||||
|
||||
# Then check RBAC permissions
|
||||
if getattr(settings, 'USE_RBAC', False):
|
||||
rbac_groups = RBACGroup.objects.filter(
|
||||
memberships__user=self,
|
||||
memberships__role__in=["member", "contributor", "manager"],
|
||||
categories__in=media.category.all()
|
||||
).distinct()
|
||||
if rbac_groups.exists():
|
||||
return True
|
||||
|
||||
# Then check MediaShare permissions for any access
|
||||
media_permission_exists = MediaPermission.objects.filter(
|
||||
user=self,
|
||||
media=media,
|
||||
).exists()
|
||||
|
||||
return media_permission_exists
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Default to Private** - Consider setting new uploads to private by default
|
||||
2. **Use Categories** - Organize media into categories for easier permission management
|
||||
3. **RBAC for Teams** - Use RBAC for team collaboration scenarios
|
||||
4. **Direct Permissions for Exceptions** - Use direct permissions for one-off sharing
|
||||
|
||||
## Configuration
|
||||
|
||||
The permission system can be configured through several settings:
|
||||
|
||||
- `USE_RBAC` - Enable/disable Role-Based Access Control
|
||||
|
||||
## Conclusion
|
||||
|
||||
MediaCMS provides a flexible and powerful permission system that can accommodate various use cases, from simple personal media libraries to complex team collaboration scenarios with fine-grained access control.
|
||||
Reference in New Issue
Block a user