Possibility for more control over dismissability of banner

[luzpaz]

Currently at the top of the FreeCAD mantisbt we use the announce plugin (as an intrusive banner) to educate users how to open tickets. It's cut down immensely on crap tickets that are hastily opened and hopelessly incomplete. The problem is that users can dismiss this banner and then forget in the future to follow the directions. If we make the banner indissmissable, then all the power users are subject to this enormous banner taking up screen real-estate.

The ask: Would it be possible to create a rule that makes the banner indismissable to reporters, and dismissable to everyone with a higher permission ?

[dregad]

It would certainly be feasible to transform the "dismissable" flag to an access level. It would require a schema change and some UI adjustments.

That being said, based on your use-case description, I'm wondering whether the Announce plugin is really the right tool for the job though. It seems to me that a more targeted message, appearing only on the MantisBT bug report page, would be more appropriate.

[luzpaz]

That being said, based on your use-case description, I'm wondering whether the Announce plugin is really the right tool for the job though. It seems to me that a more targeted message, appearing only on the MantisBT bug report page, would be more appropriate.

Perhaps, but psychologically I want to prepare the user to know what it means to make a bug report. I don't want to, last minute, for the user to be surprised by what hoops we're asking them to jump through. That is why I'd rather have 'reporters' see it on every page of the bugtracker instead of just the bug reporting page

[vboctor]

@luzpaz I was thinking about the same feature, but the solution I had in mind was more inline with how Github solves this. Basically, to do be able to configure default values for description, additional info, and steps to reproduce. Such configs can be set globally via config/config_inc.php or on a per project basis. Such templates would apply to all access levels.

[atrol]

@vboctor for what you want, the Snippets plugin could be extended (e.g. additional propertyautofill_field for snippets + move global snippet settings to individual snippets)

[vboctor]

@atrol I think this is better handled in core, since it not a snippet and it would be consistent with ability for core to default other native fields.

[luzpaz]

@luzpaz I was thinking about the same feature, but the solution I had in mind was more inline with how Github solves this. Basically, to do be able to configure default values for description, additional info, and steps to reproduce. Such configs can be set globally via config/config_inc.php or on a per project basis. Such templates would apply to all access levels.

I think the config/config_inc.php method also makes sense. It would add another nice customization option for projects that would like to use this type of functionality.

[vboctor]

Turns out that steps to reproduce and additional info already supported defaulting. I have added support for defaulting description via the following PR:

mantisbt/mantisbt#1320

[luzpaz]

Awesome. I look forward to testing this when it's merged. Any idea on the ETA ?

[luzpaz]

Great, it's been merged. Thank you. Just need to wait till the next mantis release to test it.