Finer grained access controls on ts delete
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 28
- Forks
- 25
- Avg merge
- 4d 22h
- Merged PRs (30d)
- 20
Description
#267 exposed these as separate delete methods: delete_all, delete_data, delete_key. Delete_All is the default
This issue is to address/resolve this comment from @adamkorynta :
"There was a discussion about having different store rules be gated behind user permissions (DELETE_INSERT specifically). Should that same set of permissions get applied for the types of deletion?"
I'm not aware of the full set of user permissions that are available. If we have finer grained controls we could use them.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing issue #267 and the existing delete_all, delete_data, and delete_key methods, then identify the available user permissions and how DELETE_INSERT is applied. Done means agreeing on finer-grained permissions for each deletion type and implementing them consistently, but the issue does not name files or tests to run.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- authorization, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100