bugs wrote:

(In reply to comment #0)

So, I was wondering if it would be possible to define "parts" of the gadgets
which would be loaded or not depending on whether the user has a specific right
or not. This way, if a user is able to "patrol" but not to "delete", it could
still use the script, although only the parts which are usable without the
missing rights.

I'm not a JS expert, but I would think you could already do this inside the actual script. The gadget could should be able to pull the "wgUserGroups": ["sysop", "*", "user", "autoconfirmed"] that shows up on all sysop's page loads... or they could just pull something from the API if that doesn't work.

(In reply to comment #1)

I'm not a JS expert, but I would think you could already do this inside the
actual script. The gadget could should be able to pull the "wgUserGroups":
["sysop", "*", "user", "autoconfirmed"] that shows up on all sysop's page
loads... or they could just pull something from the API if that doesn't work.

Yes, but in this case, if the user doesn't have just one of those four rights, the script would not be shown at all on [[Special:Preferences]] because the function isAllowed() checks for the presence of all rights:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Gadgets/Gadgets_body.php?annotate=86211#l312

In other words, although we can indicate that a user isAllowed() if he has (this AND that) rights, we don't have a way to indicate e.g. that he isAllowed() if he has (this OR that) rights.

Per comment #1, I think the best approach is to put the minimal set of restrictions in the gadget definition, and note in the gadget description that the gadget has additional features for those with certain rights.

The gadget author / administrator should put the minimal rights (if any) in the manifest on Gadgets-definition's [rights] block. Any conditional parts can be executed or loaded within the gadget based on the current logged-in user's rights (api meta=userinfo) or group member ships (wgUserGroups)

(In reply to comment #4)

The gadget author / administrator should put the minimal rights (if any) in the
manifest on Gadgets-definition's [rights] block. Any conditional parts can be
executed or loaded within the gadget based on the current logged-in user's
rights (api meta=userinfo) or group member ships (wgUserGroups)

But in that case, if the user doesn't have any of the rights the gadget would not be removed from [[Special:Preferences]] as it should.

The description of the "rights" parameter at gadget documentation is this:
"Makes the gadget visible in preferences only to users who have these privileges."

It is implicit that this is about "users who have ALL these privileges" but the bug is a request to be able to indicate that a user is allowed to see the gadget if he has "AT LEAST ONE OF these privileges" and comment #4 doesn't seems to be a solution for this. Besides, would that load the conditional js pages combined in a single request as happens for parts indicated in

• myGadget[ResourceLoader]|part1.js|part2.js|part3.js

?

CCing [[User:Salvatore Ingala]] since his GSoC 2011 proposal[1] focus on customization of gadgets and user scripts and the the present bug could be considered in that escope because the "visibility of a gadget in the preferences" is an aspect which needs to be customized depending on the gadget. E.g.: tool developers may want some gadgets to be displayed/hidden depending on a logical combination of user rights, such as
(rollback AND delete) OR (patrol AND markbotedits)
Besides, in addition to the idea of "newbie gadgets" mentioned at
https://bugzilla.wikimedia.org/show_bug.cgi?id=13742#c15
some gadgets which are specifically focused on experienced editors should not clutter the interface seen by newbie users. So, in this case an admin could want to hide a gadget unless the user is
(NOT autoconfirmed)
an so on. The extension could provide a field where developers could enter a boolean expression involving the rights needed in order to specify the visibility of the gadget. The current implementation only allow a specific subset of this, namely: (right1 AND right2 AND ... AND rightN).

[1] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/User:Salvatore_Ingala/GSoC_2011_application#Project_summary

salvatore.ingala wrote:

This is actually not very related with my GSoC project, whose scope is to allow gadget developers to export the configuration variables of their gadgets (which are then delivered to user code); this is not related to all those kinds of configurations that currently go in the Gadgets-definition page.

The idea of allowing more complex visibility criteria is nice, but I'm not sure it is worth the effort - how many examples are there of (existing) gadgets where it would be useful?

The some-rights thing (ie. part if you can block, part if you can delete etc.) can probably be achieved by making the gadget more object oriented / modular and splitting it up in multiple modules that can be plugged-in.

ResourceLoader take care of dependancies and make it into a single request without duplicating code.

For example in ResourceLoader2 the following is likely possible:

Gadgets:

• Awesome-core
  • hidden: true
  • scripts: awesome.core.js (MediaWik:Gadget-awesome.core.js)

• Awesome-delete
  • scripts: awesome.delete.js (MediaWiki:Gadget-awesome.delete.js)
  • dependencies: awesome-core
  • rights: delete

• Awesome-block
  • scripts: awesome.block.js (MediaWiki:Gadget-awesome.block.js)
  • dependencies: awesome-core
  • rights: block

Preferences:

• Enable Awesomeness on the Delete-page
• Enable Awesomeness on the Rights-page

-core will only be loaded once, and if one of the modules is enabled.

However "load if one of the following rights" is not possible yet (or planned to), I'm not sure we should though, it makes it hard to make any assumptions about the gadget later on. I think in most cases the above is what you actually want and not "one of the following rights".

related: bug 12211

(In reply to comment #8)

The some-rights thing (ie. part if you can block, part if you can delete etc.)
can probably be achieved by making the gadget more object oriented / modular
and splitting it up in multiple modules that can be plugged-in.

Hmm.. This approach of splitting a gadget into parts and creating different checkboxes preferences for different user rights will probably help.

And about the gadgets for non-newbies, and other more complicated combinations of rights, it seems that the admins can create some code to put on [[MediaWiki:Common.js]] which could show/hide items from [[Special:Preferences]] depending on the values of some variables and user preferences.

I'm re-closing this bug as WORKSFORME since there seems to be other good ways to achieve the same results.

Thank you all!

(In reply to comment #10)

And about the gadgets for non-newbies, and other more complicated combinations
of rights, it seems that the admins can create some code to put on
[[MediaWiki:Common.js]] which could show/hide items from
[[Special:Preferences]] depending on the values of some variables and user
preferences.

This doesn't works anymore, since MediaWiki 1.18 doesn't execute code from [[MediaWiki:Common.js]] on [[Special:Preferences]].