Page MenuHomePhabricator

Restrict making content (non-label/alias) changes to system-provided ZObjects to users with a special right
Closed, ResolvedPublic


(Kinda optional, can be bumped to a later phase)

Ensure that certain things cannot be changed through editing. These, in particular, include the core types and their keys.

Z1/ZObject of type Z4/Type and with one key Z1K1/type pointing to a Z4/Type.

Z2/PersistentObject of type Z4/Type with the following keys, and nothing else:

  • Z2K1/ID, pointing to a Z6/String
  • Z2K2/value, pointing to an anything
  • Z2K3/label (with the type we use for labels)

The same for String (with one key for value), Reference (with one key for the referenced ID), and List (with a key for Head and Tail).

We will add more hardcoded conditions as we move on, although we hope that we can keep them minimal.

Related Objects

Event Timeline

DVrandecic triaged this task as Medium priority.Aug 13 2020, 1:13 AM
DVrandecic updated the task description. (Show Details)

Change 619281 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/WikiLambda@master] [WIP] Show a header on each ZPersistentObject page

This really shouldn't be in Phase α because most of the things that are inalienable here are the types and their keys. Without actually having those, we cannot ensure the hardcodedness. So moving this back to Phase β.

Change 619281 merged by jenkins-bot:
[mediawiki/extensions/WikiLambda@master] Show a header on each ZPersistentObject page

Other hardcoded truths are the following basic types and their structure:

  • Z1/Object
  • Z2/Persistent object
  • Z3/Key
  • Z4/Type
  • Z5/Error
  • Z6/String
  • Z7/Function call
  • Z8/Function
  • Z9/Reference
  • Z10/List
  • Z11/Monolingual text
  • Z12/Multilingual text
  • Z14/Implementation

More may be added.

What it means to be hardcoded: if there is anything in the Wiki about these types, i.e. if there is a page Z2, then it can only be a type that has the keys as specified for Z2 according to the specification. The types of these keys cannot be changed, no new keys may be added, no keys may be removed. There do not *have* to be such pages representing these types, but if they exist, they must be consistent with the specification.

The pages are still editable, in particular, documentation, labels, etc. are editable as wished, but the inalienable truths are not.

Ideas and notes from task meeting:

On edit, check certain things against a hardcoded list. E.g. if ZID is in the above list, do the special check that only labels (or doc or aliases) is changeable. This needs to be kept up to date as we evolve.

Walk the tree of before and after to see if it is an allowed change.

Or: Two APIs for editing labels and for editing other things.

This sounds like protection levels? I.e. some things editable by anyone, some only by confirmed users, some only by admins, or other levels. However, you want it granular so that labels can be at a different protection level from other keys. Wikidata has desired something similar, to allow granular protection of some statements while allowing others within the same item to be editable by anyone. Anyway, would using standard Mediawiki protection procedures work for this for now?

DVrandecic raised the priority of this task from Low to Medium.Oct 7 2020, 12:54 AM
AnotherEditor144 raised the priority of this task from Medium to High.Mar 2 2021, 10:43 AM

I am changing the priority to High because not hardcoding them may cause errors.

Aklapper lowered the priority of this task from High to Medium.Mar 2 2021, 1:36 PM
Jdforrester-WMF renamed this task from Hardcode certain inalienable truths to Restrict making content (non-label/alias) changes to system-provided ZObjects to users with a special right.Jan 19 2022, 10:26 PM

Tested and works. Got scared for a moment when testing :D