Cognos Bug of the Day

Experienced a nice juicy user interface bug in the Administration Console today. It's pretty obscure and specific, but knowing about it will prevent you from chasing down the wrong paths in terms of root cause analysis.

This little UI issue is a sanity breaker though, as it will have you second guessing what you did.

Standard checkbox behaviour in a web browser is that clicking on the label for a checkbox will toggle its state from checked to unchecked and vice versa. Since the label is usually a much bigger target to click on than the checkbox, you might prefer to click on the label over the checkbox itself.

In the Cognos Administration console, if you click on a checkbox's label to disable an entry, it works perfectly fine. But if you click on the checkbox's label to enable an item, it doesn't save the change. Note that the "Hide this entry" checkbox value saves fine, so it is isolated to the "Disable this entry" checkbox label.

Your first thought is likely to be "Well, this feature has been around forever, they've tested all edge cases. It can't be a UI bug, since I did the same thing to enable it and it worked." You might be thinking maybe it's a permissions or capabilities issue. Surprise, surprise, it is indeed a user interface bug (reproducible in 11.1.7 and 11.1.4).

So let me save you a bit of time hunting this issue down, because searching for "Cognos 11 can't enable printer" or whichever item you're trying to enable probably won't give you a very good result (unless this blog post shows up, haha).

Lucky for us, there is a workaround. You can re-enable the item by clicking on the checkbox itself and then saving.

I'm not in the habit of figuring out someone else's bugs, but curiosity got the best of me, so I looked at the markup in my browser's developer tools. If you're not into coding, you'll probably want to skip the next bit and be on your merry way.

It looks like the checkbox is inside a table, and when you click outside of the checkbox, the <table> tag has an onclick event that changes state of the checkbox (it wasn't the label after all). The problem is that the value is tracked not in the checkbox control, but in a hidden text field (which is storing the value being saved to the content store), and that field isn't changed to false when the "Disable this entry" checkbox is checked (it is for the "Hide this Entry" table click though).

I'm sure the markup is quite old (the heavy use of tables is a good indicator), as backwards compatibility with Internet Explorer is still a thing in the enterprise world, even today. Having said that, by modern web coding standards, the amount of code being used to manage a boolean state on a checkbox is absolutely bonkers.