Last modified: 2012-08-04 21:10:39 UTC
We want to test the AFTv5 Edit CTA logic, and to make sure that the AFTv5 Call to Edit is only shown if users have the right to edit a page. To that end, we have created the following two test pages, and asked for someone with Admin privileges on prototype to semi-protect and fully protect them for testing purposes: Semi-protected page test: http://prototype.wikimedia.org/release-en/Edit_semi_protected_page_test Fully protected page test: http://prototype.wikimedia.org/release-en/Edit_protected_page_test Note that these test pages are now editable and this test cannot begin until we either have admin privileges to do this ourselves -- or an administrator for prototype is kind enough to protect and semi-protect these pages for testing purposes. We will then ask regular users (without admin or edit privileges) to test whether or not the Edit CTA is shown on these protected or semi-protected pages. We will also ask them to confirm that they cannot edit this page through other means. You can read more about this Call to Edit on our AFTv5 feature requirements page: http://www.mediawiki.org/wiki/Article_feedback/Version_5/Feature_Requirements#Edit_this_page
Fixed in r105747 and r105750 and tested locally.
Put the instructions on the testing page so I can close this ticket. If it fails to work, one of the testers can open a new one, because it will indeed be a different bug.
Thanks, Reha. I have copied these instructions and will re-test this properly in the morning. Howie protected and semi-protected these pages, but I am still getting access to the CTA, even though I am not an admin or editor. So something is still the matter, but I can investigate more later. For now, I have re-opened it so this issue stays on our radar. We can close this again when it has been fully resolved. Thanks, -f
I was given to understand that I should close bugs when the issue was fixed checked in to SVN, not when the fix went up to Prototype. Is that not the right thing to do?
According to Yoni, it is OK for me to re-open a ticket if I can't verify it on prototype, or if I want to make sure that it gets validated by us. But I am not sure if that's the best thing to do, there may be a better way. I want to keep these tickets on my radar, even if you think it has been resolved. On the other hand, you need a way to tell us when you think it has been solved. Suggestions welcome. Also note that this ticket is worth re-opening for another reason, because we now have a new requirement which we will have to test through this ticket. It's for a 'Call to Learn more' CTA, to be shown to users who cannot edit an article (instead of the 'Call to Edit' CTA): https://bugzilla.wikimedia.org/show_bug.cgi?id=32981
To be clear, if a user cannot edit a page because it is protected or semi-protected, we should show them the new 'Learn more' CTA requested in Bug 32981 -- instead of the 'Edit this page' CTA. You can read more about the new 'Learn more' CTA on our feature requirements page: http://www.mediawiki.org/wiki/Article_feedback/Version_5/Feature_Requirements#Learn_more
In the code from Monday's push, I was able to confirm that the new CTA2 is shown to anonymous users on protected andsemi-protected pages (instead of the Edit CTA1). But I also ran into a problem after clicking on 'Post your feedback' as an administrator on this semi-protected page: http://prototype.wikimedia.org/release-en/Edit_semi_protected_page_test Even though I have admin privileges and can edit that page, the software displayed the wrong CTA2 'Learn more' (instead of CTA1 'Edit this page'). If a page is protected or semi-protected but the user has editor status, they should get the CTA1 Call to Edit
Some issues with page edit restrictions: 1) wgRestrictionEdit contain "autoconfirmed" for semi-protected and "sysop" for protected pages 2) wgUserGroups contain any of "*", "user", "sysop" and probably more what logic applied when i need to check if the page can be edited by a user?
On Dec 13, 2011, at 12:04 PM, Roan Kattouw wrote: All groups that are in wgRestrictionEdit must also be in wgUserGroups. If there is a group that is in wgRestrictionEdit but not in wgUserGroups, the user cannot edit. If wgRestrictionEdit is empty, anyone can edit. Roan ----- On Tue, Dec 13, 2011 at 9:07 PM, Yoni Shostak wrote: That is the current logic. I'm closing the ticket as invalid, unless Fabrice has any objections.
On Dec 13, 2011, at 1:30 PM, Fabrice Florin wrote: Thank you! It sounds like testing this tomorrow on en.labs.wikimedia.org would be more effective than on prototype. Roan, would you be able to give both Yoni and I admin powers on that server, so we can test this quickly tomorrow? Here's my profile on that server: http://en.labs.wikimedia.org/wiki/User:Fabrice_Florin Thank you! Fabrice On Dec 13, 2011, at 12:51 PM, Yoni Shostak wrote: This means that the the user account you are using on prototype, is not member of any group that is allowed to edit the test pages. I will add myself to the relevant groups and verify that it works as expected. As to your question regarding goals for 1.0, my understanding is that it depends on the configuration of the production environment. I am working under the assumption that the security/permissions are configured identically on prototype and production. Yoni Shostak
For testing on prototype: http://prototype.wikimedia.org/release-en/Semi-Protected_Page http://prototype.wikimedia.org/release-en/Protected_Page
Tested to work on prototype with the following results: Protected page: Admin can edit Non-admin cannot edit Not logged in - cannot edit this is as expected Semi-protected page: No user can edit. This is because semi-protected page requires the user to be in the "autoconfirmed" group for editing. However, the default user groups are "*" and "users". The administrators are in the "sysop" user group, and bureaucrats are in their own user group. the currently implemented logic matches Roan's description, and the test results match the expected behavior in this case. I am closing this ticket as resolved/fixed.
Sounds good. Let's test again when we are on en.labs.wikimedia.org. And then test one last time after launch.
