803728 - Custom message if "Open for bug entry" not enabled (instead of "Entering a bug has been disabled.")

Status: NEW

(Bugzilla :: Administration, task)

Description

[Andre Klapper]

1. Have some external doc pages linking to /enter_bug.cgi?product=foo
2. Go to /editproducts.cgi?action=edit&product=foo
3. Uncheck "Open for bug entry" for various reasons (deprecated product, 
   superseded by product foo2, restructured Bugzilla organization)
4. Go to /enter_bug.cgi?product=foo
5. Get a generic "Sorry, entering a bug into the product foo has been disabled."

Thinking about usability:
Confused average users that will either not file their report at all or file it in a random place instead.

Proposal:
Add a non-mandatory setting under /editproducts.cgi?action=edit&product=foo which is only shown/enabled if "Open for bug entry" is NOT enabled.
Make it a text field to enter a custom message replacing or added to the current string, so I could turn it into something more helpful, like (random example):

"Sorry, entering a bug into the product 'Mobile' has been disabled. 
Please enter a bug about our mobile application in the product 'MobileApp' instead, or a bug about our mobile website under product 'Website' and component 'Mobile'."

Comment 1

[Simon Green]

Attachment: v1 patch

Comment 2

[Dave Miller [:justdave]]

I like this idea, but I think this would be better implemented as a template hook.  Then you can drop a file into your template directory with your message in it (and an if statement checking which product if necessary) and use the template system to its fullest advantage to put whatever you wanted in there instead of just what you can fit in a text box.

Comment 3

[Dave Miller [:justdave]]

Template doc hooks are here: http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/Extension.html#Template_Hooks

We'd likely need to identify the correct spot in the existing template that includes this error message to put the hook.

Comment 4

[Frédéric Buclin]

Comment on attachment 704211 [details] [diff] [review]
v1 patch

I'm honestly not interested in that feature, because I don't think it would be used a lot. Most products are active, and when a product becomes inactive, people will simply not see it. "Broken" links should rather be fixed to point to the new product.

For DB performance, I would prefer to not see another text field in the products table. And MEDIUMTEXT is IMO too large for such a field.
From a UI point of view, I would prefer to not see another text field in the admin page by default, as this field is useless as long as the product is active. So at the very minimum, JavaScript should hide this field by default till the product is marked as closed for new bugs.

I will let justdave have the final word on this.

Comment 5

[David Lawrence [:dkl]]

+1 for template hook

Comment 6

[Dave Miller [:justdave]]

(In reply to Frédéric Buclin from comment #4)
> I don't think it would be used a lot.

Whis is exactly what makes it a good template hook rather than a DB field.

> "Broken" links should rather be fixed to point to the new product.

In a perfect world, yes.  But the world isn't perfect, and trying to make it perfect is often an exercise in frustration.  Better to make things easy on the users when you can.

Comment 7

[Simon Green]

(In reply to Frédéric Buclin from comment #4)
> I will let justdave have the final word on this.

So Dave, WONTFIX or commit?

Regards,
Hugo.

Comment 8

[Teemu Mannermaa (:wicked)]

(In reply to Hugo Seabrook from comment #7)
> So Dave, WONTFIX or commit?

If I'm reading the bug correctly, neither. Thanks for the patch but we'd need a new one that does the template hook thingy that people think is better suited to fix the reported problem.

Comment 9

[Simon Green]

(In reply to Teemu Mannermaa (:wicked) from comment #8)
> If I'm reading the bug correctly, neither. Thanks for the patch but we'd
> need a new one that does the template hook thingy that people think is
> better suited to fix the reported problem.

No problems. I'll reassign this to the default assignee for someone else to work on. There are probably more important bugs that need attention.

Regards,
Hugo

Comment 10

[Charles Lewellen]

Attachment: same problem

Thanks from alocersmar1989.