Apply rules upon item creation via other tools like QuickStatements

[mzeinstra]

Currently Automated Values does not run when you create an item via quickstatements, meaning that you have to create and item with all it statements, and than touch the item again (e.g. by making a change or adding a statement) before automated values kicks in.

[JeroenDeDauw]

I do not see a reason why the rules would not be applied on edits via QuickStatements. The rules get applied on a pretty deep level in the code. The only thing that might bypass those rules is doing an XML import into the wiki. Tools like QuickStatements use the web API, and should be hitting the Wikibase hooks that we use.

TL;DR: this looks invalid to me, could you double-check? Perhaps there is another reason why a rule is not being applied.

[JeroenDeDauw]

Relevant bit of code: https://github.com/ProfessionalWiki/AutomatedValues/blob/master/src/Hooks.php#L18-L33

[mzeinstra]

The use case I have is:

A user that is not allowed to edit labels can not use the CSV import functionality of QS, they get the error that creating labels is not allowed. However when they create the item without the label, automated value only kicks in after a secondary edit of the item.

[JeroenDeDauw]

So this user is allowed to create items but not allowed to edit item labels?

That would explain why the labels are not changed. Automated Values "intercepts" the edit and adds labels to it. MediaWiki then rejects that part of the edit. At least, that is my guess of what is happening. Slightly surprising that the labels are being dropped silently; I'd have expected the whole edit to be rejected.

What can we do about this? No obvious solution immediately comes to mind.

We could work around the permission checks, but not in a selective manner, so this would basically break the permission system and allow people to do things they should not be able to do.

[JeroenDeDauw]

Being able to create items without being able to edit their labels is a bit weird :)

[mzeinstra]

Well that is why we use Automated Values to stop 'regular editors' from changing the labels of an item.

[JeroenDeDauw]

Dumping some thoughts:

Possible approach A:

• We check if the incoming edit is allowed for the $user and only continue if it is
• The rules get applied
• Assuming the rule application changed the edit, we save the edit with an admin user. This will be bad for the edit history, tracking user contributions, notifications etc. Maybe it is possible to still save as the $user by somehow bypassing the permission checks or temporarily elevating their permissions.

Possible approach B:

• Incoming edit is made by $user
• Rules are applied
• If there are changes they are stored in a second edit. If the $user is not allowed to make that edit, it is made by an admin user.

[JeroenDeDauw]

Approach A does not appear to be possible. At least not without significant changes to how the extension hooks into MediaWiki, and even then, it might not be possible.

Approach B comes with a good amount of downsides.

@mzeinstra why not simply grant these users the ability to edit labels? If you have rules for the labels anyway, the labels will always follow those rules.

[mzeinstra]

Providing permissions to edit labels might likely confuse the user and provide interactions that they do expect.

For example, they see a label that they disagree with and they change it. However the change is immediately reversed, since automated values overrides the labels upon safe. The user might see this as a bug, and not a feature :) We wanted remove that edit functionality for most users, since they would need to change the underlying claims in order to change the label.

[JeroenDeDauw]

In that case, the simplest solution is not to restrict label editing for these users but to hide the editing UI elements. We already talked about such an approach and it is tracked by #5