Extension talk:Approved Revs

Bug in combination with PageForms
When a regular user creates a page for the first time, it is unapproved. If the user follows the link to the newest, but unapproved version of the page, there is not formedit button, just the source edit.

The same procedure for an admin user (with autoapprove rights) is working fine. After creating a page, you are redirected to the form immediately when hitting edit.

These are the settings: $egApprovedRevsAutomaticApprovals = true; $egApprovedRevsShowApproveLatest = true; $egApprovedRevsBlankIfUnapproved = true;

I don't know if this has to be taken care of in PageForms or ApprovedRevs (or both). Krabina (talk) 09:39, 6 July 2022 (UTC)

Since the link to an unapproved page is &oldid= this is probably more a PF issue?


 * Are you basically saying that, if "oldid" is in the URL query string, "edit with form" doesn't show up? Yaron Koren (talk) 13:33, 6 July 2022 (UTC)


 * Yes, I guess this is what is happening. Krabina (talk) 10:44, 15 July 2022 (UTC)
 * Okay, actually, looking at this again, I think the issue is the "blank if unapproved" setting. If the page is unapproved and thus blank, it doesn't belong to any categories or officially contain any templates. So, unless you are doing namespace-based forms, there will be no form attached to the page - could that be it? Yaron Koren (talk) 13:45, 15 July 2022 (UTC)
 * No. The users use PageForms to create a page, the resulting page also belongs to a category. However, unless someone else approves the page, the second "edit" will not lead to the form again, but to the source view. Once a page is approved, the form is working as it should. For users with autoapprove rights, also creating a new page and then editing is working as expected. --Krabina (talk) 10:15, 19 July 2022 (UTC)
 * I don't understand - you have "blank if unapproved" set, and this is an unapproved page, so won't this page be blank, and thus belong to no categories? Yaron Koren (talk) 13:19, 19 July 2022 (UTC)
 * I see what you mean. So a user would have to click on "view latest version" first and then on edit to come back to the form. This is not very intuitive. If a regular user creates a new page, saves it and clicks on edit, he/she should be brougt back to the form. For other users, this page might not be shown, because it has no approved version (yet). But for the user who created it, I guess it is not intuitive to first click on the most recent version.
 * I don't think going to the latest revision would work either - the issue is that, officially, the page is blank and thus belongs to no categories. Thus Page Forms has no way to know that this page is form-editable, let alone which form to use. If this is a big problem, maybe you should undo the "blank if unapproved" setting? It can help in preventing bad page creation, but on the other hand sometimes you clearly do want unapproved pages to function normally. Yaron Koren (talk) 21:12, 19 July 2022 (UTC)
 * I tested this again. If you create the page, a blank page is shown indicating that there is a newer (unapproved) pagege. Clicking here leads to the editor as you described. Fine. But when you click on the link to the latest version, you look at the data you just entered and the page has a category assigned. However, there is only an edit link that again leads to the source editor instead of the designated form. Since the URL I am seeing is showing the &oldid, this is probably related to https://phabricator.wikimedia.org/T252525 and could be solved by page forms being able to handle this. Btw it does not help to set $egApprovedRevsBlankIfUnapproved = false; If this is set, I can see the page, but still editing of the unapproved page does not lead to the associated form.
 * Going to the latest revision will indeed show that category, but the page doesn't actually belong to that category - I think that's the issue. As for setting "blank if unapproved" to false - you need to re-save any page after making this setting change, for its category data to take effect. Yaron Koren (talk) 14:48, 24 August 2022 (UTC)

Bug with file upload with disabled file namespace
With $egApprovedRevsAutomaticApprovals = false; $egApprovedRevsEnabledNamespaces[NS_FILE] = false;

Files should not be getting approved. However on creation files are getting automatically approved (on their initial revision). This initial approval then counts against it in  (via  ) as the initial approval in the database, meaning that all subsequent revisions are approvable as well.

The fix I've put in place is to (in ) wrap   with   - then if files are not approvable generally, it never sets the initial approval and all is well, as far as I can tell.

Hopefully that's vaguely coherent... Lord Aro (talk) 16:38, 25 November 2022 (UTC)


 * The fact that that second setting doesn't disable file approvals does seem like a bug. But that first setting looks incorrect - it should be . Could that solve the problem? Yaron Koren (talk) 17:43, 27 November 2022 (UTC)