User:Kunalgrover05/AggregateGroups
Changes for Special:AggregateGroups
[edit]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
[edit]- 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
[edit]- 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
[edit]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
[edit]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
[edit]- 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