Customizing Bugzilla as IT Ticket System

[loumy...@gmail.com]

Greetings

I am planning to customize Bugzilla to act as an IT ticketing system. This will require me to add 10-15 custom fields, build custom reports and establish multiple security levels against these custom fields. I have performed Bugzilla customization in the past, but haven't taken on anything this extensive.

I am hoping a customization expert can provide some top-level advice on what I am about to do. My plan thus far is to edit the templates / create custom templates as necessary to hide most if not all of Bugzilla's fields on the appropriate pages using the typical hidden field mechanism and create custom fields that match my needs through the admin screens. Workflow is unlikely to change substantially and the existing tools for editing workflow seem adequate for my needs. However, there are a few specifics on which I am unclear:

* Can all default fields (including Product and Component) be hidden and never used or must I use some of these fields?

* Can I set user/group security to operate against only my custom fields? It is important that access be restricted based solely as these fields, as Bugzilla's default fields are not really applicable to my problem domain.

* Can you please provide any other high-level advice or anecdotes regarding this approach or your experience in attempting something similar?


Thanks much!

[Gervase Markham]

On 06/02/13 10:05, loumy...@gmail.com wrote:
> I am hoping a customization expert can provide some top-level advice
> on what I am about to do. My plan thus far is to edit the templates
> / create custom templates as necessary to hide most if not all of
> Bugzilla's fields on the appropriate pages using the typical hidden
> field mechanism and create custom fields that match my needs through
> the admin screens.

You would be better off renaming the existing fields, as far as is
possible given their data types, and then adding new fields when you run
out of existing fields to co-opt.

> * Can all default fields (including Product and Component) be hidden
> and never used or must I use some of these fields?

You have to use Product and Component, and you probably need to set a
value for Version as well.

> * Can I set user/group security to operate against only my custom
> fields? It is important that access be restricted based solely as
> these fields, as Bugzilla's default fields are not really applicable
> to my problem domain.

Why is Bugzilla's groups system inadequate for your security needs?

> * Can you please provide any other high-level advice or anecdotes
> regarding this approach or your experience in attempting something
> similar?

If you need to make such sweeping changes, why not start with a system
more closely designed for your use case?

Gerv

[Thorsten Schöning]

Guten Tag loumy...@gmail.com,
am Mittwoch, 6. Februar 2013 um 19:05 schrieben Sie:

> * Can you please provide any other high-level advice or anecdotes
> regarding this approach or your experience in attempting something similar?

Use the right tool for your needs as Bugzilla doesn't seem to fit
them? ;-)

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning E-Mail:Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[loumy...@gmail.com]

> On 06/02/13 10:05, lou wrote:
>
> > I am hoping a customization expert can provide some top-level advice
> > on what I am about to do. My plan thus far is to edit the templates
> > / create custom templates as necessary to hide most if not all of
> > Bugzilla's fields on the appropriate pages using the typical hidden
> > field mechanism and create custom fields that match my needs through
> > the admin screens.

[Gervase Markham wrote:]

> You would be better off renaming the existing fields, as far as is
> possible given their data types, and then adding new fields when you run
> out of existing fields to co-opt.

I came to this conclusion after further research, though the issue remains that reuse of existing fields and changing their name in templates may result in confusion when users attempt to write queries against these fields. Ideally, the queries my users will write should be in a domain language they understand and that maps to what they see on the bug entry page. Using only a template-based / cosmetic approach means the underlying fields they will be querying will not be changed. Nevertheless, I can re-use a number of the existing fields, including product, in a way that will likely make sense to the users with a bit of training.

> > * Can all default fields (including Product and Component) be hidden
> > and never used or must I use some of these fields?

[Gervase Markham wrote:]

> You have to use Product and Component, and you probably need to set a
> value for Version as well.

Thank you for this information. Based upon my review of the documentation I figured this was likely the case, but it would be good to know. I believe I can map these fields to something meaningful to the end user. Your information saved me from attempting something that was not doable in the name of trying to obtain a perfect match between my domain and the default domain of Bugzilla.

> > * Can I set user/group security to operate against only my custom
> > fields? It is important that access be restricted based solely as
> > these fields, as Bugzilla's default fields are not really applicable
> > to my problem domain.

[Gervase Markham wrote:]

> Why is Bugzilla's groups system inadequate for your security needs?

