Talk:User Rights Requests and Suggestions
I made a small list of some user rights that needs to be reviewed, sorry if i forgot someone. Im considering the contribution scores as something orientative because there is people with low scores that published some unique info (it was one of the few persons in this whole able to do it, we was lucky they did it), i gave them the category of "epic edits" (whatever that means, lol is not related with wiki dedication but with the quality of his edits), there is other people (maybe not in this list) with high score because they was doing wiki manteainance/organization tasks additionally to research and/or decvelopement (btw we could make a new "R&D" user group). Im not sure if my understanding of the "VIP" group matches with yours, to me it looks like it could be used as a fallback for the users with either a higher contribution scrore or labeled as "epic editor" that became inactive (most from the list below)
nick | score | epic | active | trusted | others --------------------------------------------------------------- Flatz | low | yes | no | yes | Glevand | high | yes | no | yes | Kakaroto | low | yes | no | yes | Kozarovv | high | - | yes | yes | M4j0r | high | yes | yes | yes | MikeM64 | high | - | yes | yes | Mrjaredbeta | high | - | yes | yes | Mysis | high | yes | no | yes | Naehrwert | medium | yes | no | yes | Nas plugi | medium | - | no | yes | PsiCoLeO | medium | - | no | yes | Zer0Tolerance | high | - | yes | yes | Graf chokolo | low | yes | no | yes | Mathieulh | high | - | no | yes | Nikitis | medium | - | no | yes | CrashSerious | medium | - | no | yes |
Sandungas (talk) 06:23, 25 March 2023 (CET)
I will make a new list for everyone available to share my suggestions and everyone is welcome for their feedback. My main goals are:
- Remove both inactive users from higher roles together with active users having higher roles but not using them at all (because they have a "big name" or because of a broken CAPTCHA issue on the wiki)
- Every role must have at least two people sharing the same power to avoid vandalism or other bad stuff disturbing the integrity of the wiki and its content.
- New roles:
- "VIP" for former Team members not active anymore for several years
- "automoderated" doesn't need to get moderated within their changes
- "interface-admin" editing the structure within the wikis
- "moderator" can confirm or reject edits from all other users without having higher roles ("users" / "autoconfirmed users" and "all" [unregistered users])
- "suppress" oversighting all internal actions within the wikis from all user groups
- "trusted" for well-known people from the scene so you can be sure that reading his/her edits are legit
If everything will work, the wiki will have the following higher roles in particular order from the least power to the most:
- "all" (unregistered users)
- "users" / "autoconfirmed users"
- ---------------------------------
- "automoderated" NEW
- "trusted" / "VIP" NEW
- "moderators" NEW if you have higher roles right now and you feel you can "moderate" the wiki, feel free to ask for access
- "administrators"
- "checkuser"
- "bot" / "interface-admin" NEW
- "suppress" NEW
- "bureaucrats"
I'll leave it up to you two to decide who gets what permissions since I don't have the historical context. But I would suggest that we remove the following roles and just wrap up all higher permissions into "trusted", "moderator", and "administrator". Moderators and Administrators are both trusted, and Administrators are also moderators.
- "checkuser" - Not really needed since all edits go to the moderation queue first anyway and unregistered users can make edits
- "Interface-Admin" - This was automatically created when updating MediaWiki. We should just give those rights to Administrators.
- "suppress" - Can just give those rights to moderators.
- "bureaucrats" - Can just give those rights to Administrators.
- "automoderated" - I created the Trusted users group to fill this role. Not sure if this one was auto-created.
Derf (talk) 16:41, 25 March 2023 (CET)
Sorry but I have to disagree to this one.
- I use "checkuser" from time to time, especially when to combat spam (see logs).
- "Interface-Admin" I was planned to reserve this only to you and CrunchBite.
- "suppress", we need something higher than "Moderator" since Moderators can make mistakes and need control as well
- "bureaucrats" actually the most important one and this must stay (!) because it can give roles (this is why I mentioned it in my list as the highest one of all).
- "automoderated" I like it because I see it as a step in between for getting "trusted".
Derf there is some plan to update the mediawiki software we are currently using (v1.35.2 EOL september 2023) to the latest stable (v1.39.2 EOL november 2025) ?. It looks we are at a good timing to update it
Im asking because the default user groups in v1.35.2 (line 5543) and v1.39.2 (line 7609) are way different, is actually a different file (DefaultSettings.php has been deprecated). In the documentation is mentioned to dont add any custom edit in it because the edits will be deleted everytime you update mediawiki software, so im wondering if there is some custom edit in the DefaultSettings.php we are currently using, in that case this is a problem to consider now because soon or later it will be needed to update the mediawiki software and (if needed) that custom edits needs to be taken to the new version, can you make a comparison in between the file i linked and the file in our server and tell me if there is some custom edit in it added along the years ?. In theory all the custom edits should be made in LocalSettings.php
Overall im in a similar oppinion than derf, is better to simplify it and make some groups inherit the rights from other groups as most as possible (ie: group A have the rights of group B + C + some rights specific for A). If we design this hierarchy considering there is going to be always someone active in every group is not going to work, because the most probable thing that will happen is there are going to be only a few people active (ie: if we enable a right specifically for a group but nobody from that group is active then nobody will do it), the inherited rights is the best way to prevent this with the syntax explained here, by ab/using of the array_merge in the $wgGroupPermissions
sections of LocalSettings.php
Im trying to figure how is generated the content of the Special:ListGroupRights page (i guess dinamically by reading both DefaultSettings.php and LocalSettings.php but the way how is displayed in the public page is very confusing, there are lot of repetitions
- In my eyes it's a bad idea because it will actually bring the problem you described. Before we had 10 "Bureaucrats" but only 1 was active, which was my humble self. - Roxanne
- I dont get your argument, and i dont see how reducing the number of members of a team could help, lets use your example, there was 10 "Bureaucrats" but only 1 was active... but additionally there was more than 10 people with admin rights, so in total the potential number of people that could help you was more than 20, if you remove the rights to some of them the result would be the same (only 1 person active) but your hopes to be helped would be more scarceSandungas (talk) 13:53, 26 March 2023 (CEST)
- This calculation is flawed because I gave so many people "Administrator" rights because the CAPTCHA was broken when inserting http links into the wiki. Both "Administrators" and "Bureaucrats" had over 10 people but maybe one or two were actually doing its duties. Now we are repeating the same mistake when we give everyone "Administrator" rights and we reduce the user roles so harsh as Derf now did.
- What i meant is in the scenrario you are describing (only 1 person active) the user rights configuration was not a solution (and was not the problem either), it doesnt matters if there was 10 or 10000 persons with the rights because the result would be the same, and reducing that number is not going to help either, if you are thinking in increasing the wiki exigence level for some kind of motivational boost, well, maybe that works in PS4 or PS5 wikis that are more active but in the PS3 wiki probably we are not going to be able to recruit a team big enought (and active enought) to fill all the roles--Sandungas (talk) 06:01, 27 March 2023 (CEST)
- PS3 Wiki is stable enough to run with a small group of people with higher roles. I'm not here for the fame. --- Roxanne
- Sorry, i was not meaning a motivational boost to you, but to the person requesting the role, lets say... if we design this hierarchy in a complicated way and we give specific and powerful tools to every role, the persons joining this roles will feel a bigger responsability because his duties are very clear and everybody expects that person to do it frequently, this motivational tactic could work in a organization with lot of active people (maybe in PS4 or PS5 wikis) but in ps3 wiki probably will not work, this is why i think is better to simplify it a bit: i agree that previously was too much simplifyed (admin rights for everyone) but we need to find the medium term--Sandungas (talk) 11:08, 27 March 2023 (CEST)
- Due to all respect sandungas but this is the key point which was failing before and it will fail again. If we give people specific User roles with its specific power, then we can also expect them to do their duties !!! In the past people gave them higher roles only because they have a "big name" in the scene. My table below shows that great example where people had even Bureaucrat rights but had absolutely 0 contributions to the wiki. In fact I feel confirmed again because the new Moderation tool shows that there is interest for several people. I was even surprised by myself to see some people doing the Moderation where I didn't expected it at all but in a positive way. Therefore I listed them as "Moderators" in my table as well. So for me the system is working for the very first time on this god damn wiki. If you need a confirmation, you can check the Logfile from the Moderation tool! --- Roxanne
- Sorry, i was not meaning a motivational boost to you, but to the person requesting the role, lets say... if we design this hierarchy in a complicated way and we give specific and powerful tools to every role, the persons joining this roles will feel a bigger responsability because his duties are very clear and everybody expects that person to do it frequently, this motivational tactic could work in a organization with lot of active people (maybe in PS4 or PS5 wikis) but in ps3 wiki probably will not work, this is why i think is better to simplify it a bit: i agree that previously was too much simplifyed (admin rights for everyone) but we need to find the medium term--Sandungas (talk) 11:08, 27 March 2023 (CEST)
- PS3 Wiki is stable enough to run with a small group of people with higher roles. I'm not here for the fame. --- Roxanne
- What i meant is in the scenrario you are describing (only 1 person active) the user rights configuration was not a solution (and was not the problem either), it doesnt matters if there was 10 or 10000 persons with the rights because the result would be the same, and reducing that number is not going to help either, if you are thinking in increasing the wiki exigence level for some kind of motivational boost, well, maybe that works in PS4 or PS5 wikis that are more active but in the PS3 wiki probably we are not going to be able to recruit a team big enought (and active enought) to fill all the roles--Sandungas (talk) 06:01, 27 March 2023 (CEST)
- This calculation is flawed because I gave so many people "Administrator" rights because the CAPTCHA was broken when inserting http links into the wiki. Both "Administrators" and "Bureaucrats" had over 10 people but maybe one or two were actually doing its duties. Now we are repeating the same mistake when we give everyone "Administrator" rights and we reduce the user roles so harsh as Derf now did.
- I dont get your argument, and i dont see how reducing the number of members of a team could help, lets use your example, there was 10 "Bureaucrats" but only 1 was active... but additionally there was more than 10 people with admin rights, so in total the potential number of people that could help you was more than 20, if you remove the rights to some of them the result would be the same (only 1 person active) but your hopes to be helped would be more scarceSandungas (talk) 13:53, 26 March 2023 (CEST)
Im used to change the page protection levels because i had to do it several times before, but for me the setting related with the "Autoconfirmed users" was always a mistery, i never used it and i dont remember any of you using it either, and the name itself when displayed next to the nick in the "recent changes" log was an unneeded annoyance, but now that i was learning how it works im starting liking it because the fact that is given based on a edit counter is a feature, and is pretty much the same roxanne was trying to do with the new custom "auto-moderated" group, so im wondering if we really need the "auto-moderated" group, dont you think is better to stick to the defaut settings ?, we just need to configure the counter (lets say 25 edits) and configure all the wiki pages with the "allow only autoconfirmed users" by default. There is some way to change the protection level of all wiki pages in a hit ? (doing it individually page by page is overkill, lol) BAD IDEA, INCREASING THE PROTECTION LEVEL OF ALL WIKI PAGES IS TOO MUCH RESTRICTIVE
- Absolutely, we plan to update to the current stable MediaWiki. We're trying to find time to do some heavy backend work to put all the wikis under one MediaWiki (so we'd have one wiki to update rather than eight) and also combine user tables so that you only need one account. I updated them all to the same 1.35 version to prep for that. I never used DefaultSettings.php, only LocalSettings.php. Derf (talk) 21:51, 26 March 2023 (CEST)
The CheckUser extension is fine and is not conflictive at all, i used it a couple of times too, roxanne, if you acept a suggestion i think there is no need to give so many explanations in the description because is pretty much the same feature available to all the moderators in 99.9% of the forum softwares, my only complain about the current setup is this feature needs to be made available to all moderators (or higher ranks) because all we are fighting against trolls and spammers, there are currently only 8 members in the checkuser group but it needs to be enabled for most/all the people we mentioned in the user lists we published in the last couple of days in this talk page
Sandungas (talk) 07:52, 26 March 2023 (CEST)
- Derf now merged the "Checkuser" into "Bureaucrats" after I suggested him to do so because the scenario you described was far from reality. First I want to see who is really taking care about SPAM and you will hate me now for this when I say that for the last 5 years or so, none of the "now so called" "Moderators" or other "Administrators" and "Bureaucrats" did as much as I did. I took also your input in our DM and as I understood you correctly, you have no time and/or not interested in combating SPAM, so not sure why I should follow your suggestion, sorry.
- You misunderstood me, what i told you is i dont like the Moderation extension (for anyone, not just me) because 1) it makes wiki more restrictive, 2) it requires our time to supervise edits, and 3) the person approving the edit is partially responsible of what the other person published. I could change my mind eventually but by now i still dont like the moderation extension. you simply think i dont want to fight agains spam, but the logic is not that way, i want to fight spam in the same way we was doing it since years ago but without the moderation extension, also derf have said the chaptcha extensions are working fine again so hopefully we are not going to fall in the problem that happened years ago when only you was active and without captcha protection--Sandungas (talk) 05:12, 27 March 2023 (CEST)
- I don't like that we give Accounts - which were inactive for over >12.5 years - higher roles but I said okay sandungas, as you wish. I also don't like the recent changes made by Derf, especially when I got told that I'm responsible for user roles and at the end it get changed twice anyway. So what now? When I will see my input is going into action? --- User:Roxanne
- You can remove any roles you don't want - you don't have to be responsible for anything you don't want to be. I just made the changes I thought were good and am getting your feedback. When you are satisfied with the chart on this page, I can make the actual roles match. I don't think the Moderation extension makes the wiki more restrictive - they can continue editing the page and seeing their edits on their end until it's pushed live. While it is a system that requires people to check it (I check ConsoleMods' a couple times a day), it lets us prevent spam and vandalism rather than react to it. But if everyone hates it, we can remove it. At the end of the day, I want to make the experience better for everyone! Derf (talk) 03:48, 28 March 2023 (CEST)
- I don't like that we give Accounts - which were inactive for over >12.5 years - higher roles but I said okay sandungas, as you wish. I also don't like the recent changes made by Derf, especially when I got told that I'm responsible for user roles and at the end it get changed twice anyway. So what now? When I will see my input is going into action? --- User:Roxanne
- Just for clarity, now that Captcha is fixed and the Moderation extension is running, there shouldn't be any spam getting through and should be less spam accounts. Since VPNs are now very common, blocking IPs doesn't help as much as it did 10 years ago. Derf (talk) 21:51, 26 March 2023 (CEST)
- You misunderstood me, what i told you is i dont like the Moderation extension (for anyone, not just me) because 1) it makes wiki more restrictive, 2) it requires our time to supervise edits, and 3) the person approving the edit is partially responsible of what the other person published. I could change my mind eventually but by now i still dont like the moderation extension. you simply think i dont want to fight agains spam, but the logic is not that way, i want to fight spam in the same way we was doing it since years ago but without the moderation extension, also derf have said the chaptcha extensions are working fine again so hopefully we are not going to fall in the problem that happened years ago when only you was active and without captcha protection--Sandungas (talk) 05:12, 27 March 2023 (CEST)
Roxanne's suggestions
User Name | Users | Auto-Moderated | Trusted | VIP | Moderators | Administrators | Bots | Bureaucrats | Notes |
---|---|---|---|---|---|---|---|---|---|
Admin | No | No | No | No | No | No | No | No | Maybe defyboy can handover his credentials (kinda as a backup), otherwise I suggest to remove it and protecting the words "Admin" and "Administrator" for any user creation. |
Agrippa (PS3) | Yes | Yes | Yes | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki. "Trusted" because he/she is still an active user. |
Anon | Yes | No | No | Yes | No | No | No | No | Last contribution over 9.5 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
Anon Cypher (PS3) | Yes | Yes | No | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki (but being inactive for nearly two years). |
CelesteBlue | Yes | No | Yes | No | Yes | Yes | No | No | "Trusted" because of his contribution to the scene, especially for PSVita. "Moderator" because he showed activity within the newest Moderation Logfile. "Administrator" because of combating SPAM in the past. |
CrashSerious | Yes | No | No | Yes | No | No | No | No | Last contribution over 12.5 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
CrunchBite | Yes | No | Yes | No | Yes | Yes | No | Yes | As changed within March 23rd by Derf. |
Defyboy | Yes | No | No | Yes | No | No | No | No | As suggested changed by Derf. |
Derf | Yes | No | Yes | No | Yes | Yes | No | Yes | As changed within March 23rd by Derf. |
Developer Jeff (PS3) | Yes | Yes | No | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki (but being inactive for nearly two years). |
Euss | Yes | No | No | Yes | No | No | No | No | As much as it would hurt my heart but I think we can't expect returning him, so I suggest to remove all higher roles here s well and turning him into "VIP". |
Eussbot | Yes | No | No | Yes | No | No | No | No | Same as User "Euss" because there is content on its Talk page. |
Flatz | Yes | No | No | Yes | No | No | No | No | Last contribution over 7.5 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
Glevand | Yes | No | No | Yes | No | No | No | No | Last contribution over 9.5 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
Graf chokolo (PS3) | Yes | No | No | Yes | No | No | No | No | Last contribution over 12 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
GregoryRasputin | Yes | No | Yes | Yes | No | No | No | No | Special:Permalink/62174 |
Idc (PS4) | Yes | Yes | No | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki (but being inactive for nearly two years). |
IntelMiner (PS3) | Yes | No | No | Yes | No | No | No | No | Last contribution over 12 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
Kakaroto | Yes | No | No | Yes | No | No | No | No | Last contribution over 7.5 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
Kozarovv | Yes | No | Yes | No | Yes | Yes | No | No | "Trusted" because of his contribution to the scene, especially for the PS2. "Moderator" because he showed activity within the newest Moderation Logfile. "Administrator" because of combating SPAM in the past. |
M4j0r | Yes | Yes | Yes | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki. "Trusted" because he/she is still an active user. |
MikeM64 | No | No | No | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki, but created another user because the Password Recovery wasn't working. |
MikeM6464 | Yes | Yes | No | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki (but being inactive for nearly two years). |
Mrjaredbeta (PS3) | Yes | Yes | Yes | No | No | No | No | No | Admin role was given by sandungas to match the same rights than Agrippa because both was doing manteinance and moderation tasks in the PS2 compatibility list |
MrMario2011 (PS4) | Yes | Yes | No | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki (but being inactive for nearly two years). |
Mysis | Yes | Yes | Yes | No | No | Yes | No | No | "Administrator" because of combating SPAM in the past. |
Naehrwert | Yes | No | No | Yes | No | No | No | No | Last contribution over 9.5 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
Nagato (PS4) | Yes | Yes | No | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki (but being inactive for nearly two years). |
Nas plugi | Yes | No | No | Yes | No | No | No | No | Last contribution over 9.5 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
Niinono (PS3) | Yes | Yes | No | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki. "Auto-Moderated" only because being a new user. |
Octopus | Yes | No | No | Yes | No | No | No | No | Last contribution over 9.5 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
Okawayati | Yes | Yes | Yes | No | Yes | No | No | No | "Moderator" because showing activity within the Moderation Logfile on PS4 wiki. |
PsiCoLeO | Yes | No | No | Yes | No | No | No | No | Last contribution over 11 years ago (!!!) so I suggest to remove all higher roles and turning him into "VIP". |
Roxanne | Yes | No | Yes | No | Yes | Yes | No | Yes | As changed within March 21st by my humble self. |
Sampleuser | No | No | No | No | No | No | No | No | As far as I can remember, this was only created by "Euss" to test some things, so I suggest to remove this user at all (or maybe protecting that name like for "Admin"). |
Sandungas | Yes | No | Yes | No | Yes | Yes | No | Yes | As far as I understood him correctly, he has no interest into "Moderation". |
Stayhye (PS4) | Yes | Yes | Yes | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki. "Trusted" because he/she is still an active user. |
XDPx | Yes | Yes | No | No | No | No | No | No | Admin role was only giving by Roxanne before because of the non-working CAPTCHA when trying to add http:// Hyperlinks onto the wiki (but being inactive for nearly two years). |
Zecoxao | Yes | Yes | Yes | No | Yes | No | No | No | "Moderator" because showing activity within the Moderation Logfile on PS4 wiki. |
Zer0Tolerance (PS3) | Yes | No | Yes | No | Yes | Yes | No | No | "Trusted" because of his contribution to the scene. "Moderator" because he showed activity within the newest Moderation Logfile. "Administrator" because of combating SPAM in the past. |
- Notes
- The user group named * (asterisk in DefaultSettings.php) have a comment saying
// Implicit group for all visitors
. In other words, this are the rights for wiki readers without a registered acount, and/or registered users while logged-off. This is called as "all" on the Special:ListGroupRights
- The user group named * (asterisk in DefaultSettings.php) have a comment saying
Simple Users
All the registered accounts are given the "User" rights automatically. Are included in the table above because of the case for User:Admin, User:MikeM64, and User:Sampleuser
- But whats the point of removing the user rights to User:Admin and User:MikeM64 ?, the permissions granted to a simple user are the kind of thing that could be inherited by all the other higher ranks--Sandungas (talk) 04:33, 27 March 2023 (CEST)
- Are they active? What about their old passwords no one can restore and was mentioned by Derf as a high risk ??? --- Roxanne
- Got it, so the only reason why you are representing them in your table is because are related with 3 problematic accounts, right ?. Well not sure whats the best solution, is just while trying to figure how to organize all this hierarchy im looking at your table latelly a lot and that column for "user" looks a bit weird, i guess is mostly a reminder to decide what to do with that 3 accounts--Sandungas (talk) 10:29, 27 March 2023 (CEST)
- Are they active? What about their old passwords no one can restore and was mentioned by Derf as a high risk ??? --- Roxanne
- I see two possibilities for User:Admin. I told already Derf before on Discord that maybe he can talk to defyboy to get his credentials so Derf and CrunchBite can use it for their purpose since they are the "Admins" now. If defyboy declines this request, then I suggest to delete it (or rename it to "defyboy" or whatever) because I find it stupid that we have now two new Admins and there is still this old User account. This is why I have put the {{?}} to the table with the "User" collumn since if we go for option 2, then this would mean to delete/rename it.--- User:Roxanne
- I just renamed User:Admin to User:Defyboy and blocked the names "Admin" and "Administrator" from being registered. We don't have any use for the account, as any Administrator has the same permissions to the site, and the Derf/Crunch specific rights to the backend are in a totally different username system. We can cross the "bot" bridge when someone has a bot they want to use. We can leave MikeM64 and Sampleuser in the state they are now (no roles), no issue there. Derf (talk) 03:48, 28 March 2023 (CEST)
- It seems when you renamed the account mediawiki created 2 page #REDIRECT's (i guess needs to be deleted), see: User:Admin and User_talk:Admin --Sandungas (talk) 09:43, 29 March 2023 (CEST)
- I just renamed User:Admin to User:Defyboy and blocked the names "Admin" and "Administrator" from being registered. We don't have any use for the account, as any Administrator has the same permissions to the site, and the Derf/Crunch specific rights to the backend are in a totally different username system. We can cross the "bot" bridge when someone has a bot they want to use. We can leave MikeM64 and Sampleuser in the state they are now (no roles), no issue there. Derf (talk) 03:48, 28 March 2023 (CEST)
- For User:MikeM64, it was his request who contacted me via Discord to get a new account here on Twitter because he can't remember his password and as far as I remember, the "Password recovery option" was (or even still is) broken (I know he tried it but it failed). This is why I created this "new" account for him (User:MikeM6464 and gave him Admin rights because of the broken CAPTCHA before like with many others. Therefore again I used the {{?}} again because we can all highly doubt that he will ever be able to recover his old account again, not only to mention that he is again inactive here for over two years with his new account.--- User:Roxanne
- A nice fix would be to merge User:MikeM64 with User:MikeM6464, or some way to "reassign" MikeM64 edits to MikeM6464, someone knows if is posible to do this ?--Sandungas (talk) 08:37, 29 March 2023 (CEST)
- There's the UserMerge extension. I'll give that a go soon; I'm going to need to get familiar with it anyways for handling user conflicts when merging the user tables for all the wikis anyway. Derf (talk) 05:57, 30 March 2023 (CEST)
- Nice, in the past it was neeed something like this, there are some more accounts that worths to be merged (zecoxao have a couple). We need to wait because the extension is only compatible since >= 1.37.0 so add it at the end of your todo list (after the mediawiki update to 1.39+), in the meantime i guess we can consider is a problem solved--Sandungas (talk) 09:16, 30 March 2023 (CEST)
- There's the UserMerge extension. I'll give that a go soon; I'm going to need to get familiar with it anyways for handling user conflicts when merging the user tables for all the wikis anyway. Derf (talk) 05:57, 30 March 2023 (CEST)
- A nice fix would be to merge User:MikeM64 with User:MikeM6464, or some way to "reassign" MikeM64 edits to MikeM6464, someone knows if is posible to do this ?--Sandungas (talk) 08:37, 29 March 2023 (CEST)
- For this account User:Sampleuser, no one can be for sure why User:Euss created it. As far as I can remember from some old IRC talks (back when I wasn't banned there on this misogynist channel) that he created it for testing tasks for the Bot role (see my old table where it had Bot rights before). My assumption is that he created it as a Backup but as said before, no one knows. So I thought as mentioned in my table, like for User:Admin, either delete it or rename it and protect the name etc. I think to delete it is the better option since we agreed not to use the Bot role only on behalf anyway. --- User:Roxanne
- It doesnt have any edit so doesnt matters much, we could delete it, or restore the user rights and forget about it. The existence of an account with that name is not much problematic (i can imagine a few more names that could be as much confusing, as "Sample", "Webmaster", "UserAdmin", "Adminuser", etc...) we could blacklist all this examples but is not posible to prevent all weird names because the jokers/trolls are very creative :D --Sandungas (talk) 08:37, 29 March 2023 (CEST)
Autoconfirmed users
- In mediawiki v1.35.x the "Autoconfirmed users" have a comment saying
// Implicit group for accounts that pass $wgAutoConfirmAge
. See: AutoConfirmAge and AutoConfirmCount. Is a temporal restriction for new user accounts that have less edits than the value given to the counter. When the counter is reached the user enters automatically into the "autoconfirmed" group and is given the "editsemiprotected" permission that allows toEdit pages protected as "Allow only autoconfirmed users"
(you know, is an special page protection mode available in the tab at top-right of most wiki pages: More -> Protect -> Settings), so it seems we dont need it (or we could repurpose/rename it). The problem is... this group is included in the DefaultSettings.php mediawiki installation and the documentation suggest to dont modify that file, but i guess there must be some way to disable or modify it without need to modify the problematic file (blacklisting or overriding it in LocalSettings.php ?)--Sandungas (talk) 10:29, 27 March 2023 (CEST)- It seems Derf was able to remove it successfully.--- Roxanne
- Weirdly that group is created even though $wgAutoConfirmAge nor $wgAutoConfirmCount weren't setup. I removed them both via LocalSettings.php with:
- unset( $wgGroupPermissions['interface-admin'] );
- unset( $wgGroupPermissions['suppress'] );
- unset( $wgGroupPermissions['autoconfirmed'] );
- $wgExtensionFunctions[] = function() {
- unset( $GLOBALS['wgGroupPermissions']['checkuser'] );
- unset( $GLOBALS['wgGroupPermissions']['autoconfirmed'] );
- };
- Weirdly that group is created even though $wgAutoConfirmAge nor $wgAutoConfirmCount weren't setup. I removed them both via LocalSettings.php with:
- It seems Derf was able to remove it successfully.--- Roxanne
- If the autoconfirmed group is going to be removed then is also needed to remove the option "Allow only autoconfirmed users" in the page protection available modes (the tab at top-right of most wiki pages: More -> Protect -> Settings)--Sandungas (talk) 03:34, 27 March 2023 (CEST)
Bots talk
- The purpose of the bots group is to hide its edit logs automatically, a bot can be used by high group levels (admins or close to admins) to edit pages massivelly, in the past eussNL used bots to perform hundreds (or thousands) of edits but nowaday nobody uses bots so nobody have the bot rights, anyway, the bot rights needs to be ready to be given to any user with high rights incase is requested (only to users that knows wtf are they doing, keep in mind a mistake performed by a bot could cause massive damages)--Sandungas (talk) 10:07, 27 March 2023 (CEST)
- Either Derf is changing that "Administrators" can give themselve the "Bot" role (like it is standard for the now removed "Checkuser" role) or we remove it at all (I prefer the latter one). This is a perfect example why we should had kept some roles instead of merging it such as for "Interface-Admin". In my earlier draft I even removed my checkbox for that role for my humble self because I already know I will break the wiki when tinkering with MediaWiki.css so as you asked, who can handle the Bot ??? --- Roxanne
- I've never had a need to use a bot so far, since most automated things (mass importing files or pages) can be done via the backend. The "Bot" role should be reserved for dedicated bot accounts, if we ever needed one. Adding the bot role to yourself isn't recommended since it excludes you from contribution counts and probably other stuff. Derf (talk) 21:51, 26 March 2023 (CEST)
- Agreeing with that. Also afaik as I remember, Euss used this role from the server-side outside of the wiki, mostly to combat spam or to make automatic edits within his own Talk Page. --- Roxanne
- I agree the bot rights should be given only to accounts that are going to be managed 100% by the bot because all the edits of that account are going to be hidden in the logs. The best practice example of how to play around with bots is pretty much what User:Euss did, if someone is configuring a bot for first time then it can be made with any account (there is no need to request bot rights) but only temporally and for the tests, mostly because you are not sure if your bot is going to work as desired, but after the bot is configured and ready to be deployed is needed to create a new account dedicated for the bot, either by using our nick with the prefix or suffix bot (ie: User:Eussbot) or by giving the account a name specific for his task (ie: the idea i had about a bot intended to update the PS1/PS2/PSP compatibility counters every 24 hours could be named CompatListsCountUpdater), in this example the point is we dont want this kind of bot flooding the "recent changes" page with 3 edits every day, is better to hide the bot edits--Sandungas (talk) 10:07, 27 March 2023 (CEST)
- Agreeing with that. Also afaik as I remember, Euss used this role from the server-side outside of the wiki, mostly to combat spam or to make automatic edits within his own Talk Page. --- Roxanne
- I've never had a need to use a bot so far, since most automated things (mass importing files or pages) can be done via the backend. The "Bot" role should be reserved for dedicated bot accounts, if we ever needed one. Adding the bot role to yourself isn't recommended since it excludes you from contribution counts and probably other stuff. Derf (talk) 21:51, 26 March 2023 (CEST)
- Either Derf is changing that "Administrators" can give themselve the "Bot" role (like it is standard for the now removed "Checkuser" role) or we remove it at all (I prefer the latter one). This is a perfect example why we should had kept some roles instead of merging it such as for "Interface-Admin". In my earlier draft I even removed my checkbox for that role for my humble self because I already know I will break the wiki when tinkering with MediaWiki.css so as you asked, who can handle the Bot ??? --- Roxanne
- I think you can use the Extension "ParserFunctions" (which is installed) to automatically count those totals by adding the keyword to increment a counter in the templates (e.g. in `class="compatibility-tag"style="background:#9d9;color:#05b;box-shadow:2px 4px 6px hsla(0,0%,99%,.5)inset,-2px -4px 6px rgba(0,0,0,.2)inset"data-sort-value="1"title="Works perfect without any noticeable error."|Playable`) so when it renders on the page, each template loaded will increase the correct counter. I haven't really messed with that extension though. Derf (talk) 03:31, 27 March 2023 (CEST)
- I really tryed hard to do it with the "ParserFunctions" extension, but sadly is not powerful enought, the procedure to update the counter involves reading the compatibility list in "raw" (by clicking edit in the whole page, or MediaWiki Action API, parse or query) and using string search functions over text to find how many times is repeated every {{tag}} (and after that updating the other "template counter"). The "ParserFunctions" extension have a function named "ifeq" intended to work with text strings but it cant be used with the content of a page, as far i remember it can be used with page names/titles, but not with his content. Anyway im sure this kind of bot can be made with a 20$ router running OpenWRT and a couple of weeks of experiments :D (so eventually someone could do somthing similar), also when i was investigating all this i could not count with defyboy help so it was imposible to deploy this kind of bot at the server level, but now that you and crunchbite are active we can do some experiments with it later, it requires some time to search in google how other wikis are doing this kind of services--Sandungas (talk) 06:35, 27 March 2023 (CEST)
- Why not using this one? --> https://en.wikipedia.org/wiki/Template:Table_row_counter --- Roxanne
- Hmmm, we need to count templates (not table rows) so it can't be used to update the compatibility counters. I guess it could be used to add a new counter at top of the compatibility list to tell how many games are in the page though (buut im not sure if is going to be able to do the correct maths of the total sum of table # + table A + table B + table C etc... up to table Z, remember we have that wikitables "splitted" in a bit special way for simplification purposes)--Sandungas (talk) 10:03, 27 March 2023 (CEST)
- Why not using this one? --> https://en.wikipedia.org/wiki/Template:Table_row_counter --- Roxanne
- I really tryed hard to do it with the "ParserFunctions" extension, but sadly is not powerful enought, the procedure to update the counter involves reading the compatibility list in "raw" (by clicking edit in the whole page, or MediaWiki Action API, parse or query) and using string search functions over text to find how many times is repeated every {{tag}} (and after that updating the other "template counter"). The "ParserFunctions" extension have a function named "ifeq" intended to work with text strings but it cant be used with the content of a page, as far i remember it can be used with page names/titles, but not with his content. Anyway im sure this kind of bot can be made with a 20$ router running OpenWRT and a couple of weeks of experiments :D (so eventually someone could do somthing similar), also when i was investigating all this i could not count with defyboy help so it was imposible to deploy this kind of bot at the server level, but now that you and crunchbite are active we can do some experiments with it later, it requires some time to search in google how other wikis are doing this kind of services--Sandungas (talk) 06:35, 27 March 2023 (CEST)
Highlightable numbered lists
This is a feature I made for ConsoleMods. Would you like it here as well? I thought about it because it'd be nice to mark off the chat as you read on this page :)
- Example page: https://consolemods.org/wiki/Test2
03:42, 27 March 2023 (CEST)
- Not sure whats the best solution but yeah this kind of "nested" talks are a bit chaotic and restricted to 5 or 6 levels as most, the last time i was looking for it i found StructuredDiscussions extension that seems to be good enought visually but im not sure if is going to be good enought practically, it needs to be intuitive enought for everyone to start using it without problems or annoyances, otherway if is a pita to use it everybody is going to ignore it--Sandungas (talk) 04:11, 27 March 2023 (CEST)
- Oh wow, that's a really cool extension. Looks like it requires a schema update, so it would be best to wait until after the final MediaWiki upgrade. I've added it to the todo list. If you think the highlightable list tweak would also be nice to have, I can add that too. Derf (talk) 03:48, 28 March 2023 (CEST)
- I been reading about the StructuredDiscussions and it have some problems, is abandoned, there is some people telling it have bugs, and (most important) i found a comment telling that "is not easy to uninstall", not sure what they means with that but it makes me a bit afraid it could break somehing. Btw take a look at the list of extensions bundled in the modern versions of mediawiki (bigger than the current 1.35.2 we are using). There is a DiscussionTools, AbuseFilter, VisualEditor and some more interesting we need to keep in mind from that list, because i guess are going to be installed automatically later, after the update to mediawiki 1.39+ --Sandungas (talk) 07:07, 28 March 2023 (CEST)
- StructuredDiscussions isn't abandoned, they're just not adding features anymore since 2015, only doing maintenance on it and fixing bugs it looks like. They probably say it's hard to uninstall because it actually modifies the schema and database tables, and undoing that would be a pain. I think it'd be worth using since Talk pages are a mess, but I suppose we could see how those DiscussionTools look that are coming in 1.40. I was aware of VisualEditor and was planning on enabling it here (as I did on ConsoleMods), but when I turned it on here it had some issues (known 1.35 bugs), so I'll wait until the update to the latest MediaWiki to try again. Derf (talk) 19:31, 1 April 2023 (CEST)
- I been reading about the StructuredDiscussions and it have some problems, is abandoned, there is some people telling it have bugs, and (most important) i found a comment telling that "is not easy to uninstall", not sure what they means with that but it makes me a bit afraid it could break somehing. Btw take a look at the list of extensions bundled in the modern versions of mediawiki (bigger than the current 1.35.2 we are using). There is a DiscussionTools, AbuseFilter, VisualEditor and some more interesting we need to keep in mind from that list, because i guess are going to be installed automatically later, after the update to mediawiki 1.39+ --Sandungas (talk) 07:07, 28 March 2023 (CEST)
- Oh wow, that's a really cool extension. Looks like it requires a schema update, so it would be best to wait until after the final MediaWiki upgrade. I've added it to the todo list. If you think the highlightable list tweak would also be nice to have, I can add that too. Derf (talk) 03:48, 28 March 2023 (CEST)
Todo List
Made a todo list for myself here: https://www.psdevwiki.com/ps3/Todo_List
Linked in my User page to be easy to find.