Question

We're using the workflow plugin and would like to add a couple of categories which fall outside of the scope of software development (such as IT orders for example, which would be used only by the IT group) and we're worried that it would clutter the interface and confuse users with too many options.

One possible approach could be if you could somehow configure permissions for categories by using groups. So that in our case only members of the "IT" group would be able to see (and work with) cases of category "IT order".

Alternatively this could be solved by being able to configure whether a field should be displayed or not per category.

Case FC1838029

Answer 1

We have a case open for your request to allow fields to be disabled on a per-project basis. Please up-vote this question to show your support.

---

Here is a workaround using javascript:

You can hide drop-down and text fields as well as links using the guides linked to here.

You will need your code to run conditionally based on the category of the case. You can find it using the goBug object on the case page:

var oCategory = new CCategory();
oCategory.LoadByIx(goBug.ixCategory);
var sCategory = oCategory.name;

if (sCategory == 'Feature')
{
    console.log('Feature case');
    // call your function to hide the field/link
}

Run your code when the case view changes to edit mode. You will also need to bind to the event when the category drop-down changes and run when it is changed.

Here is a sample to hide the priority drop-down for feature category cases.

name:          Disable feature priorities
description:   Disables the priority droplist for feature cases
author:        Adam Wishneusky and Dane Bertram
version:       1.0.0.0

js:

// set the ixCategory to hide Priorities for
var ixCategoryHideEnabled = 2; // Features

// if we're not on the case page, don't do anything
if (!$('#bugviewContainer').length) return;

var setPriorityEnabled = function() {

    if (!$('#ixCategory').length) return;

    var ixCategory = parseInt($('#ixCategory').val(), 10);

    if (ixCategory === ixCategoryHideEnabled) {
        DropListControl.refresh($("#ixPriority")[0]).disable();
        console.log('disabled Priority field');
    } else {
        DropListControl.refresh($("#ixPriority")[0]).enable();
        console.log('enabled Priority field');
    }
};

// whenever the category changes, check if we need to disable anything
$('body').on("change", "#ixCategory", setPriorityEnabled);

// in case we're on the new case page
setPriorityEnabled();

// when the view changes to edit mode, check if we need to disable anything
$(window).on('BugViewChange', function(e, data) {
    if (data.sCommand === 'edit') {
        // add delay to allow for view transition
        setTimeout(setPriorityEnabled, 100);
    }
});

Answer 2

We thought about this, and it would be kind of nice to be able to limit categories to certain groups, but categories and permissions are so much a part of the core of FogBugz that this ended up looking like a lot of coding and design work, far more than would be warranted by the potential benefit. Additionally, we wanted our workflow plug-in to be as lightweight as possible, as even the simplest workflow management can get confusing.

If we had unlimited resources, this would already be done. As it stands, many other features outweigh it from a cost-benefit standpoint.

Answer 3

For per-category Custom Fields, see this question

Answer 4

I would also love to see the ability to set filed visibility per category. Minimalism is one of the reasons I am considering to use FogBugz.

Some use-cases where this feature would be useful: 1. Bug category - typically needs several unique fields like version, operating system, etc. 2. Folder category - A 'Folder' case is sometime useful to keep a well structured case tree. 'Folder' case does not need most fields.