Is there an existing issue for this?
Current behavior
When updating profile cover image (and/or avatar) via the Profile settings page on a self-hosted instance using the bundled MinIO storage, the PATCH /api/users/me/ request fails with a 400 Bad Request and a misleading error message:
json{"cover_image": ["Enter a valid URL."]}
This happens because the frontend sends cover_image as a relative path returned by the asset upload endpoint (e.g. /api/assets/v2/static//), but the backend serializer validates cover_image as a Django URLField, which requires an absolute URL (e.g. https://...). The relative path fails URL validation.
Despite the error response, the underlying asset upload itself succeeds, and after refreshing the page, the cover image and other profile fields (first name, last name, display name) are correctly persisted. So the practical impact is a misleading error notification, not actual data loss — but it's confusing and makes users think the save failed.
This appears to be a different variant of the previously reported issue #6083 ("Setting Cover Images Fails Without Error") and the fix mentioned in the v1.3.0 changelog ("Fixed persistence of external cover image URLs") — that fix seems to target external URLs (e.g. Unsplash), not relative paths returned by the self-hosted MinIO asset endpoint.
Steps to reproduce
Self-host Plane CE using the standard docker-compose.yml with bundled MinIO (USE_MINIO=1), behind a reverse proxy / tunnel with a public HTTPS domain.
Log in, go to Profile Settings.
Click "Change cover" and upload a new cover image.
Click Save changes.
Observe a red error toast: "There was some error in updating your profile. Please try again."
Open browser DevTools → Network tab → inspect the PATCH https:///api/users/me/ request.
Status: 400 Bad Request
Request payload includes: "cover_image": "/api/assets/v2/static//"
Response body: {"cover_image": ["Enter a valid URL."]}
Refresh the page — the cover image and other submitted fields (first name, last name, display name) are actually saved correctly, despite the error shown in step 5.
=========
Expected Behavior
The profile update should succeed without showing an error, since the operation actually completes successfully.
Either:
The backend should accept relative asset paths for cover_image (consistent with how avatar_url appears to be handled), or
The frontend should send a fully-qualified URL (including the instance's public domain) instead of a relative path.
Environment
Production
Browser
Google Chrome
Variant
Self-hosted
Version
v1.3.1 (self-hosted, Community Edition)
Is there an existing issue for this?
Current behavior
When updating profile cover image (and/or avatar) via the Profile settings page on a self-hosted instance using the bundled MinIO storage, the PATCH /api/users/me/ request fails with a 400 Bad Request and a misleading error message:
json{"cover_image": ["Enter a valid URL."]}
This happens because the frontend sends cover_image as a relative path returned by the asset upload endpoint (e.g. /api/assets/v2/static//), but the backend serializer validates cover_image as a Django URLField, which requires an absolute URL (e.g. https://...). The relative path fails URL validation.
Despite the error response, the underlying asset upload itself succeeds, and after refreshing the page, the cover image and other profile fields (first name, last name, display name) are correctly persisted. So the practical impact is a misleading error notification, not actual data loss — but it's confusing and makes users think the save failed.
This appears to be a different variant of the previously reported issue #6083 ("Setting Cover Images Fails Without Error") and the fix mentioned in the v1.3.0 changelog ("Fixed persistence of external cover image URLs") — that fix seems to target external URLs (e.g. Unsplash), not relative paths returned by the self-hosted MinIO asset endpoint.
Steps to reproduce
Self-host Plane CE using the standard docker-compose.yml with bundled MinIO (USE_MINIO=1), behind a reverse proxy / tunnel with a public HTTPS domain.
Log in, go to Profile Settings.
Click "Change cover" and upload a new cover image.
Click Save changes.
Observe a red error toast: "There was some error in updating your profile. Please try again."
Open browser DevTools → Network tab → inspect the PATCH https:///api/users/me/ request.
Status: 400 Bad Request
Request payload includes: "cover_image": "/api/assets/v2/static//"
Response body: {"cover_image": ["Enter a valid URL."]}
Refresh the page — the cover image and other submitted fields (first name, last name, display name) are actually saved correctly, despite the error shown in step 5.
=========
Expected Behavior
The profile update should succeed without showing an error, since the operation actually completes successfully.
Either:
The backend should accept relative asset paths for cover_image (consistent with how avatar_url appears to be handled), or
The frontend should send a fully-qualified URL (including the instance's public domain) instead of a relative path.
Environment
Production
Browser
Google Chrome
Variant
Self-hosted
Version
v1.3.1 (self-hosted, Community Edition)