290753 - Enable flagtypes to have different names/descriptions values using the same category selection widget as is used for the flag itself

Status: RESOLVED WONTFIX

(Bugzilla :: Attachments & Requests, enhancement)

Description

[timeless]

bug 290191 among others is asking for a way to transition from 'review' and
'super-review' to 'first-review' and 'second-review'.

As it happens, the current 'review' and 'super-review' flags really aren't that
bad, if i could select new names and descriptions while keeping the same flag
ids (effectively establishing equivalencies) using the category interface, i
wouldn't have to do much transition work.

and when everyone finally transitions to the same set of descriptions, i could
consolidate the names and be happy. the other good thing about such an interface
is that we wouldn't have needed to create 5 different review flags in the first
place, since the first one could just have been branded using this feature.

Comment 1

[Max Kanat-Alexander]

*** This bug has been marked as a duplicate of 290751 ***

Comment 2

[Max Kanat-Alexander]

Oh, mistake. They just looked so similar.

Comment 3

[Max Kanat-Alexander]

Seems like quite a complication for an already complex system. I think there
probably exists a simpler way to solve this problem, although I don't know what
it is right at this moment.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

It may make sense for the details of flags to be product/component-specific. 
Currently, b.m.o creates multiple distinct but identically-named flag types in
order to configure those types for products/components with different needs for
flag multiplicity and other flag attributes.  For example, we have four
different "review" flag types in three distinct configurations.

If the configurations were product/component-specific, we could instead have a
single flag type, and moving bugs between included products/components wouldn't
create the kinds of problems that bug 274802 was designed to fix.

If the flag name itself was configurable, it would take care of bug 290756,
although arguably the name is the basic identifier of a flag type, and we should
require it to be the same across "equivalent" types.

This approach is more complicated than our current system.  But it solves
problems we're currently patching around elsewhere.  Is it easier and better to
create those patches than to implement the complex approach requested here? 
It's unclear, but it's certainly worth considering.

Comment 5

[Frédéric Buclin]

Mostly all bits of flagtypes could differ between components, meaning that it's much easier to clone a flagtype than to implement so much complexity. The existing code already handles flags having the same name across products correctly, so this is no longer a problem.