Bug 465338
| Summary: | Need way to specify a flag as a release type | ||
|---|---|---|---|
| Product: | [Community] Bugzilla | Reporter: | David Lawrence <dkl> |
| Component: | Administration | Assignee: | David Lawrence <dkl> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.2 | CC: | kbaker |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-10-28 01:32:43 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 465357 | ||
| Bug Blocks: | 463810 | ||
*** Bug 464605 has been marked as a duplicate of this bug. *** |
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)