User:Kunalgrover05/AggregateGroups

Changes for Special:AggregateGroups

These are the fixes that we are aiming at for Special:AggregateGroups

• Allow aggregate group name and group description to be changed on Special:AggregateGroups. - [Bug 36298]
• Make Special:AggregateGroups output a special page when permissions insufficient (bug number?)

Approach/Implementation

• Have an edit button beside the remove button to change the name and description.
• Implement different display forms for the 2 cases with a parameter in the form which displays the optional parts.

Current progress

• Reading up and understanding the code
• Implemented a method in API to change the name and description.
• Implemented UI method to use API
• Bug fixed :)
• Made Special:AggregateGroups read only when user lacks permissions. Merged :)
• Finished first patch for performance improvements in Special:AggregateGroups. Replaced group selector by autocomplete input box.

Performance improvements in Special:AggregateGroups

Working on Special:AggregateGroups performance improvements was kind of a challenging task. The group selector had to be replaced with an autocomplete input box.

Improvement suggested by Nikerabbit. Special:AggregateGroups is too slow when the number of groups is huge. It might be because of so many group selectors.

Try 1  Done

Replace group selector UI with an autocomplete input box for selecting subgroups.

Results: Wiki with 600 groups and 20 pages per group

With old selector Time: 8.06105 Memory: 35.44 MB (Peak: 35.62 MB)

With new selector Time: 4.73612 Memory: 32.44 MB (Peak: 32.62 MB)

Approach

• Made changes in API module to return all translatable pages.
• Now, read all the subgroups in JS and populated the autocomplete.
• It was required to remove the already existent groups from the autocomplete, used Jquery to get the list and populate an array which includes all that had to be excluded.
• Had to use a global array for storing the labels and ids to be able to map easily.

Challenges faced

It breaks the searching groups using aggregate group id. Now multiple groups can have the same name as well. Is it better to create a new group followed by deleting the old one?

Nikerabbit suggested to have the same group id even on updation

This brings this bug into place, suppose a new group is created with a certain name and then the name is changed. We can never again create a group with the same name. Is it better to use the Copy group and delete existing group way?

Implemented this way- keeping the id as NAME1 automatically if the NAME is a valid aggregate group name but not a valid id.

The error part in mw.Api() doesn't work for me.

Solved with Nikerabbit's help. Need to use as mw.Api().fail( function( error_code, data ) );

There was an issue in using $this->dieUsage() and $this->dieUsageMsg()

$this->dieUsage can be used directly but for $this->dieUsageMsg the message needs to be declared already.

Gerrit patches

API

https://gerrit.wikimedia.org/r/#/c/135872 (Merged)

Front end

https://gerrit.wikimedia.org/r/#/c/135874 (Merged)

Read only page

https://gerrit.wikimedia.org/r/#/c/140822/ (Merged)

Performance improvements

https://gerrit.wikimedia.org/r/#/c/142053/ (Merged)