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.

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

Finer-grained locks #321

Open
cellio opened this issue Nov 29, 2020 · 0 comments
Open

Finer-grained locks #321

cellio opened this issue Nov 29, 2020 · 0 comments
Labels
area: backend Changes to server-side code area: frontend Changes to front-end code complexity: unassessed Needs further developer investigation before complexity/feasibility can be determined. priority: medium type: change request New feature or request

Comments

@cellio
Copy link
Member

cellio commented Nov 29, 2020

The abilities work added locks to the Tools menu. This is good, but it's a little coarser-grained than we intended. Now that the framework is in place, let's adjust these.

Currently you can lock a post entirely (edits, votes, comments), or you can disable comments:

screenshot of menu

Our initial goal (as described in these use cases) was to have two types of locks, edit lock and comment lock. I see no reason to lock a post from voting, and the way to prevent new answers to a question is to close it. We've left open the possibility of other lock types, but we haven't identified any others.

Can we change the "lock" entry here to an edit lock, which, with the next one, together satisfies most of this goal? Both are gated by the Curate ability, with permanent locks being a Moderator ability. (The use cases also specify that a Curator lock should raise an auto-flag for moderators so they know to look at it; if that's hard to do here we can defer it.)

@cellio cellio added area: backend Changes to server-side code area: frontend Changes to front-end code type: change request New feature or request priority: medium complexity: unassessed Needs further developer investigation before complexity/feasibility can be determined. labels Nov 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: backend Changes to server-side code area: frontend Changes to front-end code complexity: unassessed Needs further developer investigation before complexity/feasibility can be determined. priority: medium type: change request New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant