Idea
The "Select group(s)" filter lists every group in the installation. On a Redmine
with many groups — permission groups, partner groups, historical ones — most are
irrelevant for capacity planning, and the list gets long enough that finding the
teams you actually plan for is tedious.
Administrators should be able to decide which groups show up there.
Two ways to do it
A) A group selection in the plugin settings. A multi-select listing all
groups; the chosen ones are excluded from the filter.
Everything stays in one place, no dependency on other Redmine features, easy to
inspect when something looks off. But the stored ids go stale when a group is
deleted, the setting is invisible to whoever creates a group, and the list of
checkboxes grows with the number of groups — the same long-list problem, moved
into the settings page.
B) A boolean group custom field, e.g. "Exclude from workload planning".
Group already calls acts_as_customizable, so GroupCustomField works today.
Configured where the object lives, dies with the group, and scales — one
checkbox per group instead of a list of all of them. The cost is bootstrapping:
the plugin has to know which field to read, either by creating one on install or
by naming it in a setting. And the field appears on the group form for everyone,
including installations that do not care.
Leaning towards B. The scaling argument decides it: A moves the problem
rather than solving it.
Check this first
WlGroupSelection#all_groups uses Group…all rather than Group.givable.
Group is an STI class and its subclasses include GroupNonMember and
GroupAnonymous, so the filter currently offers built-in pseudo groups nobody
can plan for. That is a one-line fix, independent of this feature, and it may
already remove a good part of the noise.
Idea
The "Select group(s)" filter lists every group in the installation. On a Redmine
with many groups — permission groups, partner groups, historical ones — most are
irrelevant for capacity planning, and the list gets long enough that finding the
teams you actually plan for is tedious.
Administrators should be able to decide which groups show up there.
Two ways to do it
A) A group selection in the plugin settings. A multi-select listing all
groups; the chosen ones are excluded from the filter.
Everything stays in one place, no dependency on other Redmine features, easy to
inspect when something looks off. But the stored ids go stale when a group is
deleted, the setting is invisible to whoever creates a group, and the list of
checkboxes grows with the number of groups — the same long-list problem, moved
into the settings page.
B) A boolean group custom field, e.g. "Exclude from workload planning".
Groupalready callsacts_as_customizable, soGroupCustomFieldworks today.Configured where the object lives, dies with the group, and scales — one
checkbox per group instead of a list of all of them. The cost is bootstrapping:
the plugin has to know which field to read, either by creating one on install or
by naming it in a setting. And the field appears on the group form for everyone,
including installations that do not care.
Leaning towards B. The scaling argument decides it: A moves the problem
rather than solving it.
Check this first
WlGroupSelection#all_groupsusesGroup…allrather thanGroup.givable.Groupis an STI class and its subclasses includeGroupNonMemberandGroupAnonymous, so the filter currently offers built-in pseudo groups nobodycan plan for. That is a one-line fix, independent of this feature, and it may
already remove a good part of the noise.