When sending a full search request to backend (i.e. when hitting Enter),
the debouncer needs to be cancelled, otherwise it will get invoked and
trigger a second search request to the backend.
When deleting a for_topic bookmark, we were calling
bookmark.attachedTo() for the bookmarks:changed event,
but the bookmark was not always a Bookmark model instance,
so sometimes that call would error. Now we make sure that
the bookmarks in the topic.bookmarks JS array are all
bookmark model instances, and added a test to cover this
deleting for_topic bookmark case as well.
A follow up PR should investigate why `proposal-logical-assignment-operators` is not getting used here (test file?) but this should be enough to get things running.
I was previously relying on `this.isDestroying` returning `true` during `willDestroyElement`. This was an incorrect assumption.
This commit refactors the logic into an explicit `cleanup` function, and also adds some cleanup for empty keys in the `subscribedProxy` array
The flow goes from:
- getting current user object
- creating a POJO using some of the current user keys
- passing this POJO around, which end up being used in message bus
- the processing fn associated ens up doing User.create on this object will both create a User object, but also inject store in it, store is holding a reference to currentUser Object and...
BOOM, we have an object holding a reference to the same object, which JSON.stringify used in prepareBody of pretender doesn't like.
This commit adds uploadHandler support to composer uploads using
uppy. The only things we have that are using this are discourse-brightcove and
discourse-video, which both pop modal windows to handle the file upload and
completely leave out all the composer-type flows. This implementation simply
follows the existing one, where if a single file is uploaded and there
is a matching upload handler we take control away from uppy and hand
it off to the upload handler.
Trying to get this kind of thing working within uppy would require a few
changes because they have no way to restrict uploaders to certain file types
and with the way their uploaders are run it doesn't look like it would be easy
to add this either, so I don't think this is worth the work unless at some
point in the future we plan to have more upload handler integrations.
I also fixed an issue with `cleanUpComposerUploadHandler` which is used
in tests to reset the state of `uploadHandlers` in the composer. This
was doing `uploadHandlers = []` to clear that array, but that creates
a brand new array so anything else referencing the original array will
lose that reference. Better to set `uploadHandlers.length = 0` to
clear it. This was breaking the tests I added to see if upload handlers
were working.
We were previously showing the "n new or updated topics" alert on
category routes like `/c/category-slug/ID/none` on every new/unread
topic update. This PR looks up the category by ID, which should be more
precise.
Previously, `loadLibs` was called inside the `optimize` function of
the media-optimization-worker, which meant that it could be hit
multiple times causing load errors (as seen in b69c2f7311)
This commit moves that call to a specific message handler (the `install` message)
for the service worker, and refactors the service for the media-optimization-worker
to wait for this installation to complete before continuing with processing
image optimizations.
This way, we know for sure based on promises and worker messages
that the worker is installed and has all required libraries
loaded before we continue on with attempting any processing. The
change made in b69c2f7311 is no
longer needed with this commit.
This new app event will fire whenever a bookmark is created,
edited, or deleted for a post or topic, and replaces these old
app events which had inconsistent APIs:
* page:bookmark-post-toggled
* topic:bookmark-toggled
When the event is triggered, the arguments are in this order:
1. bookmark - The bookmark record created or changed. Will be null
if the bookmark was deleted.
2. target - Object with target (post or topic) and targetId (post ID
or topic ID)
When inviting a group to a topic, there may be members of
the group already in the topic as topic allowed users. These
can be safely removed from the topic, because they are implicitly
allowed in the topic based on their group membership.
Also, this prevents issues with group SMTP emails, which rely
on the topic_allowed_users of the topic to send to and cc's
for emails, and if there are members of the group as topic_allowed_users
then that complicates things and causes odd behaviour.
We also ensure that the OP of the topic is not removed from
the topic_allowed_users when a group they belong to is added,
as it will make it harder to add them back later.
* DEV: allow composer option to skip jumping to a post on save
* DEV: refactor js safe access in jump logic
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
