A typical use case for the "clear" flag is load-modify-save, in which case most of the entity would be restored as they were. This means that any permissions checks for parts of the entity that need extra permissions but were restored (like e.g. terms) would be redundant.
In other words: permissions for modifying an entity part should only be checked if that part is effectively modified by the request. They should not be checked if the part is restored unchanged after it was first cleared.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T166586 Consistently check permission for entity creation | |||
| Resolved | WMDE-leszek | T170673 Make ChangeOps define required permissions | |||
| Open | None | T171484 When checking permissions in the context of applying the "clear" flag in wbeditentity, only check effective modifications. | |||
| Open | None | T171483 Check any special permissions like entity-term when applying the "clear" flag in wbebeditentity | |||
| Declined | GoranSMilovanovic | T171876 Create grafana dashboard for tracking the usage of the "clear" feature of wbeditentity | |||
| Resolved | daniel | T171609 Track usage of the "clear" feature of wbeditentity in statds | |||
| Resolved | daniel | T172100 get list of users of API module wbeditentity with clear flag |
According to the analysis of P5835 (see comments), it seems that the "clear" lag is used primarily to completely empty out an entity in preparation of turning it into a redirect. We could continue supporting this used case by keeping the "clear" flag, but disallowing any data to be re-added to the entity in the same request. That would avoid the need for determining the "effective" edit for checking permissions, etc.
If we want to remove the clear flag or change semantics, the following tools will be the ones most heavily affected: