විකිපීඩියා:Request an account/Guide
This is a guide to using the account creation request interface. All new users to the interface should read this page carefully, and all tool users should check periodically for modifications.
|Continual failure to correctly assess requests may result in suspension of tool access.|
Read a related email
|The ACC interface is not a toy. If it says you can do something, you can do it. Please use this responsibly. Abuse of the system will result in immediate loss of access/tools. You are responsible for all of your actions on this tool and when creating accounts on Wikipedia. Use of an automated tool is not an excuse.|
- 1 Registering for use
- 2 Using the interface
- 3 General Notes
- 4 Creating Accounts
- 5 Interface Administrators
- 6 Interface Developers
- 7 CheckUsers
- 8 Notes
- 9 See also
Registering for use[සංස්කරණය]
To use the interface to handle requests, you must register here and complete your registration by leaving a signed edit on your Wikipedia user talk page confirming that you wish to sign up. Your account must be approved by an interface administrator and the administrator who approves your account will notify you, usually on your talk page.
Please note that the interface administrators (herein referred to as admins) are not the same as Wikipedia administrators (herein referred to as sysops). Similarly, most Wikipedia administrators are not interface administrators.
Please also note that tool accounts unused for 45 days will likely be suspended. Contact a tool admin to regain access.
Despite the similar names, you do not need the "account creator" right to use the account creation interface. This is an entirely separate permission from being granted access to the interface itself. Your rights as a regular Wikipedia editor in good standing are sufficient to create accounts in normal, uncomplicated situations. After gaining experience using the account creation interface, you may wish to apply for the "account creator" right which lets you handle more complex cases and override certain limits.
Qualifications for using the interface[සංස්කරණය]
Usually a user should simply be trusted by the approving administrator. To qualify as an ACC user, you should meet the following minimum requirements:
- You must not have had a recent block on the English Wikipedia
- You must not have any history of account-related abuse, such as sockpuppetry
- You must have read, understood and agreed with the ACC guidelines
- Your account on Wikipedia must be more than 60 days old
Using the interface[සංස්කරණය]
After logging in, you will see the main interface — see screenshot below — which displays a list of open requests, requests needing account creator attention, a list of requests needing checkuser attention, and a list of the last five closed requests. After you mark a request as being handled, each open request or request needing account creator attention or checkuser attention will have a string of links, like this:
Zoom (CMT) [ Address@website.com (2) | 127.0.0.1 (100) ] WikipediaAccount | Ban: IP — E-Mail — Name
Please remember that account creating is not a race! The requests that end up in the ACC interface are accounts which couldn't have been created under normal circumstances. Please keep this in mind and react thoughtfully. It happens sometimes that one is in the middle of a situation and one doesn't know what action to take. Just ask in the Accounts IRC Channel for help in situations such as these: සැකිල්ල:IRC. There are always other interface users online who are willing to assist you. In case you do not get a satisfactory response, and do not know which course to undertake, it is better to defer the request to other users rather than to undertake a wrong course of action. If you ask for help, you will need to provide the link shown on the 'zoom' page to the other user to allow them to see the private data.
Please note: If you seem to 'rush' through a request (for example, by not performing all the checks listed below), you may lose access to the tool. It is essential that all the checks are performed to ensure that accounts are correctly created or declined.
The IP Address links group contains the following links:
- Talk Page links to the IP's talk page
- Local Contributions links to the IP's contributions on the English Wikipedia
- Global Contributions links to the IP's contributions across all Wikimedia projects
- Local Blocks links to the IP's block log on the English Wikipedia
- Local Range Blocks checks for any applicable IP-range blocks on the English Wikipedia
- Global Blocks links to the IP's global block log on Meta
- Global Range Blocks checks for any applicable global IP-range blocks or locally disabled global blocks
- Whois runs a WHOIS on the IP
- Geolocate Geolocates the IP
- Abuse Filter Log shows all actions from the IP that tripped an Edit Filter
Keep in mind that some IP addresses may have been blocked on Wikipedia or even globally. When this happens, the IP is usually a shared address. This can be confirmed by doing a WHOIS on the address. Sometimes, it is good to assume good faith in situations such as these. However, it should be remembered that advice can be sought in the IRC channel mentioned above. Remember: Checkuser advice needs to be sought if any rangeblock is present on the IP address or there is any indication of sockpuppetry.
If the request was made through a proxy, then links for the proxy's IP address will also be shown. The links shown are the same as those shown for the normal IP.
The User name links group contains the following:
- User Page: A link to the user page of the requested account
- Creation log: A link to check the creation logs of the requested account
- SUL util: A link to check the existence of the requested user name on other Wikimedia projects
- Username List: A link to the user list to check for similar account names
- Google search: A link to Google, which searches occurrences of the requested account name on Google's search index
You should also check the username. Remember to keep the Wikipedia:Username policy (WP:U) in mind when reviewing a name. Always do a Google search to see if it is the name of a company or organization, which may be considered promotional and a violation of Username Policy. If the name's link to a company is ambiguous, then you should take where the requester's IP Address geolocates to in relation to the relevant company, the requester's EMail address, and the requester's comment into consideration. It is also important to check whether the requested username made any contributions on other Wikimedia Projects. This way you could see whether the requested name forms part of a global account or unified login — if so the account should not be created. When you are pleased with the request you can click the Create! link to create the account.
The Account creation link group contains the following:
- Create!: A link to create the requested account
The Actions group contains the possible resolutions that can be given to a request:
- Created! if you were able to create the account
- Similar if it is too similar—see below for details
- Taken if the username was already taken (but if the username was created a very short while after the request - for example a few minutes after - then you can assume that it is the same user, and Drop the request instead)
- SUL Taken if the username is already a part of a SUL account
- UPolicy if the requested username violates the username policy
- Invalid if it contains bad characters—such as #, \, / - do not use this for usernames with non-Latin characters. These are allowed. Also note that in some cases bugs in the tool may replace certain non-Latin characters in a username with invalid characters when filling in the username field on Special:Userlogin. In such cases it is recommended that you attempt to manually copy and paste the name as it appears in the ACC interface into the username field.
- Password Reset if you have sent a password reset email to a similar username, because it was created recently and appears to belong to the requestor. Note that if it was created very recently (e.g. a few minutes after request) you can assume that the requester managed to create it and Drop the request.
- Custom close the request and send a custom email to the user
- Drop if the request is a bad request—for example a ban accompanies a drop, see below
The 'Defer' group allows you to send the request for the attention of a normal user, flagged user, or a checkuser.
- Defer to flagged users if a user with the accountcreator permission needs to handle the request
- Defer to checkusers if the request needs to be checked by a checkuser before continuing (this includes any IP Address in a blocked range, regardless of the reason or who placed it)
The SUL Taken option should be used when the requested name is part of a unified login—such as described in the previous section. If the username is similar to that of somebody on another wiki then the Similar option should be used, and if the username is the same as somebody on another wiki then Taken should be used.
When none of the above options describes the particular situation, you should use the Custom option. You would then be prompted for a custom email message that would be sent to the requester. The message you write will form the entire content of the email to the user.
Note: All of these links perform an action on the request and do not link to the relevant policy. All resolutions except the Defer and Drop resolutions send an e-mail to the requester indicating what has happened to the request. If the request was already closed or deferred to account creators, then the Defer to account creators link becomes Defer to users, which returns it to the main queue.
The Ban links group is only available to the interface administrators and contains the following three ban links:
- One for banning the IP address.
- One to ban the E-Mail address.
- One to ban the requested account name.
This group is located on the same line as the Email, IP Address, Username, and reservation information.
Last 5 Closed requests[සංස්කරණය]
The Last 5 Closed requests queue displays just that, the last five closed requests. Clicking Zoom brings you to the username's interface log. Clicking on the username brings you to that user's userpage, and Reset defers the request to users. Keep in mind that the email and IP addresses of closed requests is not visible.
There is another section at the end, which is designed to prevent people from racing through requests just to make sure they review the request properly. This is called request reservations, where you can mark a request as being handled, so other users can see you are dealing with that request. The tool will not allow you to handle a request which has been reserved by another user.
If you reserve a request and then need to go offline without completing the request, please break the reservation beforehand, so that another user can complete the request, unless you have good reason to require the request to be handled by yourself, in which case you must leave a comment. If you do not do this, the request will remain reserved and cannot be created by other users; a tool admin may forcefully break the reservation if you have left no indication as to why you need to keep the request reserved.
Requests will be automatically unreserved when you close them, but there is nothing stopping you from marking a closed request as being handled. All currently reserved requests will show up on one of the statistics pages, accessible by clicking the Statistics link at the top of the page. The tool is currently set to warn users if they attempt to reserve more than 1 request. This is to attempt to discourage people from hogging lots of requests all at once. When you reserve a request, it will automatically take you to the zoom screen, to help focus you on that one request.
Tool admins are now capable of breaking a reservation, but they should only do this when a request has been waiting for a good few hours without indication why, and if the user who reserved the request cannot be contacted in a reasonable amount of time. Abuse of this will not be taken lightly.
Interface administrators can ban and unban an IP address, an E-Mail address, or a Account Name from submitting requests. A ban should be placed in these circumstances—as an example, there are a few more conditions, which are also more rare:
- The IP is a recent vandal or spammer.
- The IP has sent multiple requests in a short period of time, where these requests are not reasonable.
- The Name has been the subject of multiple vandal or promotional requests.
Bans should be commented at the time of the ban, and there are four length options:
- 24 hours
- One week
- One month
Again, all of the interface administrators can ban and unban an IP or E-Mail address, but abusing bans will result in loss of access—see below. Remember WP:BLOCK — IP addresses can frequently change, so extended blocking periods are not recommended. The maximum period to use in non-exceptional circumstances is 1 week for IP addresses. Fake email addresses can be banned indefinitely, whereas a user who appears to have a valid email address can be blocked for a period of time, to allow the user to reform. Users blocked on the English Wiki are automatically redirected to the unblock mailing list, so we shouldn't have to handle those.
Checking for multiple requests[සංස්කරණය]
You should check for multiple requests from an IP address or an E-Mail address. To do so, click the Zoom button next to an open request or click the requested username in the list of last 5 closed requests, or go to the logs—see below and click a request number. At the end of the request line—like you see normally for all open requests, you will see the UTC date and time the request was submitted. Farther down the page you would also see a list of other requests—if any, from that IP address or E-Mail address. If there are multiple requests, please ban the offender from sending requests to the list. Please keep in mind that shared IP addresses are common.
In the header of every page, there are a number of links:
- Account Requests: returns you to the request queue
- Logs: shows recent activity
- User list: shows all users with access to the tool
- Ban management: shows all active bans
- Message management: shows the current interface messages:
- Mail Messages which are sent to the requester when the request is closed
- Public Interface messages which are messages that people can see when submitting their requests for an account
- Internal Interface messages which are messages that the users of the interface see when using the interface
- User management: (admins only) where interface users can be approved, blocked, promoted to admins or demoted to users
- Search: allows a search of the ACC logs (not Wikipedia's creation logs)
- by email address
- by IP address (admins only)
- by requested username
- A wildcard is automatically added to each end of the search query.
- Statistics: shows statistics about the ACC tool and the users of the tool
- Preferences: allows you to change your settings:
- Enable use of the secure server
- Enable WelcomerBot welcoming of the users I create
- Your signature (wikicode)
- Welcoming template to use
- You can also change your password on this screen
- Guide: Opens this guide
- If the exact wording of the documentation prevents you from creating an account that you feel should be created, ignore it and leave a comment explaining why.
- If the Whois determines that the IP belongs to AOL, then the IP address is not the correct IP address for that user; we have no way of finding the actual IP address.[note 1]
- If there is any rangeblock on the requesting IP or any indication of sockpuppetry, defer the request to CheckUsers. Users creating accounts in such cases without consulting a CheckUser will be suspended.
- Remember that global blocks are not the same as local blocks. Global contribs is a collective of contribs across all wikis, but global blocks are blocks that affect ALL wikis.
- Using a script or other program to automatically handle requests in any way (includes reserving) is taken to lightly and will probably result in account suspension. Using an automated refresher, however, is generally OK, as long as the refresh time is considerate to the toolserver's resources (at most once a minute).
- If it appears that the user created the account themselves after the request was made, just drop the request, as they don't need to be confused with any of our other messages. Make sure you leave a comment saying they self-created though if you do this. If you do click "Taken", then there is a saving clause which says "(unless you had created the account yourself after requesting it)", but a drop is preferred.
- If you need to make any form of a comment to the requester, either use the "Custom Close" button if you are immediately closing and need to explain something to them at that point or email the user directly if you want the user to be able to respond to clarify something before you decide on how to close the request, please make sure you add the firstname.lastname@example.org mailing list to either the recipients, carbon copy (CC) or blind carbon copy (BCC) lists for reference. The requesting user can not see any comments left in the request itself, all comments there will only be viewable by other tool users (or only administrators if you choose to mark the comment as "Admin Only").
- If you need to log off and you have a request reserved, please break the reservation or leave a comment as to why you still need to handle this request.
Once you have reserved a request as above, and decided that the account should be created, click the Create! link next to the desired username. This will bring you to the MediaWiki account creation form. The name and email will be filled in automatically. Do not type in a password manually—simply click the By Email button and a randomly-generated one will be emailed to the user. If the By Email button isn't visible next to the Create Account button, you may need to login.
If you do accidentally type in a password and click Create Account, go to Special:Userlogin, type in the username and click Email new password. This will reveal your IP to the requester, so try to avoid doing this. Once the account has been created, click Created! next to the request on the ACC tool.
Please note on creates where there are no issues with the request such as vandalism, similar names, etc. there is no need to leave a comment like "Everything looks good with this request.".
If the account is too similar ("Flagged user needed")[සංස්කරණය]
Sometimes, Wikipedia will not allow you to create an account if the requested user name is (a) a perfect match of an existing global account or (b) too similar to an existing local account.
- In case of requests that are a perfect match to an existing local account on another wiki: if an account of the exact user name requested exists on any other language Wikipedia and has more than 0 edits, it should be declined as Taken. In case there are 0 edits by the perfectly matching account on the other language Wikipedia, and only if SUL is not unified, you can go ahead and create the account. Make sure that you create such an account only after you have conducted all the other relevant checks generally required on any new account request.
- If the requested user name is the same as a global account, it cannot be created; the request should be declined as SUL Taken.
(Please note that any new account request that is a 'perfect match' of an existing local account on the English Wikipedia will be rejected automatically, and the user requested to choose a new name.)
In case of accounts that are 'too similar' to existing accounts, only ACC tool users with the account creator flag are able to create the account - only if the account the request is too similar to is inactive. ACC tool users without the account creator flag, though not allowed to create the too similar account requests, are allowed to decline requests (Similar, Taken, UPolicy…).
Inactive accounts are determined by the following qualities:
- If the similar account has any edits on the English Wikipedia, then for it to be considered inactive, it must:
- Have been created over one year ago.
- Account has fewer than about fifteen global edits (whichever is largest for local/unattached accounts, the sum for a SUL account), none of which were within the last year.
- Last edit was made over one year ago.
- Last entry in logs occurred over one year ago.
- If the similar account has zero edits on the English Wikipedia:
- The account must have fewer than about fifteen edits globally, none of which were within the last 6 months.
- Be older than 6 months.
Based on the above rules, if the account the request is too similar to is active, then click Similar to close the request as too similar to an active account.
If the account the request is too similar to is inactive, you can go ahead and create the account, provided you are a flagged user, if not, you must break your reservation to allow a flagged user to create the account. Creating such an account should only be done after you have conducted all relevant checks required for any new account request. In order to create the account, you must check the "Ignore spoofing checks" box on the account creation page. This tells the MediaWiki software to ignore any similarity(ies) between the requested account and existing similar account(s), and thus allow the requested account to be created.
Interface administrators are trusted users who can, among other things, edit interface messages—they can use the Edit! buttons in Message management and Template management, and have access to a fifth option invisible to other users, User management, which allows them to approve, promote, demote, and suspend users. However, abuse of these tools is not tolerated, and the interface is not a toy. Abuse will result in immediate loss of access and tools!
A list of current interface admins can be found here: tools:~acc/statistics.php/Users
Interface administrators can change other users' access to the interface via User management. Available options—which vary based on the target user's status, are as follows:
- Approve — This allows newly-registered users to log in and use the interface.
- Count — Checks the edit count of users that need to be approved.
- Promote — Makes an approved user an interface administrator.
- Demote — Makes an interface administrator a regular user.
- Suspend — The equivalent of a block on Wikipedia. It is issued by an interface administrator and prevents the target user from logging in.
- Unsuspend — The equivalent of unblocking someone. Undoes suspension and allows the user to resume using the interface.
- Edit — Edit a user's email address and on-wiki username.
- Rename — Rename a user's interface account.
An example user readout looks like this:
5. [ FastLizard4 / FastLizard4 ] Suspend! - Demote! (Promoted by Rjd0060 [P:6|S:3|A:21|Dm:0|D:2])
The number really doesn't mean much, but the first name is the user's name on the interface. The second displays and links to the user's username on Wikipedia. The two links in blue are described above, the text in black indicates who approved/suspended/promoted the target user. The text in purple is the statistics for that admin being described in the particular entry—not the promoting admin. P is the number of promotions, S is the number of suspensions, A is the number of approvals, Dm is the number of demotions, and D is the number of accounts declined. As such, the purple statistics only appear for interface administrators.
The interface developers are the team who have commit access to the tool, and as such can modify the latest development version of the tool in the code repository. If you want something to be changed or added, or find a bug, you can contact one of them, but it's probably better to file a bug in the bug-tracker at https://jira.toolserver.org/. You could see the current development team on this page: tools:~acc/team.php.
The tool roots are SQL (retired), Cobi, OverlordQ (currently inactive), and Stwalkerster. They have access to the server that runs the tool, and are the only people who can modify the configuration of the tool, and update the tool to a new version. The tool roots also act as the liaison between the toolserver administrators, and the rest of the tool users. The tool developers and roots reserve the rights to modify the tool as necessary, and to remove access to the tool for any reason as they see fit.
CheckUsers on Wikipedia should have a flag set on their tool account that allows them to have access to CheckUser-only information from the tool. If you are a CheckUser and do not have the flag set on your tool account or are unsure if the flag is already set, please contact one of the tool roots (Cobi or Stwalkerster) and they will set the flag for you.
- AOL sends its users through a set of proxies, and which proxy is used for a specific user changes frequently to the extent that every single request from a user is sent through a different proxy. As default, AOL also strips off the X-Forwarded-For header that otherwise would enable servers to determine the IP of the original client. Being so, most servers cannot determine the IP of the original sender except for a few selected sites for which the header is kept. These include the Wikimedia Foundation servers, however the Toolserver is not one of them. As a result, while the clients real IP is visible on Wikipedia, we (using the ACC interface) only see the IP of the proxy server used for that specific request. Hence, all IP data for AOL requests on the ACC tool is useless, and can be safely ignored. There is no way for the Toolserver to gain access to the X-Forwarded-For data currently, and this situation is unlikely to change.