Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc(permissions): Updated permission change instructions #1295

Merged
merged 2 commits into from
Jun 3, 2022
Merged

doc(permissions): Updated permission change instructions #1295

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6378ec2
doc(permissions): Updated permission change instructions
TheSlimvReal May 27, 2022
ed6f7c3
Merge branch 'master' into permission_doc_update
sleidig Jun 3, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions doc/compodoc_sources/concepts/permissions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -128,12 +128,12 @@ As permissions cannot directly be created and edited from within the app at the
Look for or create the document with `"_id": "Config:Permissions"` and define the permissions as described above.
2. After saving the new permissions document, update the replication backend about the updated permissions:
Visit `https://<your-system-domain>/db/api/` to use the OpenAPI interface for this.
3. There in `Servers` select `/db deployed`
4. Use your CouchDB admin credentials in the `POST /_session` endpoint to get a valid access token.
5. Make a request to the `POST /rules/reload` endpoint. If successful, the response will show the newly fetched rules.
3. There in `Servers` select `/db deployed`.
4. Click on `Authorize` enter valid user credentials and click `Login`.
5. Make a request to the `POST /rules/{db}/reload` endpoint, where `{db}` is the active database, e.g. `app`. If successful, the response will show the newly fetched rules.
6. In case some users might have **gained** access to documents to which they did not have access before,
also trigger the `POST /clear_local` endpoint.
The `/clear_local` endpoint will ensure that each client re-checks whether new objects are available for synchronization.
also trigger the `POST /{db}/clear_local` endpoint, where `{db}` again is the active database.
The `/{db}/clear_local` endpoint will ensure that each client re-checks whether new objects are available for synchronization.
This should also be used in case an existing user has gotten a new, more powerful role.
In case a user lost permissions for objects that were already synced, this users local DB will automatically be destroyed and the user has to synchronize all data again.

Expand Down