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.
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?
Some contractual bugs im happy to leave visiable to the public, eg the libc fflush bug i reported today on behalf of Robin.
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.
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?
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.
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.
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 ;)
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.
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.
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.
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.