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

Support for "Is edit protected", refs 2227 #2232

Merged
merged 1 commit into from Feb 4, 2017

Conversation

Projects
None yet
2 participants
@mwjames
Contributor

mwjames commented Feb 4, 2017

This PR is made in reference to: #2227

This PR addresses or contains:

  • Adds Is edit protected as an administrative property to restrict edit access to an annotated entity (page) to avoid accidental data modification

This PR includes:

  • Tests (unit/integration)
  • CI build passed

@mwjames mwjames added the feature label Feb 4, 2017

@mwjames mwjames added this to the SMW 2.5.0 milestone Feb 4, 2017

@mwjames

This comment has been minimized.

Show comment
Hide comment
@mwjames

mwjames Feb 4, 2017

Contributor

For sometime now, I was locking for a smart (== none intrusive, yet powerful) way to prevent users from accidental changing data or property specifications, especially when you have authority data some kind of check and balance should hinder a change to a specification to avoid altered types or worse have those changes flood the job queue and invalidate depending data sets.

With #2227 (PropertySpecificationReqExaminer, PropertyPageMessageHtmlBuilder), I was able to add a feature to 2.5 that is small in terms of LOC but does what is required to hinder accidental data modifications.

Workflow

The workflow as very simple, "... any user is qualified to add the Is edit protected property to a subject, yet only a user with a dedicated permission can edit or revoke the protection to an entity after it has been added ..."

A user without an appropriate right (which is maintained in smwgEditProtectionRight) will be given a notice and is unable to edit, delete, or move that page.

image

In case smwgEditProtectionRight is disabled (== false), the Is edit protected property page will notify a user about the circumstances.

image

Technical notes

  • Is edit protected is a predefined property
  • smwgEditProtectionRight is added as setting to disable, enable the functionality and provide the name of the right to check against
  • smw-pageedit is deployed as extra right to distinguish it from any other right and is assigned to the smwcurator role by default
  • Lookup and validation of the Is edit protected property is handled by EditProtectionValidator and is optimized to cache a request and minimize any Store/DB connections
  • Only the TitleQuickPermissions hook is used to control and influence on the protection behaviour because "... checked first in the Title::checkQuickPermissions ... are the most basic of permissions needed to perform ..."
Contributor

mwjames commented Feb 4, 2017

For sometime now, I was locking for a smart (== none intrusive, yet powerful) way to prevent users from accidental changing data or property specifications, especially when you have authority data some kind of check and balance should hinder a change to a specification to avoid altered types or worse have those changes flood the job queue and invalidate depending data sets.

With #2227 (PropertySpecificationReqExaminer, PropertyPageMessageHtmlBuilder), I was able to add a feature to 2.5 that is small in terms of LOC but does what is required to hinder accidental data modifications.

Workflow

The workflow as very simple, "... any user is qualified to add the Is edit protected property to a subject, yet only a user with a dedicated permission can edit or revoke the protection to an entity after it has been added ..."

A user without an appropriate right (which is maintained in smwgEditProtectionRight) will be given a notice and is unable to edit, delete, or move that page.

image

In case smwgEditProtectionRight is disabled (== false), the Is edit protected property page will notify a user about the circumstances.

image

Technical notes

  • Is edit protected is a predefined property
  • smwgEditProtectionRight is added as setting to disable, enable the functionality and provide the name of the right to check against
  • smw-pageedit is deployed as extra right to distinguish it from any other right and is assigned to the smwcurator role by default
  • Lookup and validation of the Is edit protected property is handled by EditProtectionValidator and is optimized to cache a request and minimize any Store/DB connections
  • Only the TitleQuickPermissions hook is used to control and influence on the protection behaviour because "... checked first in the Title::checkQuickPermissions ... are the most basic of permissions needed to perform ..."
@mwjames

This comment has been minimized.

Show comment
Hide comment
@mwjames

mwjames Feb 4, 2017

Contributor

@kghbln FYI, Once merged it would be marvelous if you could add $GLOBALS['smwgEditProtectionRight'] = 'smw-pageedit'; to the configuration.

PS: I haven't restricted the functionality to only work on the Property NS which means that any page can be protected using the Is edit protected annotation.

Contributor

mwjames commented Feb 4, 2017

@kghbln FYI, Once merged it would be marvelous if you could add $GLOBALS['smwgEditProtectionRight'] = 'smw-pageedit'; to the configuration.

PS: I haven't restricted the functionality to only work on the Property NS which means that any page can be protected using the Is edit protected annotation.

@mwjames mwjames merged commit 2e4092f into master Feb 4, 2017

2 of 3 checks passed

Scrutinizer Created
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@mwjames mwjames deleted the edit-pro branch Feb 4, 2017

@kghbln

This comment has been minimized.

Show comment
Hide comment
@kghbln

kghbln Feb 5, 2017

Member

I have finally done this. Utmost cool! Especially fixed properties and properties of imported vocabularies are born to be used together with this feature.

Member

kghbln commented Feb 5, 2017

