Right now the experimental user menu sorts notifications the same way that the old menu does: unread high-priority notifications are shown first in reverse-chronological order followed by everything else also in reverse-chronological order. However, since the experimental user menu has dedicated tabs for some notification types and each tab displays a badge with the count of unread notifications in the tab, we feel like it makes sense to change how notifications are sorted in the experimental user menu to this:
1. unread high-priority notifications
2. unread regular notifications
3. all read notifications (both high-priority and regular)
4. within each group, notifications are sorted in reverse-chronological order (i.e. newest is shown first).
This new sorting logic applies to all tabs in the experimental user menu, however it doesn't change anything in the old menu. With this change, if a tab in the experimental user menu shows an unread notification badge for a really old notification, it will be surfaced to the top and prevents confusing scenarios where a user sees an unread notification badge on a tab, but the tab doesn't show the unread notification because it's too old to make it to the list.
Internal topic: t72199.
This PR changes the icon for `posted` notification types (these are the notifications that you receive when someone posts in a topic you're watching) from `reply` to `discourse-bell-exclamation`. We're doing this to visually distinguish between the `posted` notifications and `replied` notifications which are the notifications that you receive when someone replies to you directly.
Internal topic: t72835.
In Safari, `img.complete` is sometimes true even before the image is loaded. Checking for the presence of `img.naturalHeight` seems to be more reliable. It is very difficult to write a test for this behaviour due to the dependence on network conditions, scroll location, etc.
`img.naturalHeight` is supported by all our target browsers, and I have verified the functionality of this commit in Chrome, Safari and Firefox.
This updates the ember-cli plugin detection logic to match the logic in `Plugin::Instance.find_all`. It will now ignore plugin directories which do not have a `plugin.rb` file.
This commit adds to the experimental user menu a new "other notifications" tab that's very similar to the "all notifications" tab, but with the main difference being that it doesn't show notification types that do have dedicated tabs in the menu (e.g. mentions, likes, replies etc.).
The rationale behind this is that the notification types that do have dedicated tabs tend to dominate the "all notifications" tab, leaving very small chances for the user to notice rarer or infrequent notification types. Adding a tab for all the other types gives the user a way to review those infrequent notification types.
Internal ticket: t72978.
Co-authored-by: OsamaSayegh <asooomaasoooma90@gmail.com>
We were using the directory name rather than the plugin's defined `name`. This was an unintended change in behaviour from the old sprockets implementation. This commit makes the ember-cli naming logic match the old sprockets logic.
If the server is configured to use a view like `categories_and_latest_topics`, it will preload data for the topic list. If the client doesn't actually use it (e.g. on mobile), then that preloaded data would remain cached and be used for the next loaded topic list. This commit ensures it's always removed, and adds a test for the behaviour.
https://meta.discourse.org/t/237126/35
A user could receive more than a notification for the same post if they
watched both the categories and tags at different levels. This commit
makes sure that only the watching notification is created.
* Add DiscourseEvent before post notifications are created
Previously we were relying on a highly-customized version of the unmaintained Barber gem for theme template compilation. This commit switches us to use our own DiscourseJsProcessor, which makes use of more modern patterns and will be easier to maintain going forward.
In summary:
- Refactors DiscourseJsProcessor to move multiline JS heredocs into a companion `discourse-js-processor.js` file
- Use MiniRacer's `.call` method to avoid manually escaping JS strings
- Move Theme template AST transformers into DiscourseJsProcessor, and formalise interface for extending RawHandlebars AST transformations
- Update Ember template compilation to use a babel-based approach, just like Ember CLI. This gives each template its own ES6 module rather than directly assigning `Ember.TEMPLATES` values
- Improve testing of template compilation (and move some tests from `theme_javascript_compiler_spec.rb` to `discourse_js_processor_spec.rb`
Kris
Osama Sayegh
Penar Musaraj
Jarek Radosz
dependabot[bot]
David Taylor
Arpit Jalan
Andrei Prigorshnev
Gerhard Schlager
Jordan Vidrine
Krzysztof Kotlarek
jbrw
Bianca Nenciu
Ghassan Maslamani