Talk:ResourceLoader/Version 2 Design Specification/Worklist for 2011

Previous page history was archived for backup purposes at Talk:ResourceLoader/V2 Task management/2011-12/LQT Archive 1 on 2015-07-10.

It'd be protected/restricted to users with the "gadgets-edit" right (a bit like NS_MEDIAWIKI and editinterface). I'm not quite sure to which group (if any) it should be assigned by default.

Traditionally and due to backwards-compatibility it could be assigned to the sysop-group (that is, in the current system sysops can edit gadgets since they have editinterface and gadget resources are stored in MediaWiki:Gadget-<name>.js).

On the other hand, perhaps we could start a new group, like "js developers" or "gadget artists", something like that (probably needed in the long run anyway).

Question being: Is the average sysop supposed to able to modify gadget resources ? Note that the gadgets-edit user right is not the same as the "gadgets-definition-edit" user right. The latter is for the management of the gadgets through Special:Gadgets (such as toggling "load by default") which is more of a sysop-thing. gadgets-edit would (just) be for editing the gadget resource wiki-pages in the Gadget-namespace.

After a few years without looking into Gadgets 2.0 I was a little confused when I enabled the (new) "gadgets2" role on Vagrant and visited "Special:Gadgets", because there was just a message "This wiki currently has no gadgets defined." with no links or buttons suggesting that a gadget could be created.

I think the extension should provide (by default) a user group with the appropriated user rights to create a gadget, and mention that user group in the message above, linking e.g. to Special:UserRights if the user is a sysop (to allow him to add himself to the group), or to the list of users in the new user group: Special:ListUsers/newgadgetsusergroup.

This post was posted by He7d3r, but signed as Helder.wiki.

Did someone look at the current API?

Yes, and I don't think we have to change a lot there. But to be sure, I've listed it here so that it will not be forgotten. It will probably only need a few small changes to account for the changes in the backend.

The proposal so far plans to have a mw_gadget table in which the current state of things is stored. There is no history and it's not on a wiki page, but in the database. This gives many advantages (hence we choose it). However, all actions are logged.

The down side to this:

1. Either we get very long log messages or some info will simply not be retrievable from the past
2. Hard to revert/undo
3. Impossible to add to watchlist or show a diff

On the other hand, it's not a whole lot different from any of these:

• Block
• Delete
• Protect
• Patrol
• Rollback
• Move

All of these only leave a log-entry with details but not descriptive revision that is revertable or diff-able (they do leave null-revisions in some cases). Although these may not justify a lack, it may be worth considering to just keep the plan the way it was (eg. not creating mw_gadget_revision + all the complications [1].

What do you think: Current-state table with logging ? Or revisioned ? Something else ?

---

1. ↑ complications, or perhaps feature-ideas: history view, diff view, possibly revdel and watchlist