I have finally done this. Utmost cool! Especially fixed properties and properties of imported vocabularies are born to be used together with this feature.

@kghbln

This comment has been minimized.

Show comment
Hide comment
@kghbln

kghbln Feb 5, 2017

Member

Documentation:

  • User groups and right - done
  • Special property - done
  • Configuration parameter - done
Member

kghbln commented Feb 5, 2017

Documentation:

  • User groups and right - done
  • Special property - done
  • Configuration parameter - done
@mwjames

This comment has been minimized.

Show comment
Hide comment
@mwjames

mwjames Feb 5, 2017

Contributor

I have finally done this. Utmost cool!

I'll try to squeeze in a change to have it combined using $wgRestrictionLevels[] = 'smw-pageedit'; [0]:

image

Settings and work done in this PR are a prerequisites but the update on the protect action event to set the Is edit protected property is a bit shaky right now therefore I can't promise that it works from the protect action menu.

[0] https://www.mediawiki.org/wiki/Manual:$wgRestrictionLevels

Contributor

mwjames commented Feb 5, 2017

I have finally done this. Utmost cool!

I'll try to squeeze in a change to have it combined using $wgRestrictionLevels[] = 'smw-pageedit'; [0]:

image

Settings and work done in this PR are a prerequisites but the update on the protect action event to set the Is edit protected property is a bit shaky right now therefore I can't promise that it works from the protect action menu.

[0] https://www.mediawiki.org/wiki/Manual:$wgRestrictionLevels

@kghbln

This comment has been minimized.

Show comment
Hide comment
@kghbln

kghbln Feb 5, 2017

Member

I can very well imagine that this is not quite as trivial. A lot of users will also used this via a semantic form so both approaches should be somehow compatible if possible.

Member

kghbln commented Feb 5, 2017

I can very well imagine that this is not quite as trivial. A lot of users will also used this via a semantic form so both approaches should be somehow compatible if possible.

@mwjames

This comment has been minimized.

Show comment
Hide comment
@mwjames

mwjames Feb 5, 2017

Contributor

Especially fixed properties and properties of imported vocabularies are born to be used together with this feature.

Yes, when I saw changes on the sandbox to same properties, I thought that this sort of thing probably happens fairly frequent and is most likely caused unintentionally, yet creates unfortunate disruptions therefore a solution should be part of SMW-core to hinder such actions.

For this feature to work the "smw-pageedit" user right must be added to the configuration parameter $smwgEditProtectionRight in "LocalSettings.php".

$smwgEditProtectionRight can contain any right, it is just that "smw-pageedit" is provided for convenience to make the intention more distinct. Is edit protected bounds itself to check against what is maintained in $smwgEditProtectionRight which happens in the EditProtectionValidator.

Contributor

mwjames commented Feb 5, 2017

Especially fixed properties and properties of imported vocabularies are born to be used together with this feature.

Yes, when I saw changes on the sandbox to same properties, I thought that this sort of thing probably happens fairly frequent and is most likely caused unintentionally, yet creates unfortunate disruptions therefore a solution should be part of SMW-core to hinder such actions.

For this feature to work the "smw-pageedit" user right must be added to the configuration parameter $smwgEditProtectionRight in "LocalSettings.php".

$smwgEditProtectionRight can contain any right, it is just that "smw-pageedit" is provided for convenience to make the intention more distinct. Is edit protected bounds itself to check against what is maintained in $smwgEditProtectionRight which happens in the EditProtectionValidator.

@mwjames

This comment has been minimized.

Show comment
Hide comment
@mwjames

mwjames Feb 5, 2017

Contributor

A lot of users will also used this via a semantic form so both approaches should be somehow compatible if possible.

