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
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`
The generate RSA key and import theme routes worked separate from each
other. The RSA key returned both the public and private key and it was
the frontend which posted the private key back to the server. With this
commit, only the public key is necessary as the server keeps a map of
public and private keys that is used to get the private key back from
a public key.
It used to return the next URL anyway which lead to an additional
request. On the frontend, if the result set was empty, it kept retrying
until at least one result was returned. This bug is fixed in this commit
too.
`popupAjaxError` is used by the controller to handle errors when saving the badge model. That only works properly when it gets the original exception from the ajax call. This manipulation of the error in the badge model was breaking that behavior.
The admin-badges controller is the only place which saves this model, so this shouldn't cause any issues elsewhere in the app.
This lets us use all our normal JS tooling like prettier, esline and babel on the splash screen JS. At runtime the JS file is read and inlined into the HTML. This commit also switches us to use a CSP hash rather than a nonce for the splash screen.
* FIX: hide welcome topic banner as soon as the welcome topic is edited
This commit adds a message bus listener on client to hide the welcome
topic banner as soon as the welcome topic is edited.
* update test
* only subscribe when show_welcome_topic_banner is true
* Do not lookup for messageBus service if it's not required
* Remove unneeded code
* Cache result for Site.show_welcome_topic_banner
* Update tests per latest changes
* Changes per PR review
Each new user menu notifications should have their own count. Therefore, we need to include all types to serializer and not only `grouped_unread_high_priority_notifications`
Additional PR will be created for chat and assign plugin, as they will have to switch to `grouped_unread_notifications` as well.
When installing private themes and theme components, the public key does
not show until the administrator types a valid Git repo URL. The regular
expression that checked the URL was too strict and it required the URL
to end with ".git".
In eb12daa7f8 when adding community
section support for anonymous users, we changed the `sectionLinks`
property into a getter method. This meant that if the getter method was
called again after the community section has been rendered, we would end
up reintializing the section links classes. As part of the
initialisation, some section links would setup a TopicTrackingState
onStateChange listener. However, the listener is only removed when the
entire community section is removed which resulted in us leaking the
onStateChange listeners.
This commit reverts the `sectionLinks` from being defined as a getter
method into a property which is only set once when the community section
is being constructor. Also, we changed it such that the community
section will register the listener instead of each section link since it
makes cleaning up much easier to reason about.
No tests have been added for this commit because the original bug is
not possible after this change and we already have an existing tests
ensuring that TopicTrackingState change listeners are cleaned up when
the community section is destroyed.
Internal ref: /t/73224
When you receive a new notification, Discourse prepends a small count `(n)` to the tab title (i.e. `document.title`) if the tab is in the background to alert the user that they have a new notification. The count that's shown in the tab title should reflect the numbers shown on the notification bubbles above the user's avatar. Prior to the experimental user menu, there were 2 bubbles: a blue one which was removed once the user opened the menu and a green one that indicated high priority notifications and it was only removed when the user read all of their high priority notifications.
In the new experimental user menu, we no longer have the green bubble; everything is now combined (including flags/reviewables) into the blue one with no change to its behavior (i.e. it's removed once the user opens the menu). However, the logic that is responsible for updating the tab title hasn't been updated and still updates the tab title to include the count of the old green bubble. This commit updates the logic for the tab title count so that it only reflects the number on the blue bubble when the experimental user menu is enabled.
Kris
Jarek Radosz
Penar Musaraj
dependabot[bot]
Osama Sayegh
David Taylor
Arpit Jalan
Andrei Prigorshnev
Jordan Vidrine
Krzysztof Kotlarek
jbrw
Ghassan Maslamani
Bianca Nenciu
Joffrey JAFFEUX
Alan Guo Xiang Tan
Keegan George