In hindsight and especially now that I believe I can make full use of the product field, I believe Bugzilla's security model will be adequate. My only concern arises from security requests that may arise in the future in which bugs based on custom fields should drive who could see or manipulate the bug state information. In the past, I have not had to customize Bugzilla's security model based on custom fields, but believe this may be necessary for this project. Do you have any experience with using custom fields and Bugzilla's groups to control access (read or read/write) to bugs in general or, in a finer-grained security model, to certain (potentially custom) fields on bugs?

> > * Can you please provide any other high-level advice or anecdotes
> > regarding this approach or your experience in attempting something
> > similar?

[Gervase Markham wrote:]

> If you need to make such sweeping changes, why not start with a system
> more closely designed for your use case?

and [Thorsten Schöning wrote:]

> Use the right tool for your needs as Bugzilla doesn't seem to fit
> them? ;-)

Thank you both for your responses. This is an excellent question and one in which I should have addressed in my initial post. First a small background:

The IT Ticket system I require is not "standard" IT ticketing though that is the best way to describe it. The system is to support two software and hardware testing labs in different states in the US. Within the labs, there is application software under test, embedded software under test, application and embedded test management software, custom hardware and wiring and of course a significant amount of core IT infrastructure (linux / windows servers, VME-based systems, routers and the like). Defects will just as often be software as hardware related. The goal is to capture problems seen by testers and drive to root cause solutions regardless of whether these are hardware or software solutions and regardless of how the problem manifested. Over time, we can build a searchable database of problem manifestations and root causes that will reduce problem resolution and provide the data to drive lab investment decisions.

Based on this, here is my reasoning in no particular order:

() Software defects will be a measurable portion (at least 50%) of the reported problems, but these defects may first, _to the tester_, appear to be problems in hardware. Thus, capturing the initial appearance of the problem in a domain-specific way is important even if the problem is often traced to software in the end. Buzilla seemed a fine fit, though it lacked many of fields I need and had a number of fields I either don't need or wish were optional.

() Where a problem arises in hardware, capturing software-related information is usually of prime importance. Obviously, this is Bugzilla's forte.

() I examined "true" IT ticketing systems and found them lacking in a number of ways: they were not FOSS, they lacked custom reporting, they lacked significant customization capabilities, they lacked the ability for users to store their own queries, they were not extensible, they did not provide rich graphical reports, and/or they were not easily upgraded / migrated to new systems or backed up in case of system failure. Bugzilla is very strong in all of these areas.

() Security is important to the system in that the labs are a shared environment among multiple customers and I need to ensure that customers can see only the information pertinent to their testing. Furthermore, all such information needs to remain unexposed to the public at large. I know from past experience that Bugzilla takes security seriously.

() I found that I would rather use a tool I understood and could receive advice when using then purchasing a tool on blind faith or choosing a FOSS solution that lacked the global reach and exposure of Bugzilla.

Thanks to both of you for responding!

I remain interested in suggestions, anecdotal information or questions. If you believe you have something to contribute, please post. I will respond.

Lou

[Gervase Markham]

On 07/02/13 19:02, loumy...@gmail.com wrote:
> In hindsight and especially now that I believe I can make full use of
> the product field, I believe Bugzilla's security model will be
> adequate. My only concern arises from security requests that may
> arise in the future in which bugs based on custom fields should drive
> who could see or manipulate the bug state information. In the past, I
> have not had to customize Bugzilla's security model based on custom
> fields, but believe this may be necessary for this project. Do you
> have any experience with using custom fields and Bugzilla's groups to
> control access (read or read/write) to bugs in general or, in a
> finer-grained security model, to certain (potentially custom) fields
> on bugs?

Controlling write access is fairly easy; use the
bug_check_can_change_field hook. Controlling read access might be
trickier. There's the "useproductgroups" parameter but I have no
experience of it. There's a can_see_bug function but I don't think it
contains a hook.

Gerv

[loumy...@gmail.com]

On Monday, February 11, 2013 9:02:03 AM UTC-5, Gervase Markham wrote:
> Controlling write access is fairly easy; use the
> bug_check_can_change_field hook. Controlling read access might be
> trickier. There's the "useproductgroups" parameter but I have no
> experience of it. There's a can_see_bug function but I don't think it
> contains a hook.

I will look into creating a custom hook should this issue arise.

Thanks for your time!


Lou