Bug 465338 - Need way to specify a flag as a release type
Summary: Need way to specify a flag as a release type
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Bugzilla
Classification: Community
Component: Administration
Version: 3.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
: 464605 (view as bug list)
Depends On: 465357
Blocks: 463810
TreeView+ depends on / blocked
 
Reported: 2008-10-02 20:29 UTC by David Lawrence
Modified: 2013-06-24 04:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-28 01:32:43 UTC
Embargoed:


Attachments (Terms of Use)

Description David Lawrence 2008-10-02 20:29:08 UTC
Description of problem:
Need way to take a current flag and specify it as a release related flag for use by other components in Bugzilla such as Release Components and schedule related features.

---- 

From: Kevin Baker <kbaker>
Subject: Re: Code Review - Flagtypes.is_release support and also first try
	object oriented ReleaseComponents.pm

On Tue, Sep 30, 2008 at 05:49:50PM -0400, David Lawrence wrote:
> As if you guys didn't already have enough to do. If you could do a code review 
> of what I have attached and let me know if you see any glaring problems.
> 
> 1. flagtypes_is_release.patch
> 
> Simply adds a new attribute to the flagtypes table that allows us to mark
> a certain flag as a release flag. The UI has a simple checkbox that allows
> an admin to mark a flag as release. This will later be used by other functionality
> such as release components and bugbot features in the future.

My only concern is that we a marrying ourselves close to the bugzilla
data. I'd like to strive to keep it in separate tables. Don't take this
as an order, please discuss.

My motivation is that if we need to pull this out of bugzilla then it
will be easier if we just have to lift out whole tables.

An alternative to keep the release stuff completely separate to vanilla 
bugzilla is to simplhy maintain a pointer to the flagtype id in a 
"release" table.

In order to populate that table another screen may be needed. (Or you
could do it from the flag edit screen but just update the "release"
table.) This screen would list all the available flags
and let the user choose which flags is to be a release flag.

 +--------------------+
 | List all flags     |
 |                    |
 | o rhel-5.2         |
 | x rhel-5.3         |
 | o rhel-4.7         |
 | o rhel-4.8         |
 | x cluster-4.7      |
 | o cluster-4.8      |
 |                    |
 | +----------------+ |
 | | Set as Release | |
 | +----------------+ |
 +--------------------+

"Set as Release", when clicked would add the pointers to the checked
flags; marking them as for release. Also note that you could add a
different description here too, I see are using the flags
description in the release list which doesn't really make sense in the
release context.

TABLES:

rh_release

 +----+--------------+-------------+
 | id | flagtypes.id | description |
 +----+--------------+-------------+

 id           = unique id for a release. independent of bugzilla data
 flagtypes.id = links the release to a bugzilla release flag
 description  = a release description (rather than a flag description)

Comment 1 David Lawrence 2008-10-02 20:39:33 UTC
*** Bug 464605 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.