[justdave]

Details

Adds a donation banner to the front page, per the specification in Bug 1983391 comment 3

Light mode:

Dark mode:

The "call to action" message at the top is randomly picked from the following list:

use constant BANNER_MESSAGES => (
  'Help us make Bugzilla better more often.',
  'A small donation helps keep Bugzilla moving forward.',
  'Support the people who keep Bugzilla running.',
  'Even a little funding helps Bugzilla improve more quickly.',
  'If Bugzilla helps your team, consider helping Bugzilla too.',
);

I'm open to suggestion for messaging in there.
It could use a real graphic on the left, too. Buggie holding a wad of cash? @hellcp

The administrative params screen linked to in the bottom of that banner:

The end-user preferences screen:

Additional info

• bug#1983391

Test Plan

1. Fired up Bugzilla using the docker image, and played around.

[dannycolin]

No strong feeling if we keep the current list of options but it might be better to have less. For example,

• Remind me later (default: 1 month)
• Pick a date...
• Never...

Feel free to file a follow-up bug to explore this option if you consider it low priority for the next release ;)

[mrenvoize]

We don't need the settings exposed twice under 'Preferences' do we.. once without good descriptive names under 'Bugzilla.org' in the 'General preferences' and a second time in their own tab on the left 'Donate to Bugzilla'

[justdave]

Nope, should only be on the donate tab. I'll fix that.

[mrenvoize]

OK, not just cosmetic.. there's some other leakage of those preferences going on...

1. On the home page, in the banner dropdown pick "Remind me after the next Bugzilla upgrade" → Save. Banner disappears; reload home to confirm it stays gone.
2. Now go to Preferences → General Preferences and click Submit Changes without touching anything.
3. Reload the home page → the banner is back.

Looking at the database, it looks like when saving settings from the 'General preferences' area, even if nothing changed.. we wipe the banner settings.

[mrenvoize]

Dismissing via the Donate tab doesn't actually dismiss

1. Go to Preferences → Donate to Bugzilla (userprefs.cgi?tab=donate).
2. Select "Remind me after the next Bugzilla upgrade" → Submit Changes.
3. Reload the home page → the banner is STILL showing.

Looking at the database donate_banner_pref does get properly set to 'next_upgrade' but theres no donate_banner_last_version row

[mrenvoize]

I think the banner itself should match the width of the homepage.. it looks a bit odd having part of the page nicely centred with gutters and the banner not adhering to the same.

[mrenvoize]

The buggy picture is a bit stretched.. but you've already suggested that you'd like to improve that.

[mrenvoize]

I think I'd also display the banner on the 'Administration' page until it's dismissed.

[mrenvoize]

Inspecting the code a little.. it looks like we're using the same '#new_release' slot in the template as the security release warnings stuff..

Doesn't that mean that the donation banner hides the new-release / EOS notice

I couldn't quit work out how to replicate that one for reals, but the code is fairly clear to follow.. I think the donation banner should be more distinct in the template.

[mrenvoize]

Nope, should only be on the donate tab. I'll fix that.

Fixed in a follow-up above

[mrenvoize]

Whilst working through this I think I found bugs in how we're triggering update notifications and how bugzilla is versioned now.. the Bugzilla::Constants version (which take a semantic form) is basically ignored everywhere and instead we're using the Bugzilla->VERSION string (which is a date format string) instead... it's tied into all the CSS and JS static file endpoints too, so it's not a fix I think we should work on here.. I'll report a new bug for it

[mrenvoize]

Good catch there @dannycolin

I've fixed, squashed the fix and pushed.

Could you re-review please ?

[mrenvoize]

OK, another little push with the 5.14 update to get the tests happy again now I've rebased it all

[justdave]

My idea for the graphic was to have Buggie holding a wad of cash or something. Maybe that would look too greedy though. The current Buggie image only got used because it was already in the source tree.

[dannycolin]

My idea for the graphic was to have Buggie holding a wad of cash or something. Maybe that would look too greedy though. The current Buggie image only got used because it was already in the source tree.

We could have a bugzy that water a small tree to symbolize the idea of growth. Maybe there's another even better analogy but you get the idea.

[justdave]

This is looking pretty good to me. Now to get the updates from here backported to the 5.2 PR.

Going to refactor this more before committing, so getting it off the "ready to commit" list.

[mrenvoize]

Doh.. I just rebased but didn't spot @justdave said he was going to refactor some more.

[mrenvoize]

Looks reasonable: no third-party fetches, CSP nonce on the script, FILTER html on output, and POST plus a token on the dismiss endpoint. Suggestions: add rel=noreferrer to the donate link; the CSS/JS load on every page, so consider loading only on the home page; and a test for the dismiss endpoint. The base is a stacked branch, so it will need retargeting once its parent merges.

[justdave]

The new test suite I just added gets run by the "Sanity Tests" test job, in case you want to see the output from GitHub running them.

[mrenvoize]

I ran this against the PR head (589d723) in Docker as an admin and as a plain user: all three visibility modes, each dismissal path, the preferences tab, the params panel and static asset serving. It all behaves as described, and the extension tests and the t/ sanity set pass. I'm going to hold off approving until the first item below is sorted. The rest are small and fine as follow-ups if you'd rather not hold this up.

1. Cache-bust the CSS and JS. The banner links donation-banner.css and donation-banner.js at a fixed path (extensions/BugzillaDonationBanner/web/...), and the server serves those with Cache-Control: public, max-age=31536000, immutable. After an upgrade that changes either file, browsers can keep the old copy for up to a year. Core handles this with the version filter (see format_js_link in global/header.html.tmpl), and I confirmed the versioned form serves the extension's files, e.g. /static/v20200805.1/extensions/BugzillaDonationBanner/web/donation-banner.css returns 200. So in donation/banner.html.tmpl and account/prefs/donate.html.tmpl, use [% 'extensions/BugzillaDonationBanner/web/donation-banner.css' FILTER version FILTER html %] for the <link> and the same for the two <script src> tags. The SVG can stay unversioned.
2. Unknown or missing donate_action is a silent no-op. bin/donate.cgi passes the parameter straight to dismiss(). With a valid token and an unrecognised action it redirects as if it worked and changes nothing, and with the parameter missing it hits an uninitialised-value warning on eq. Throwing a user error for anything outside next_upgrade, week, month, date and never would be cleaner.
3. template_before_process matches more than the home page. m{(?:^|/)index\.html\.tmpl$} also matches admin/params/index.html.tmpl, so banner data is computed there for nothing. $file eq 'index.html.tmpl' would be tighter.
4. The "Donate to Bugzilla" preferences tab is shown to non-admins under the default admins_only setting, even though they never see the banner, so the preference has no effect for them. Hiding the tab unless the banner can be shown to that user would avoid that.

For other reviewers: / is a static, cacheable redirect to /home (Bug 1532766), so the banner appears on /home, not /. That's existing behaviour, not an issue with this PR.