Skip to content
This repository has been archived by the owner on Mar 10, 2024. It is now read-only.

Moderator data manager capabilities resoloution #391

Open
phillf opened this issue Apr 12, 2021 · 6 comments
Open

Moderator data manager capabilities resoloution #391

phillf opened this issue Apr 12, 2021 · 6 comments
Assignees

Comments

@phillf
Copy link
Contributor

phillf commented Apr 12, 2021

Is your feature request related to a problem? Please describe.
Currently for each datum type available for editing via the Data Manager there are constants that control the following for moderators:

  • ACCESS - Provide for the ability to view the given section of the Data Manager but doesn't grant any Write/Modify permissions.
  • EDIT - Allows the editing of pre-existing entries in the database.
  • DELETE - Allows the deletion of pre-existing items from the database.

Describe the solution you'd like
Should a fourth option be added for CREATE or should it be bundled with EDIT.

Describe alternatives you've considered
There are no alternatives that I am aware of at the time of this posting.


@phillf phillf self-assigned this Apr 12, 2021
@phillf phillf added this to the 1.0.0 milestone Apr 12, 2021
@phillf phillf changed the title Moderator data manager capabilities resoloutiong. Moderator data manager capabilities resoloution Apr 12, 2021
@devotedsouls
Copy link
Contributor

Fourth option should be created, separate from EDIT.

@phillf
Copy link
Contributor Author

phillf commented Apr 12, 2021

If the decision is taken to breakout the CREATE permission specifically then it will come as part of a 1.0.1 patch. There is more to this than just adding a set of constants in oc-config.php. The installer also has to be updated to handle the new options.

@ItsAGeekThing
Copy link
Member

I think "CREATE" should be implemented separately and not bundled with the "EDIT" permission. Just because a community gives an individual the ability to edit via the Data Manager doesn't necessarily imply they want them to be able to create new entries.

That being said, we should push this to the 1.1.0 milestone.

@phillf
Copy link
Contributor Author

phillf commented Apr 12, 2021

@ItsAGeekThing, why 1.1.0 if that is indeed the case at this endeavour. Why not 1.0.1 as I suggested? Am I misunderstanding the SemVer spec?

@phillf phillf removed this from the 1.0.0 milestone Apr 12, 2021
@Cambridgeport90
Copy link
Contributor

I have to agree with @ItsAGeekThing on this one. Editors and folks who can create new entries shouldn't always be the same people. I think that how large the community can definitely play a roll in this,but the larger the community, the more separated out the rolls should be, for you don't want too few being able to do too much.

@ItsAGeekThing
Copy link
Member

ItsAGeekThing commented Apr 12, 2021

@ItsAGeekThing, why 1.1.0 if that is indeed the case at this endeavour. Why not 1.0.1 as I suggested? Am I misunderstanding the SemVer spec?

@phillf

The patch version Z (x.y.Z) should only be incremented for bug fixes.

The minor version Y (x.Y.z) should only be incremented for new (backwards compatible) functionality.

Adding a new permission would be adding new functionality and in turn would warrant incrementing Y and not Z.

https://semver.org/#spec-item-6
https://semver.org/#spec-item-7

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants