Bug 57018 - Differentiation between Open source and contract bugs
Differentiation between Open source and contract bugs
Status: CLOSED NOTABUG
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
2.18
i386 Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: David Lawrence
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-03 08:08 EST by Andrew Lunn
Modified: 2007-04-18 12:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-11 00:00:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Lunn 2001-12-03 08:08:33 EST
Description of Problem:

When submitting bugs there needs to be a simple way to differentiate
between a bug submitted to be fixed under contractual support and an
OpenSource bug which im reporting FYI but has not yet caused my a problem.
Comment 1 Alex Schuilenburg 2001-12-03 08:30:26 EST
Is this not solved by making a bug viewable to the "eCos ASCOM PLC Contract"
group only equivalent to making it a contract bug, and leaving the bux unchecked
equivalent to making the bug public?
Comment 2 Andrew Lunn 2001-12-03 08:35:22 EST
Some contractual bugs im happy to leave visiable to the public, eg the libc
fflush bug i reported today on behalf of Robin.
Comment 3 David Lawrence 2001-12-03 10:52:21 EST
There is a special permission group called 'setcontract' that makes a check box
show up on the bug entry form if you are a member. It basically is a check box
allowing for the bug to be marked as a contract bug which causes a warning box
to be displayed on the screen when a person logs in that has outstanding
contract bugs assigned to them. People who need to be able to make contract bugs
need to be added to that permission group.
Comment 4 Alex Schuilenburg 2001-12-03 14:48:35 EST
OK, I see the new field now.  Is the intention that we also give the permission
to set this field to customers who are using Bugzilla, or is this an internal
field only?
Comment 5 David Lawrence 2001-12-03 15:01:08 EST
Normally what happens is that a new group is created that pertains to a
company/contract such as 'Intel Confidential' etc. The one or two people from
that group are given the ability to enter bugs as contract bugs and are placed
into the 'setcontract' group. That group gives the ability to make a new bug a
contract bug by clicking the checkbox when submitting and also make a current
bug report a contract bug by changing the priority to contract when making changes.
So it is not necessarily an internal only field.
Comment 6 Alex Schuilenburg 2001-12-03 15:15:38 EST
OK, gotcha!  I set Andrew to a member of that group so he should now be able to
change the priority of the bugs he submitted.

The only problem I can see is that the customer can set the priority of *any*
bug as contract, not only their own.

We really need a facility to that allows submitters who are paying customers
(i.e. support contracts) and members of "setcontract" only to set the priority
of a bug to contract, and even then this should only be allowed by the submitter
if they  have support on that component.
Comment 7 David Lawrence 2001-12-03 15:24:28 EST
Actually they worst thing that could happen is that someone with setcontract
privileges could set a *public* bug as a contract but I do not see that
happening. Otherwise the can see bugs marked private to their own contract group
not others. So if say a bug is marked private to 'Intel Confidential' and
someone who is only in 'Compaq Confidential', they would not be able to see it
much less edit the priority. Unless they were actually members of both groups
which would normally be RH employees. Of course I may be missing your point
entirely ;)
Comment 8 Alex Schuilenburg 2001-12-03 15:36:43 EST
No. You got the point, which is someone with setcontract priority could set an
arbitrary public bug with "contract" priority.

I am just concerned that this may put whoever is assigned that bug into a
tailspin . This is open to abuse by customers given this priviledge (not that we
don't trust them, just that not all are as trustworthy as you Andrew ;-).

Maybe a better solution would be to allow the "contract" priority to be set by
someone if they are in a "contract" group (like "Intel confidential"), and only
for bugs submitted by members of the same contract group. Then "setcontract"
could be for internal use only.
Comment 9 David Lawrence 2006-04-08 13:44:33 EDT
Red Hat's current Bugzilla version is 2.18. I am moving all older open bugs to
this version. Any bugs against the older versions will need to be verified that
they are still bugs. This will help me also to sort them better.
Comment 10 Andrew Lunn 2006-04-08 14:41:52 EDT
I think this bug can be closed. 

Alex Schuilenburg is no longer interested since he no longer works for RedHat
after they closed down the U.K. eCos group. The support contract that Ascom had,
and that i was the technical contact person for, is long since over.

The issue of "Differentiation between Open source and contract bugs" is now a
mute  point since RedHat is no longer active in the eCos field, except for Mark
Salter does RedBoot ports every so often. 

The only reason to keep this bug would be if the same problem applys to other
pieces of software Redhat has customer support contracts for, and this problem
is not solved by v2.18 of Bugzilla.
Comment 11 David Lawrence 2006-04-11 00:00:53 EDT
Tighter integration now between Bugzilla and Issue Tracker (RH's internal CRM)
can  now be used to tell which bugs are from customers are ones that are not.

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