| Ruakh | |
| Jun 17 2018, 7:16 PM |
| F22333506: Screen Shot 2018-06-17 at 11.18.47 PM.png | |
| Jun 18 2018, 3:21 AM |
Steps to reproduce:
Expected behavior: should be able to see the page.
Actual behavior: error-message about the account not yet being approved.
Workaround: log out of https://phabricator.wikimedia.org/ until the account has been approved.
Upstream: https://secure.phabricator.com/T13154
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| operations/puppet | production | +2 -0 | Phab: Explain to not-yet-approved users how they can access tasks |
@MZMcBride: Resetting priority - if you think this is high priority please explain why.
An issue that impairs the ability of a user to perform basic functions such as reading a task is a high priority to get resolved. Can you explain why you reset the priority here?
I tried to create a test account just now and a verified e-mail address is required. Since when?
Am I understanding this issue correctly? The current behavior when a new user registers a Wikimedia Phabricator account to file a bug or report some kind of issue is presenting them with this screen?
I'm really struggling to see how this behavior is appropriate or acceptable.
@mmodell enabled auth.require-approval two days ago, presumably due to T162026, which is a general task discussing phabricator vandalism, which was escalated to UBN three days ago due to a vandalism spree.
Requiring approval is justified, blocking the ability to read until they're approved is not.
The number of affected user account is very small and the account approval queue is processed. So I'm going to reset the task priority.
Makes sense; quoting from upstream:
But we don't have infinite resources and this affects only affects a small portion of users (users on public installs with approval required), usually fairly briefly (only until their account is approved), so it's hard to imagine this change ever making it high enough on the priority list to get implementation in the upstream.
Upstream also implies that this requires 107 places in the code base to get checked and potentially updated. I do not think that we should spend time on that (and maintaining our custom diff) either.
Proposing to close this task as declined.
Edit: Had not seen the task summary change. My last line refers to "patch everything in Phabricator to allow unapproved users to be treated as logged out for permissions purposes"
Yeah. If that part is declined then I don't think wontfixing this is an option, the approval requirement must be removed.
https://secure.phabricator.com/T13154#239449 offers code that we could consider maintaining downstream.
Can we set up a temporary bug tracker that users can be redirected to until this is fixed? Unless I'm misunderstanding the summary here, Phabricator is completely non-functional for all but established users because of this.
Can the error message be changed to advise users to log out to see the pages?
Frankly, if the entire bug tracker can just go down like this for over a week, is it okay to be using it in the first place?
The reason why this is high priority is https://lists.wikimedia.org/pipermail/wikitech-l/2018-June/090220.html (the registration restrictions are "temporary" and supposed to be reverted as soon as possible).
Change 441806 had a related patch set uploaded (by Aklapper; owner: Aklapper):
[operations/puppet@production] Phab: Explain to not-yet-approved users how they can access tasks
You are free to fork anything.
Can the error message be changed to advise users to log out to see the pages?
Yes, see the previous comment.
Change 441806 merged by Rush:
[operations/puppet@production] Phab: Explain to not-yet-approved users how they can access tasks
https://gerrit.wikimedia.org/r/c/operations/puppet/+/441904
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, (/etc/puppet/modules/phabricator/data/fixed_settings.yaml): did not find expected key while parsing a block mapping at line 221 column 3 at /etc/puppet/modules/phabricator/manifests/init.pp:79:23 on node phab1001.eqiad.wmnet Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run
I turned off the account approval queue, replacing it with range blocks on mediawiki.org and wikitech.wikimedia.org. See T162026#4318141 for (private) details.
Has the account approval queue been re-enabled? From the #wikimedia IRC channel this evening:
[20:23] <bernard_> can someone cancel my phab approval [20:23] <bernard_> it doesn't let me read anything [20:51] <bernard_> nevermind. logging out does the trick
Another report in the MediaWiki-General IRC channel just now:
[00:32] <okdana> is there something special i need to do to open an account? it says an admin has to approve me [00:32] <okdana> is it just slow because it's the week end?
I'm re-opening this task as the issue is not resolved.
Yes: https://lists.wikimedia.org/pipermail/wikitech-l/2018-July/090269.html
Way forward is still being discussed.
Summary: Once we have the necessary tooling in place (namely a vandalism detection system and reversion) we will turn account approval off.