Open Bug 173127 Opened 22 years ago Updated 2 years ago

product- and user-specific views

Categories

(Bugzilla :: Bugzilla-General, defect)

Product:
Bugzilla
Component:
Bugzilla-General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

People

(Reporter: myk, Unassigned)

References

Details

Different products may have different bug tracking needs, especially when they are being worked on by separate teams, so it should be possible to customize the "enter bug" and "show bug" UIs (showing/hiding various fields) based on the product to which a bug belongs. Different types of users (development, QA, project management, etc.) also have very different needs and interests, so it should be possible to customize the UIs for each of these groups. Either of both of these customizations may need to take place for a given user/product, which means two independent axes of customization.
Blocks: bz-zippy
For product specific stuff, wouldn't product-specific fields which are settable on a per product basis cover 99.9% of this? The only things which wouldn't be settable this way are: - flags (which are handled in teh same way via another mechanism) - assignee/reporter/cc/product/bug#/component - does anyone seriously want to disable those? cc is the only one of those which is removable w/o much work, and I doubt anyone actually wants to do so. Even cc may be doable as a custom field - keywords - this could be modified to have product specific keywords, but since this scheme seems to only imply an all-or-nothing thing, this should be trivial - dependency/blocking - does anyone want to disable these? - status/resolution - these are required to be present, but the values I guess could be modified, when custres comes. - alias - hmm The rest are custom fields, falling into several categories: - freeform - url/status whiteboard - select-from-list - platform/os/priority/severity/milestone - valid-email - qa contact (yes, this option isn't in the first round of the fields patch, but its not that hard to add given the infrastructure there). Since the qa can always see a bug, theres we could just have a bit on teh field to say 'user-can-always-see-bug', or something. Note that I'm not objecting to doing this, and doing so is reasonably trivial, via a template naming scheme of some sort. I just think that custfields is a better/more flexable/more easily customaisable/etc way to do so, and since thats on the plan anyway.... Or was this not the sort of 'view' you were thinking of? Can you give a concrete example of user-specific view which is wanted? Which of our fields would a particular class of user always want to not see?
Epiphany. We can do this using stylesheets. We make sure every UI item relating to a particular field is inside a container with a class name of that field. Then, we have a style-sheet-choosing template which, based on any criteria you like (product, group etc.) chooses a stylesheet for that user. That stylesheet contains a number of rules like: .bug_priority { display: none; } This would require a rearrangement of the enter_bug and show_bug templates so that they wouldn't break when random bits of the UI are removed, but I think that this is possible. This needs doing for custfields anyway - we need to be able to add a reasonably arbitrary number of dropdowns and text boxes to show_bug without it breaking. This is an infinitely preferable solution to multiple templates, or breaking the templates up, both of which would be a nightmare to maintain. To answer bbaetz' point: custom fields are going to be per-product. If you want different groups of users to have different views of the same bug, then custom fields alone won't do the job. But some of the stuff you say is very wise - you are definitely right about needing an "email" custom field. Gerv
stylesheets don't really work, because you're left with gaps in the output, and the result will look ugly. We have to do this server side, since I don't know of any client-side way to cover this. For my custfields solution to this, see bug 91037 comment 110 #3. I'm sure I gave more info on that somewhere, but maybe I just thought about doing so. I still have trouble naming a field which user-type-A wants to see/change, but user-type-B doesn't, and so I'd really like to see a use-case from myk. It doesn't have to be a field which is present in bugzilla now, it could be one which custfields will allow the addition of. Not to mention those users whose jobs cover multiple roles... My point wrt custom fields is that there are very few fields which bugzilla really cares about internally, and those that it does are stuff which can't be removed, and which hiding doesn't make sense for. This makes product specific 'views' basically obsolete, since you customise those at the field level. It will probably make sense from a UI-point of view, though, if there are a large nuymber of different fields. Again, though, edit-<product>.html.tmpl will do for that, falling back to edit.html.tmpl if that fails. Thats a ~10 line patch after my Bug.pm stuff goes in, if thats all that myk wants with that part of this request.
You can also set "visibility:hidden" in addition to "display:none", the combination of the two completely removes the section from the page layout, reflowing everything to fill in the hole. On the other hand, if someone doesn't use a browser that has complete CSS support, they'd still see it because the stylesheet wouldn't hide it.
Bradley - here are a few examples for you: 1. Team A and B are in the same company and must use the same database. Team A works on a project requiring testing with different versions brands of television. Team B works on a project testing something else where the brand of television is irrelevant. In Team A's "view" for the bug database, it makes sense to have a field showing the many television brands that are being tested so the team can report bugs against it. In Team B's "view", having a field showing brands of television would not make sense and the field would just be wasted space. 2. Company C works with Company D on a project. Company D uses a database within it's firewall. The database cannot be put into the public since Company D's products are not developed in open source (ie. government or something). The bug database holds many projects and fields. Company C has been give access to the bug database. However, there is a need to give Company C limited access to projects and/or fields within the same project. So, Company C's views/access the the fields would be different than Company D. I can probably come up with more examples :-)
1) is taken care of by custom fields, which isn't implemeented yet, but is apparently another zippy-blocker - you simply define teh TV field as only valid for product X - I presume breaking this up at the product, rather than the component, level is OK? 2) is handled by product groups, I think - if people can't see the product, then they can't see the component. Given the restrictions of (2), CSS wouldn't work, since then people could still do view-source to see the info. If you want people to see part of the bug only, then this becomes a lot more difficult, because the post_bug page has to handle the fact that the modification didn't happen. Is that what is required?
I cannot think of a real-world example of, if C and D are collaborating on a project, there should be fields that D can see and C can't. If there is some information like that, you could use the Insiders functionality and add the information to the comments. I still maintain that CSS is the obvious way to go here; if there are extreme situations where it won't work for security reasons, then that administrator can go to the hassle of maintaining multiple overlapping custom templates - but that's no reason to impose that burden on default Bugzilla, and other admins whose requirements are more sane. Gerv
Depends on: 175861
Bradley: I think there are lots of use cases for user type-specific fields. In particular, engineers aren't frequently interested in project management fields (by when a bug should be fixed, how many man-hours it will take to fix it, etc.), while project management types may not be that interested in the bug specifics (f.e. platform, os, version). I'm not arguing that these groups shouldn't have access to this information, only that it shouldn't be treated as if it was just as important as all the other information available to each user type. Right now "show bug" is a mess, and part of the problem is the volume of fields we show everyone. This volume seems to be increasing, and a little bit of a differentiation between major types of users and the fields they are usually interested in (with appropriate mechanisms for accessing those fields when necessary) would go a long way towards cleaning it up. This may need to be a separate bug.
Maybe show_bug needs to be split into panels like the preferences are. We can have one panel for "Show everything" that you can use when you need to change several things at once, and then other panels that would only show a piece of the information. Bug Activity and Dependency Trees could easily become two of these panels instead of having links in the middle.
myk: Well, I'd hope that engineers are interested in when a bug is meant to be fixed by, so that they can aim to do so before that date :) I do see your point, though, and I can see some fancy css/js based stuff for 'hiding' such fields in some cases, similar to what gerv suggests. Thats different from what I'm interpreting Lisa's proposal to being, ie where some fields are 'hidden' for security/confidentiality/etc reasons.
dmose suggested i comment here. I'm not sure if what I need is really relevant to this bug, so feel free to point me at a different bug. As an engineer with a fairly rich bug list, I need a field in bugzilla that: 1) only I can change (the "assigned" owner is the only one who can set the field) 2) has a fairly rich set of values (either an open text field like the status whiteboard, or a field with lots of values like our milestone field) 3) shows up as one of the columns I can choose for bug lists, and that I can sort on. 4) the filed is not given a semantic meaning that anyone else depends on or tries to interpret (ie, changing 'milestone' to meet condition #1 isn't sufficient) This need is one that has become clear to me over ~4 years of bugzilla usage.
> Maybe show_bug needs to be split into panels like the preferences are. Not wanting to bang on about styles, but we could use alternate style sheets (which you can switch with JS, or Mozilla has a menu) to make it possible for e.g. engineers to see the product management view should they wish to do so - and without the need for a reload from the server. Lisa's proposal does seem to be more about security; is the security aspect of it the Zippy requirement, or is it the custom-views-for-simplicity requirement? I'd be surprised if Zippy wanted to have confidential information (hidden completely from one team) when those teams are working on the same bug. Let's not forget the insiders feature, which can help in that situation. Gerv
Yeah, Gerv, Zippy's requirement here is more about security. It's not actually about hiding information from other teams, it's more about restricting which teams can change the information. The users who weren't a member of a specific group would get a given field as read-only (and would be displayed that way on the screen).
No longer depends on: 175861
*** Bug 175861 has been marked as a duplicate of this bug. ***
I was thinking we need 2 main types of views: 1. languages These would sit in template/XX (where XX is the language code) and would contain one or more skins (see below). Each language directory could contain a metadata file, either as a template file or as a simple .pm possibly that describes the name of the language, the language pack maintainer, etc... 2. skins These go inside each language pack directory and contain actual sets of template files. They can be layered so you can have en/default and en/myproduct and any templates not defined in myproduct would be pulled from default. The language would be set by the user in user prefs and the skin could be set in one of three places (processed in the following order): 1. By group (all users in a group use a certain skin) 2. By product (all bugs being filed or viewed in a given product will be displayed with a certain skin) 3. By user (an individual user selects the skin they would like to use in user prefs) We would ship the English language and the default skin (possibly some other skins if others are developed, light html or lynx mode maybe?) and it would be up to admins to add/write others as needed. Another option would be to store language data in localization files and keep the strings separate from the templates, but this would probably not work very well. Thoughts? Ideas? Complaints?
Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa
See also bug 221017, which suggests different templates depending on a bug type.
*** Bug 213775 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.