wontfix per bug 31863

Reopen, because this field is needed to allow anon users/maintenance scripts protecting a title against recreate (Yah, a rare usecase, but why not?). The field should be set only, when the pr_user field is 0, because than that is an anon user.

this field is needed to allow anon users/maintenance scripts protecting a title against recreate

Note that the protect right is ineffective unless you give them also the editprotected right - which makes the usecase even more rare.

Regardless, the field is not needed to provide the functionality since protected_titles.pt_user is not a unique key. Anons are already perfectly able to protect titles assuming they have the necessary rights.

As a side note, even the pt_user column is redundant, so yet another reason against pt_user_text.

Does the software currently allow this grant to be given to anons? If so, what is the error that happens when you try this?

If this isn't currently something possible, I suggest changing the task to instead be about the general feature. Then the scheme change will follow later (and might be done differently, for example, in light of the actor tables).

How about instead converting pt_user to use a reference to the actor table? I.e. add pt_actor

In T29872#5348258, @Krinkle wrote:

Does the software currently allow this grant to be given to anons? If so, what is the error that happens when you try this?

If this isn't currently something possible, I suggest changing the task to instead be about the general feature. Then the scheme change will follow later (and might be done differently, for example, in light of the actor tables).

No errors when I granted anon protect and editprotected and tried to protect a title. Can be closed as invalid?

I instead propose to replace pt_user, pt_reason_id and pt_timestamp with a new column referring to the logging table.