I suspect any edit is protected which should include SF as well (I don't have it installed nor have I tested it explicitly).

Contributor

mwjames commented Feb 5, 2017

A lot of users will also used this via a semantic form so both approaches should be somehow compatible if possible.

I suspect any edit is protected which should include SF as well (I don't have it installed nor have I tested it explicitly).

This was referenced Feb 7, 2017

@mwjames mwjames referenced this pull request Feb 11, 2017

Merged

Add `smw-pageedit` to wgRestrictionLevels, refs 2232 #2249

2 of 2 tasks complete
@mwjames

This comment has been minimized.

Show comment
Hide comment
@mwjames

mwjames Feb 11, 2017

Contributor

I'll try to squeeze in a change to have it combined using $wgRestrictionLevels[] = 'smw-pageedit'; [0]:

This ended up to be a bit more challenging than anticipated but #2249 contains the necessary changes.

Documentation:

@kghbln To provide you with some support on the documentation front, I added:

Contributor

mwjames commented Feb 11, 2017

I'll try to squeeze in a change to have it combined using $wgRestrictionLevels[] = 'smw-pageedit'; [0]:

This ended up to be a bit more challenging than anticipated but #2249 contains the necessary changes.

Documentation:

@kghbln To provide you with some support on the documentation front, I added:

@kghbln

This comment has been minimized.

Show comment
Hide comment
@kghbln

kghbln Feb 12, 2017

Member

$smwgEditProtectionRight can contain any right, it is just that "smw-pageedit" is provided for convenience to make the intention more distinct

I wanted to elaborate more on this on the configuration parameter level. Still a mention on this page is not bad either.

This ended up to be a bit more challenging than anticipated but #2249 contains the necessary changes.

Thanks you for being brave and having the required stamina!

To provide you with some support on the documentation front, I added: https://www.semantic-mediawiki.org/wiki/Edit_protection

Great, since this also answers some questions I would have posted here. Just fluffed and tweaked a bit.

Member

kghbln commented Feb 12, 2017

$smwgEditProtectionRight can contain any right, it is just that "smw-pageedit" is provided for convenience to make the intention more distinct

I wanted to elaborate more on this on the configuration parameter level. Still a mention on this page is not bad either.

This ended up to be a bit more challenging than anticipated but #2249 contains the necessary changes.

Thanks you for being brave and having the required stamina!

To provide you with some support on the documentation front, I added: https://www.semantic-mediawiki.org/wiki/Edit_protection

Great, since this also answers some questions I would have posted here. Just fluffed and tweaked a bit.

@kghbln

This comment has been minimized.

Show comment
Hide comment
@kghbln

kghbln Feb 12, 2017

Member

Is it possible to add an array of rights to $smwgEditProtectionRight?

Member

kghbln commented Feb 12, 2017

Is it possible to add an array of rights to $smwgEditProtectionRight?

@mwjames

This comment has been minimized.

Show comment
Hide comment
@mwjames

mwjames Feb 12, 2017

Contributor

Is it possible to add an array of rights to $smwgEditProtectionRight?

That would require some changes. Any particular use case in mind that would require multiple allowed edit rights?

For example, if [[Is edit protected::true]] is set then we force a protection level and in case it is only one the case is simple but when you have multiple which one do you want to enforce? The first one in the array as convention or do you want to add a smwgEditProtectionEnforcedRight setting?

Contributor

mwjames commented Feb 12, 2017

Is it possible to add an array of rights to $smwgEditProtectionRight?

That would require some changes. Any particular use case in mind that would require multiple allowed edit rights?

For example, if [[Is edit protected::true]] is set then we force a protection level and in case it is only one the case is simple but when you have multiple which one do you want to enforce? The first one in the array as convention or do you want to add a smwgEditProtectionEnforcedRight setting?

@mwjames

This comment has been minimized.

Show comment
Hide comment
@mwjames

mwjames Feb 12, 2017

Contributor

Is it possible to add an array of rights to $smwgEditProtectionRight?

I pushed a c88ee7c change that would allow $GLOBALS['smwgEditProtectionRights'] = array( 'smw-pageedit', 'editsemiprotected' ); (PS: mind the name change to the plural form). I haven't really tested it and the question about the enforced right remains open (currently it uses the first right from the array).

Contributor

mwjames commented Feb 12, 2017

Is it possible to add an array of rights to $smwgEditProtectionRight?

I pushed a c88ee7c change that would allow $GLOBALS['smwgEditProtectionRights'] = array( 'smw-pageedit', 'editsemiprotected' ); (PS: mind the name change to the plural form). I haven't really tested it and the question about the enforced right remains open (currently it uses the first right from the array).

@mwjames mwjames referenced this pull request Feb 12, 2017

Closed

Allow multiple edit protection rights, refs 2232, 2249 #2255

1 of 2 tasks complete
@kghbln

This comment has been minimized.

Show comment
Hide comment
@kghbln

kghbln Feb 16, 2017

Member

That would require some changes. Any particular use case in mind that would require multiple allowed edit rights?

Cool. Thank you for going at it. I was primarily asking for the purpose of documentation but I can imagine cases where I would not like a user to be part of the curator group due to the regex editing connected with it. However this person may very well be capable of doing all other edits on protected pages. Multiple rights would allow for more flexibility. However it would alternatively be possible to create an extra group or use an existing one and assign smw-pageedit to it. So allowing multiple rights to be set is not required to allow for flexibility in this case if required. For the sake of simplicity it may probably be better to keep as is ...

Member

kghbln commented Feb 16, 2017

That would require some changes. Any particular use case in mind that would require multiple allowed edit rights?

Cool. Thank you for going at it. I was primarily asking for the purpose of documentation but I can imagine cases where I would not like a user to be part of the curator group due to the regex editing connected with it. However this person may very well be capable of doing all other edits on protected pages. Multiple rights would allow for more flexibility. However it would alternatively be possible to create an extra group or use an existing one and assign smw-pageedit to it. So allowing multiple rights to be set is not required to allow for flexibility in this case if required. For the sake of simplicity it may probably be better to keep as is ...

@mwjames mwjames referenced this pull request Aug 6, 2017

Merged

Add create restriction on properties, refs 2232 #2600

2 of 2 tasks complete

@kghbln kghbln referenced this pull request Sep 25, 2017

Merged

Update en.json #2703

1 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment