Support non-enwiki projects

[stwalkerster]

ZI Jony approached us with a request to allow bnwiki access to the ACC tool for their local account creation issues. They've requested full tool admin access to manage the bnwiki side. DQ and I discussed this, and we've agreed that we want to support this.

This presents with a number of technical and operational challenges. On the technical side, there's these:

• Multilingual interface
• Separation of requests, queues, close templates, etc, and authorisation checks for those
• Creation of requests directly in specific queues (related to Create referral links to triage requests into specific queues. #517)

We can probably use some of the event management code I've written (#281) for parts of this, as that has some basic separation of queue permissions and different request interfaces.

On the operational side, we need to:

• Think about how tool admin access works across the different ACL domains, including user suspension etc.
• Consider global policies on tool access
• Consider audit visibility, and communication channels for bnwiki. Do we want a separate mailing list? IRC channel? How will bot notifications / custom closes work?

There's a LOT hard coded into the system to be enwiki-only, so this task will act as an overall tracking task for the "features" project, but when this work gets started, I expect we will have a new project to track everything.

---

Overall design plan

The design for this will be split into two parts - broadly split into i18n and non-i18n.

Point 1: i18n

Firstly, to internationalise the tool. A lot of strings in the interface are hard-coded, and thus are easy targets for translation. A lot of the remaining strings are domain-specific data, which won't be a problem as it'll be handled by point 2. Use of resources such as intuition/translatewiki will be good here - we just need to integrate it into the tool.

Point 2: Domains

I want to introduce the concept of "domains" to the tool. This is nothing to do with DNS, rather I'm using the definition "A group of related items, topics, or subjects."

My expectation is that this will be a form of data-specific user rights which will sit alongside the existing role-based access control. The idea is that every request will be tagged with a specific "domain" which it sits in. Every user will also sit in a domain, and if the domains match, then the user can see the record. Broadly speaking, a domain will have all information specific to a wiki instance attached to it, including things like the API address and the default close template.

For the vast majority of users, I expect access to be granted to a single domain - either bnwiki or enwiki. Users in a single domain will see no difference in the tool interface. For multi-domain users, I plan to add a "domain switcher" which will let users log in to a different domain. While in the domain, nothing in other domains will be visible. For an idea of the UI I'm planning for this, take a look at software such as AWS (account switching), the Unifi Controller (site switching), or even OpenStack Horizon (project switching) - essentially a dropdown allowing a switch, and following the switch, only data in that domain is visible.

Some stuff, like requests, close templates, welcome templates, bans, and role grants etc offer obvious targets to be domain-specific. Other stuff, like users, are obvious targets to be global.

Some things will need to be moved from their current location to a domain-specific location, such as some user preferences (email signature, welcome template choice, etc), and the default close template.

Known hurdles and open questions

• Translation of styled text. Do we accept raw HTML in translations, or do we limit translations to text only? How do we then handle styled text?
  • https://commonmark.thephpleague.com/
• User approval/suspension. Users are global, so how do we handle this sort of stuff? Allow domain-local admins to suspend if only in their domain seems reasonable, else it might have to fall to a tool root to unpick.
• Steward access - how do we manage default access to all domains?
• OAuth credentials - are these per-wiki, or global across all wikis?
• How does the hospital queue (and other virtual queues) work?
• API queries and domain interaction?

Overall task list

This is the breakdown into a number of stages that we can to probably push into prod fairly independently. The (very) rough dependency graph is as follows:

• [:floppy_disk:] Basic multiproject database infrastructure #590 Basic database infra (four new tables), initial domain seed, initial request queue seed
  • [:lock:] Multiproject domain UI #591 Domain editing UI, security around UI.
    • [:lock:] Current domain session variable #592 Domain session variable
      • [:lock:] Domain switcher UI #593 Domain switching UI
      • [:lock:] User domain access UI #614 User domain access UI
      • [:floppy_disk:] Multiproject preferences updates #594 language and default domain option in preferences, split prefs into new table
        • [:lock:] Include domains in signups #595 Signup to domains
      • Domain default close template #596 Implement usage of default close template
      • Domain custom mailing list config #597 Implement usage of custom mailing list
      • Domain custom notifications target config #598 Implement usage of custom notifications target
      • [:floppy_disk:] Domain columns to other tables #599 Add domain column to request/close templates/welcome template/userrole/sitenotice/logs/jobqueue, populate appropriately
        • [:lock:] Domain filtering #600 Start filtering on everything
  • Multiproject request queue UI #601 Request queue editing UI
    • [:floppy_disk:] Migrate multiproject request queues to table #602 Request - split out status column, start using new db table, look up default queue, log changes
      • Implement multiproject request queue enabled flag #603 Handle enabled flag, show queue if requests present but not enabled
  • [:lock:] Multiproject request form UI #604 Request form UI, new, editing, etc
    • [:floppy_disk:, :lock:] Enable multiproject request forms publicly #605 New field on request, change public routes to start using forms
      • Remove default creation form #606 Consider removing default form, update links, etc.

[Matthewrbowker]

For the multilingual interface, I recommend Krinkle's intuition: https://github.com/Krinkle/intuition/wiki/Documentation along with TranslateWiki. We set that up for XTools and it worked well.

[MisterZillur]

Any update on this? we can have a separate mailing list, but can be used same IRC channel. We also can use the same mailing list and IRC channel by renamed as wikipedia-accounts.

[stwalkerster]

Work has so far not yet started. I want the recent newinternal branch merge to settle somewhat, as well as enable the updates to OAuth before truly getting started. I do have vague plans already, but this will need to be broken down into smaller, lower risk pieces of work which can be put into prod individually, to avoid an enormous code review and merge challenge at the end like we had for newinternal.

From the policy/procedural standpoint, can you give me a link to where this has been discussed on bnwiki? I should have asked for this before, so my apologies for not doing so.

[MisterZillur]

100% support, hopefully we have no obstacles in getting it started. https://w.wiki/YTL

[stwalkerster]

Cheers, I've dumped some of the initial notes I made offline into the description of the ticket; I'll try and split this out into smaller units of work that we can complete independently and deploy to prod in small chunks. I don't want a repeat of the newinternal reviews which were open for literally years.

[stjohann]

JFYI: today I added the link to your tool to https://ru.wikipedia.org/wiki/MediaWiki:Createacct-imgcaptcha-help with a mention that it is in English since there isn’t a better solution.

Hopefully it's alright that some requests to ACC will not be in English (even though I noted that the form is in English). This seems like the only solution at the moment to the issue of inaccessible account creation captcha raised in https://phabricator.wikimedia.org/T6845 while the WMF is slacking.

[stwalkerster]

@stjohann: I don't have a problem with requests coming to us, but I still think it's going to require some special handling on our side at least until this ticket is properly resolved (when these problems will hopefully disappear)

The tool currently will only create accounts on the English Wikipedia. If you're directing people to us due to an ruwiki block stopping account creation, then an account created only on the English Wikipedia will do no good (as the account creation block will prevent the account attaching to ruwiki as well). We can manually override this, but this sort of cross-project use is fairly outside what this tool was designed to help accomodate (which again, this ticket is supposed to be trying to resolve, but it's not done yet). It's also worth noting that we evaluate requests based on the English Wikipedia username policy, so if there are discrepancies between ruwiki and enwiki's username policies, it may cause some friction.

