This PR removes the user reminder topic timers, because that system has been supplanted and improved by bookmark reminders. The option is removed from the UI and all existing user reminder topic timers are migrated to bookmark reminders.
Migration does this:
* Get all topic_timers with status_type 5 (reminders)
* Gets all bookmarks where the user ID and topic ID match
* Loops through the found topic timers
* If there is no bookmark for the OP of the topic, then we just create a bookmark with a reminder
* If there is a bookmark for the OP of the topic and it does **not** have a reminder set, then just
update it with the topic timer reminder
* If there is a bookmark for the OP of the topic with a reminder then just discard the topic timer
* Cancels all outstanding user reminder topic timers
* **Trashes (not deletes) all user reminder topic timers**
Notes:
* For now I have left the user reminder topic timer job class in place; this is so the jobs can be cancelled in the migration. It and the specs will be deleted in the next PR.
* At a later date I will write a migration to delete all trashed user topic timers. They are not deleted here in case there are data issues and they need to be recovered.
* A future PR will change the UI of the topic timer modal to make it look more like the bookmark modal.
* DEV - versions of JS files written to a JS file to be included by load-script and appended as params to URLs
* Formatting
* Incorporate feedback from PR
* Update filename of public-js-versions
Admins can currently add the bookmarks discovery route link
to the homepage interface, but users can't presently select
that as their default home view. This change facilitates that,
adding the option to the existing Default Home Page dropdown on
the User Preferences Interface page.
Incorrect search filters like `in:personalasd` will end up checking the
checkbox for `in:personal` because the regexp used was only doing prefix
matching.
This helps us out in a few ways:
1. It lessens our reliance on jQuery
2. It's slightly less code because it omits options we don't use
3. It is one less library to import and put into ES6 modules
eg repro before:
- visit http://pr-discourse.test/top/weekly?f=foo
- select another period in the period chooser
- f=foo was gone
After this commit it should still be present
The emoji-picker is a specific piece of code as it has very strong performance requirements which are almost not found anywhere else in the app, as a result it was using various hacks to make it work decently even on old browsers.
Following our drop of Internet Explorer, and various new features in Ember and recent browsers we can now take advantage of this to reduce the amount of code needed, this rewrite most importantly does the following:
- use loading="lazy" preventing the full list of emojis to be loaded on opening
- uses InterserctionObserver to find the active section
- limits the use of native event listentes only for hover/click emojis (for performance reason we track click on the whole emoji area and delegate events), everything else is using ember events
- uses popper to position the emoji picker
- no jquery code
Like "default watching" and "default tracking" categories option now the "regular" categories support is added. It will be useful for sites that are muted by default. The user option will be displayed only if `mute_all_categories_by_default` site setting is enabled.
Enabling the moderators_manage_categories_and_groups site setting will allow moderator users to create/manage groups.
* show New Group form to moderators
* Allow moderators to update groups and read logs, where appropriate
* Rename site setting from create -> manage
* improved tests
* Migration should rename old log entries
* Log group changes, even if those changes mean you can no longer see the group
* Slight reshuffle
* RouteTo /g if they no longer have permissions to view group
* REFACTOR: Get us closer to no `Discourse` constants in tests
* REFACTOR: Remove `Discourse.currentUser`
* REFACTOR: `prioritizeNameInUx` is really a helper and can use context
* REFACTOR: Rename test
* REFACTOR: Remove `Discourse.MarkdownItURL` and use session
* REFACTOR: Remove unused `LetterAvatarVersion`
* REFACTOR: Remove unused `Discourse.ThemeSettings`
* REFACTOR: Remove unused CDN constants
* REFACTOR: The `globalNotice` property doesn't exist anymore
* REFACTOR: Remove `Discourse.__container__` from plugin api
* REFACTOR: Consider `logout()` a helper and remove container.
For sites that are configured to mute some or all categories and tags
for users by default, groups can now be configured to set members'
notification level to normal from the group manage UI.
When a tab is open but left unattended for a while, the red, green, and blue
pills tend to go out of sync.
So whevener we open the notifications menu, we sync up the notification count
(eg. blue and green pills) with the server.
However, the reviewable count (eg. the red pill) is not a notification and
is located in the hamburger menu. This commit adds a new route on the server
side to retrieve the reviewable count for the current user and a ping
(refreshReviewableCount) from the client side to sync the reviewable count
whenever they open the hamburger menu.
REFACTOR: I also refactored the hamburger-menu widget code to prevent repetitive uses
of "this.".
PERF: I improved the performance of the 'notify_reviewable' job by doing only 1 query
to the database to retrieve all the pending reviewables and then tallying based on the
various rights.
* FEATURE: set notification levels when added to a group
This feature allows admins and group owners to define default
category and tag tracking levels that will be applied to user
preferences automatically at the time when users are added to the
group. Users are free to change those preferences afterwards.
When removed from a group, the user's notification preferences aren't
changed.
