Also I guess you want not to add a new RIGHT but a new USER GROUP. An user group is a group of user which can use specific rights. Rights are defined by mediawiki core, extensions etc. But they can't be defined in configuration. Am I right?

Hi!
We didn't discuss giving bot rights to the group in etwiki, so I think it's better not to give this right to the group. The user group should just have the "tooluse" right.

Urbanecm, we would like both new right and new group. The right can be used in
MediaWiki:Gadgets-definition (for example this example <pre>CategoryMaster[ResourceLoader|rights=delete]|CategoryMaster.js|CategoryMaster.css</pre> uses the right delete for access check). And to use the right, we need a new group with that right. The group that can be assigned to users by admins.

https://www.mediawiki.org/wiki/Manual:User_rights#Adding_new_rights

Yeah, I understand you now. But there is one problem. As the JavaScript is always getable, anyone who will want to use the tool without the right, he can copy the code to Special:MyPage/common.js. Even there will be a condition which doesn't allow running without it he can delete it simply! The rights param should be used only when the right is really needed for runing the tool. I.e. gadget which allows sysops delete pages en masse won't run without delete right in any way. Or gadget which prompts for confirmation before rollback (so you must click the link and hit enter when you want to use it) won't run without rollback right (it will but it won't work because you can't rollback).

Did you discuss this at your wiki?

I am aware that anyone can install any Javascript code and do anything that his rights in wiki allow.
We discussed it year ago (here: https://et.wikipedia.org/wiki/Vikipeedia:%C3%9Cldine_arutelu/Arhiiv_33#Kategooriate_teisaldamise_t.C3.B6.C3.B6riist) and I raised the exact same point.
It is security through obscurity but it is better than nothing. If some user starts to abuse any script, we would block him and deal with him through the usual ways of blocking vandals.
Most users are not technically advanced enough to modify scripts or to understand how to bypass restrictions.

In Bulgarian wiki they use exactly the same tool as we in Estonian wiki (that allows to change categories en masse). They decided to limit the tool use with autopatrol user right. We don't have Autopatrollers user group (and don't need it).
But anyways, it makes no difference from the security standpoint, whether it is standard "autopatrol" or "tooluse" right, as in both cases Javascript code can be copied to user's common.js.

Okay, thanks. Last thing for now, could you write here (or at wiki) English summary of the discussion? Another possibility (for futher requests) is firstly discuss it internally and then vote with graphic symbols so everybody can understand it.

Here is the summary.
I proposed to create Autopatrollers user group in etwiki (along the lines of Bulgarian wiki), and stated that the purpose is to allow administrators to flexibly administer some gadget access rights. Described how admins can add/remove users to/from the group.
User Vihelik said we don't need Autopatrollers group since there are too few users in etwiki. User Andres said we don't need Autopatrollers, and that my question was really about Toolusers group, which he does not oppose. User Toon commented on the word Autopatrullijad (Autopatrollers). User Melilac agreed that there should be a way of giving tool rights to trusted users and not give every user rights to tools that can massively change articles (support). I don't understand what was user Pietade's point, but he didn't oppose or support the proposal.
So the tally is: Andres (bureaucrat) and Melilac (administrator) support the proposal; Vihelik (administrator), Toon (user) and Pietade (user) neither oppose or support.

Smell like another instance of what we're been already seeing with trwiki, trwikiquote (T144638), and ruwiki (T144599) asking for new permissions groups to delegate rights based on classes of editors. Remember that sensitive rights such as editinterface, gadgets-edit, gadgets-definition-edit, editusercss, edituserjs are not to be grantable by sysops . According to w:et:ListGroupRights , so-called "tools" are actually gadgets.

P.S.: Differentiate between what is called a right (right to do certain action), a user group/flag (that can have certain rights combined) and grants (group of rights that are required to allow you to do certain action).

P.P.S.: Proposal of sysops elimination and splitting all sysop rights to classes of editors was already discussed

@Arseny1992 This isn't about editinterface but about new right. When you'll have it, you'll be able to use certains gadgets. So nothing about editintefrace, gadgets-* rights, editusercss or edituserjs isn't applied there.

I know that right, flag and grants are different things and this is really about new right and flag which will has it.

I don't clearly see what would be the usefulness for this, with all respect. Creating an usergroup so people can use certain gadgets looks odd, specially since you can load them yourself via your own .js subpages; making this not useful at all.

@MarcoAurelio The usefulness lies in being able to list certain gadgets under the Preferences > Gadgets where they can be easily installed and yet not have them easily available to all users.
Some gadgets can be abused. For example a gadget that changes hundreds of articles with a couple of clicks. You wouldn't want to have that kind of thing available to some new user, who hasn't yet developed understanding of how some particular aspect (e.g. categories) of Wikipedia works. Such users usually have no clue what a user script is or how to install one. Even most of the experienced users don't know much about user scripts. If we don't make the gadget easily accessible to users, they would not use it. At the same time it is desirable to make it easily accessible to other, experienced users.

Thanks for your comments, but I'm still failing to see the usefullness for this, given that any gadget can be loaded via our personal .js/.css subpages. I'm skeptic that you can achieve the goal intended with this.

I understand that you may want not to show some gadgets in the Preferences but to some users because they won't be able to use them (ie: a deletion gadget isn't useful if your account is not permitted to delete). I'd worry more about malicious users rather than on new users to be sincere. Malicious users with experience will surely know how to circunvent this check.

If you wish some scripts to work only for certain users, I suggest that instead the script be programmed to a) detect if the account that is invocking the script has the "delete", "block", "noratelimit" rights, for example; -or- b) have the script check the username invocking the script against a whitelist of approved users as it happens with enwiki's AutoWikiBrowser.