I can create a custom form for ruwiki for the time being as well, which can route the ruwiki requests into a separate queue for easier handling on our side. I'd need you to update the form link (to https://accounts.wmflabs.org/index.php/r/enwiki/ruwiki-requests ) once I've got the form set up properly. If you could provide translations for the below four bits of text (syntax is markdown, not wikitext), I can also include them on the form.

Main block of text shown above the form:

## Request an account!

We will need a few bits of information in order to create your account. However, please keep in mind that you do not need an account to read the encyclopedia or look up information - that can be done by anyone with or without an account. The first thing we need is a username, and secondly, a **valid email address that we can send your password to** (please don't use temporary inboxes, or email aliasing, as this may cause your request to be rejected). If you want to leave any comments, feel free to do so in the comments field below. Note that if you use this form, your IP address will be recorded, and displayed to [those who review account requests](https://accounts.wmflabs.org/internal.php/statistics/users). When you are done, click the "Submit" button.

**Please note!**
We do not have access to existing account data. If you have lost your password, please reset it using [this form](https://en.wikipedia.org/wiki/Special:PasswordReset) at wikipedia.org. If you are trying to 'take over' an account that already exists, please use ["Changing usernames/Usurpation"](http://en.wikipedia.org/wiki/WP:CHU/U) at wikipedia.org. We cannot do either of these things for you.
{:.alert.alert-warning}

If you have not yet done so, please review the [Username Policy](https://en.wikipedia.org/wiki/Wikipedia:Username_policy) before submitting a request.

Help text below the username field:

Case sensitive, first letter is always capitalized, you do not need to use all uppercase. Note that this need not be your real name. Please make sure you don't leave any trailing spaces or underscores on your requested username. Usernames may not consist entirely of numbers, contain the following characters: `# / | [ ] { } < > @ % : =` or exceed 85 characters in length.

Help text below the email fields:

We need a valid email in order to send you your password and confirm your account request. Without it, you will not receive your password, and will be unable to log in to your account.

Help text below the comments field:

Any additional details you feel are relevant may be placed here. **Please do NOT ask for a specific password. One will be randomly created for you.**

[stjohann]

No, in this case, this is a link in Special:CreateAccount for people who cannot complete the captcha, not ‘in case of a local block’.

Translations:

## Запросить учётную запись!

Нам нужно немного информации, чтобы создать вашу учётную запись. Тем не менее, пожалуйста, учтите, что вам не нужна учётная запись для чтения энциклопедии или поиска информации — это могут делать все посетители и без учётной записи. Первое, что нам нужно, — имя учётной записи, а затем — **корректный адрес электронной почты, на который можно послать вам пароль** (пожалуйста, не используйте временные адрес или алиасы адресов, ваш запрос может быть отклонён). Если вы хотите оставить любые комментарии, это можно сделать в поле комментариев. Учтите, что если вы используете эту форму, ваш IP-адрес будет записан и отображён [проверяющим запросы на создание учётных записей](https://accounts.wmflabs.org/internal.php/statistics/users). Когда вы закончите заполнение формы, нажмите кнопку «Submit».

**Учтите!**
У нас нет доступа к существующим данным учётных записей. Если вы потеряли свой пароль, пожалуйста, сбросьте его [через форму сброса пароля](https://ru.wikipedia.org/wiki/Special:PasswordReset) на wikipedia.org. Если вы хотите «занять» существующее имя учётной записи, пожалуйста, воспользуйтесь страницей [«Запросы на узурпацию»](https://ru.wikipedia.org/wiki/Википедия:Запросы_на_узурпацию) на wikipedia.org. Мы не сможем выполнить эти запросы.
{:.alert.alert-warning}

Если вы ещё не сделали этого, пожалуйста, ознакомьтесь с [правилом о допустимых именах участников](https://ru.wikipedia.org/wiki/Википедия:Имена_участников) перед подачей запроса.

Чувствительно к регистру, первая буква всегда заглавная, не требуется писать полностью в первом регистре. Учтите, что не требуется, чтобы это было реальное имя. Пожалуйста, убедитесь, что вы не оставили пробелов или подчёркиваний после запрошенного имени учётной записи. Имена не могут быть целиком из чисел, содержать следующих символов: `# / | [ ] { } < > @ % : =` или быть длиннее 85 символов.

Нам нужен корректный адрес электронной почты, чтобы выслать вам ваш пароль и выполнить ваш запрос. Без него вы не получите свой пароль и не сможете войти в свою учётную запись.

Любые другие подробности, которые вы считаете важными, могут быть добавлены здесь. **Пожалуйста, НЕ запрашивайте конкретный пароль. Для вас будет создан случайный пароль.**

(As I didn't know if buttons and labels would be translated, I left "Submit" in translation as is.)

[stwalkerster]

Yeah, not everything is translatable at the moment (again, this ticket!).

I've applied the translations to https://accounts.wmflabs.org/index.php/r/enwiki/ruwiki-requests and enabled the necessary config. We'll see how this goes. 😄

[stjohann]

Changed the interface message to the Russian form, thanks for the quick work :-) Hopefully it won't be too much for the reviewers.