Enhancement: UI notification when a new timetagger version is available

[PassionateBytes]

Summary

This PR notifies users in the UI about new release versions. For that, the frontend queries the public Github API for the latest release tag of the timettager project.

If the current release tag does not match the latest release tag, a notification-dot appears on the hamburger menu button, inviting the user to open the menu. Inside the app menu the Whats new... section also sports notification-dot, and explicitly informs the user about the new available version.

The change gracefully handles network errors when querying the github API. If the latest release version cannot be fetched, the application simply behaves as usual.

Screenshots

Changes

• Version fetching (tools.py)
  • Fetches latest release tag from GitHub API on page load and hourly
  • Stores in window.latest_release_version for UI comparison
  • Handles errors gracefully (potential network issues, rate limiting, no internet...)
• Notification dot on hamburger menu (front.py)
  • Modified _draw_button() to draw notification dot on canvas when update available
• Notification dots in menu items (dialogs.py)
  • Wraps icons in .icon-wrapper when notification needed
  • Shows dot on "What's new" item when update available
• CSS notification dots (app.scss)
  • Added styles for notification dot on menu items
• New global color (_style_embed.scss, front.py)
  • New $notification SCSS variable and COLORS.notification_dot constant
  • Consistent color across CSS and canvas rendering

[almarklein]

Have you also seen the similar logic in index.md? I must admit that code was written long ago; I'm not even sure if show_refresh_button() produces a button thats even visible :) But I'd rather clean it up while we're at it, to prevent having two systems that attempt to do the same.

[PassionateBytes]

@almarklein thanks for the note.

I've taken a look at the code you referenced in index.md and that actually covers a different (though related) scenario than my PR. - That show_refresh_button() function is for service worker updates. (when a new release of the timetagger server is deployed, this part of the service worker code enforces updates to locally cached PWA.)

My PR on the other hand is for release notifications, telling users that a new release is available and that they should update the deployment.

These are complementary features, not overlapping ones: My PR notifies users to update their deployment to the latest version. The service worker code ensures that PWA content is propagated to user's end devices, when new releases are deployed.

[almarklein]

The callback on 'controllerchange' serves a different purpose, but the lines further down, below "// Auto-update each several hours" are there to check for updates, so that when a user never refreshes, it happens automatically.

Your method is better, so I'd like to use that instead. But then let's disable the lines in index.md that registers the long timer.

[PassionateBytes]

I might still be missing something, but I still believe my point from earlier still stands:

These are complementary features, not overlapping ones: My PR notifies users to update their deployment to the latest version. The service worker code ensures that PWA content is propagated to user's end devices, when new releases are deployed.

The existing service worker logic in index.md still has a legitimate purpose, and it does not overlap in scope with my new additions. - That code (including the 4 hour timer) ensures that the PWA/Service Worker assets on client devices is updated, when a administrator updates the deployed (self-hosted) timetagger server.

My PR on the other hand, just checks whether there exists a new timetagger version on github, and reminds users to update their self-hosted deployment.

Again, I believe the existing service worker logic is complementary to my additions, and doesn't need cleaning up. On the contrary, it still offers the same helpful functionality as it did before - making sure that after a server update the clients update their PWA assets.

...Admittedly, I might be misunderstanding your point, in which case please let me know! Maybe I'm just missing something about how the service worker logic works...? But as far as I can tell, it does not check for new available releases for the timetagger server, like my PR does...

[almarklein]

My PR on the other hand, just checks whether there exists a new timetagger version on github, and reminds users to update their self-hosted deployment.

Ah, that's the point I was missing. Thanks for the clarification!