Of course, any user with experience can copy the gadget to their personal .js subpages, amend it to avoid the username/rights check and use it though (unless the script requires accessing restricted functions such as deletion or blocking).

Regards.

@MarcoAurelio Yes. But if a new group without any additional rights should be used for this how we can help with it other way than creating new right?

Change 319568 had a related patch set uploaded (by Urbanecm):
New user right and user group for et.wikipedia.org

https://gerrit.wikimedia.org/r/319568

@MarcoAurelio Thanks for the comment!

W/ regard to usefulness:
If the goal is true security, then yes, it is useless. It cannot give true security. However, if the goal is weak security (hiding some gadgets, making it difficult to use them for inexperienced users) then it is useful, because it helps to achieve that.

Is the goal of having weak security valid?
As you say, in enwiki they are using this kind of weak security for AutoWikiBrowser. Bulgarian wiki uses existing autopatrol right and Autopatrollers group as a flag for restriction – same type of weak security that can be overcome by copying the affected script(s) into user's common.js. So the goal of having some weak security seems to be valid, otherwise people in enwiki and Bulgarian wiki wouldn't bother with it, they would just make the scripts like AutoWikiBrowser available for everyone.

W/ regard to technical implementation of weak security:
I think that using Wikimedia user group and right is the easiest way to implement user rights checking. Yes, it could be done inside gadget, using whitelists, similar to AutoWikiBrowser. But is is essentially implementing user rights on a script level. The program code needs to be put into each separate script (although the code can probably be reused). Keeping whitelists somewhere in a separate file and updating them (probably manually) is cumbersome and messy.

Checking account rights ("delete", "block", "noratelimit" etc) from the script could be a solution, but our wiki does not have any such rights that separate certain users from all other users. There are basically only administrators and registered users. That's why I first proposed creating Autopatrollers group and right – to have some right that can be used as a flag. But then I thought, why use autopatrol right if the Mediawiki software allows creating any arbitrary right.

What are the downsides of creating a new user right (other than being useless for true security)?

first proposed creating Autopatrollers group and right – to have some right that can be used as a flag. But then I thought, why use autopatrol right if the Mediawiki software allows creating any arbitrary right.

What are the downsides of creating a new user right (other than being useless for true security)?

Consistency across Wikimedia farm. If some wikis already use this (enwiki/bgwiki) based on already existing groups, why to request yet another arbitrary custom group (yet alone also arbitrary right?) specifically for that? Such as with the technican/technician/engineer case, in that pace we'll get up to a point, when every of the 800+ wikis will have arbitrary similar groups and rights (T139246#2425520) and that'll be burden to manage. Frwikinews for example already have trusteduser user group. What's being proposed is to merge any such similar rights for consistency (T144699, T144700).

Custom arbitrary rights are not a good idea for large-scalability in cases of wiki farms.

@Arseny1992 I see. Would it be better if we requested some standard user group like Autopatrollers?

@Cumbril much better. Point the above claim on the local community, and decide which rightset autopatrolled are going to have, if different from default (autopatrol to autopatrol own revisions). Hewiki for example let autopatrollers see Special:UnwatchedPages.

Basically:

• To enable the patrolled revisions system by extension that patroller and autopatrolled imply? Unlike the MediaWiki.org page, the default on Wikimedia is to have it disabled and be enabled by each project individually upon request.
• Who may add and who may remove these groups from users? I.e. to be addable by sysop, but revocable only by bureaucrats or sysops also? Processing/election pages also would be needing to be set up locally for users to request and ask to revoke the group if abused (or that to be done on requests for admin/bureaucrat action page).
• Should users be auto-promoted to autopatrolled after e.g. 1000 edits? (If revoked, shouldn't be auto-added on next edit)

Once consensus reached, file a new task for the change.

Upd:

That's why I first proposed creating Autopatrollers group and right – to have some right that can be used as a flag

So if since its only for that and if that consensus is already reached (you propose to add autopatrollers and enable the patrolled edits system), you can proceed to create new task with answers to the above points. Do not do it in this current same task as a reply / description amendment, because this task is to be referenced here as partial rejection.

Change 319568 abandoned by Urbanecm:
New user right and user group for et.wikipedia.org

Reason:
Probably won't be needed anymore.

https://gerrit.wikimedia.org/r/319568

I opened new discussion in the community. It seems that there is consensus for creating Autopatrollers group in etwiki. Going to wait for a few more days to collect opinions.

Should I open new task for this?

In T149610#2791165, @Cumbril wrote:

I opened new discussion in the community. It seems that there is consensus for creating Autopatrollers group in etwiki. Going to wait for a few more days to collect opinions.

Should I open new task for this?

In T149610#2772449, @Arseny1992 wrote:

Upd:

That's why I first proposed creating Autopatrollers group and right – to have some right that can be used as a flag

So if since its only for that and if that consensus is already reached (you propose to add autopatrollers and enable the patrolled edits system), you can proceed to create new task with answers to the above points. Do not do it in this current same task as a reply / description amendment, because this task is to be referenced here as partial rejection.

Since this task scope is for the toolusers right request, this has to be closed as declined and a ref be posted there.
Each task handles a specific case, do not mix up actions to same task.

If there is consensus for autopatrolled handling all the points I described in the previous message, after waiting for the opinions do a new task explicitly answering those points and then we'll process it ;)

@Cumbril Please fill me (Urbanecm) to the new task as Assigned, I'm going to create a patch...

@Urbanecm OK, just need to wait a day or two.