* Fix user title logic when badge name customized
* Fix an issue where a user's title was not considered a badge granted title when the user used a badge for their title and the badge name was customized. this affected the effectiveness of revoke_ungranted_titles! which only operates on badge_granted_titles.
* When a user's title is set now it is considered a badge_granted_title if the badge name OR the badge custom name from TranslationOverride is the same as the title
* When a user's badge is revoked we now also revoke their title if the user's title matches the badge name OR the badge custom name from TranslationOverride
* Add a user history log when the title is revoked to remove confusion about why titles are revoked
* Add granted_title_badge_id to user_profile, now when we set badge_granted_title on a user profile when updating a user's title based on a badge, we also remember which badge matched the title
* When badge name (or custom text) changes update titles of users in a background job
* When the name of a badge changes, or in the case of system badges when their custom translation text changes, then we need to update the title of all corresponding users who have a badge_granted_title and matching granted_title_badge_id. In the case of system badges we need to first get the proper badge ID based on the translation key e.g. badges.regular.name
* Add migration to backfill all granted_title_badge_ids for both normal badge name titles and titles using custom badge text.
* If a staff user created only a security key as their single 2FA option. they continued to be prompted to create a 2FA option because we only considered this condition satisfied if a TOTP was added.
* The condition is now satisfied if TOTP OR security keys are enabled.
Instead of enabling `suppress_from_latest` setting on many categories now we can enable `mute_all_categories_by_default` site setting. Then users should opt-in to categories for them to appear in the latest and categories pages.
Previously our index was non unique, causing situations where a user could
have multiple drafts stored in the table for the same exact entity.
This does not properly reflect reality and needed to change as in certain
cases duplicate drafts could be created causing internal data inconsistency
This change adds a message to the admin panel if it detects an api
requests that doesn't use the new header based authentication method.
The message is to warn people to switch to header based auth and links
to the api documention topic on meta for more info.
Issue was mentioned in this [meta topic](https://meta.discourse.org/t/send-a-notification-to-watching-users-when-adding-tag/125314)
It is working well when category is changed because NotifyCategoryChange job already got that code:
```
if post&.topic&.visible?
post_alerter = PostAlerter.new
post_alerter.notify_post_users(post, User.where(id: args[:notified_user_ids]))
post_alerter.notify_first_post_watchers(post, post_alerter.category_watchers(post.topic))
end
```
For NotifyTagChange job notify post users were missing so it worked only when your notification was set to `watching first post`
- Allow revoking keys without deleting them
- Auto-revoke keys after a period of no use (default 6 months)
- Allow multiple keys per user
- Allow attaching a description to each key, for easier auditing
- Log changes to keys in the staff action log
- Move all key management to one place, and improve the UI
These are the changes to tags routing that correspond to the category
routing changes of d84c34ad. The new scheme is:
/tags/c/*slug_path/:id/none/:tag_id/ENDPOINT
/tags/c/*slug_path/:id/none/:tag_id
/tags/c/*slug_path/:id/:tag_id/ENDPOINT
/tags/c/*slug_path/:id/:tag_id
Previously theme translations were loaded along with other plugin API scripts. These run after pre-initializers and initializers when the app boots. This commit moves theme translation loading into pre-initializers, so their behaviour matches core translations more closely.
Previously we could not place extra nav items in a particular order.
This change introduces a new `before` attribute to addNavigationBarItem
with this attribute we can place a nav item before "top" or any other place.
Additionally this allows navigation items to force active state. In some
cases we may want an items that is simply a "filter" on latest using `?query_params`
when we do that we can "force" the filter active.
A concrete example is the assign plugin that adds a nav item for
Unassigned => `/c/cat-slug/l/latest?assigned=nobody&status=open`
If we did not force then latest would be selected even though the filter
is clicked.
This ensures we can very quickly figure out which topics are banners if
a banner is set.
Previously you would have to scan an entire table to find banners
In a category's settings, the Tags tab has two new fields to
specify the number of tags that must be added to a topic
from a tag group. When creating a new topic, an error will be
shown to the user if the requirement isn't met.
The routes for categories are changing. The scheme that I intend to move
us to is:
/c/*slug_path/(:id)/ENDPOINT
/c/*slug_path/(:id)
This commit adds support for the new scheme to the server side without
dropping support for existing URLs. It is necessary to support existing
URLs for two reasons:
* This commit does not change any client side routing code,
* Posts that contain category hashtags that refer to a root category
are baked into URLs that do not fit this new scheme, (/c/[id]-[slug])
* FIX: move attachment_css_class constant out of upload-short-url for discourse-markdown-it
* Use setTimeout instead of ember later
* WIP. Not sure if this worked.
* oneboxer cache in separate file
* Reset onebox cache still
* set functions for oneboxers cache
This is a major change to draft internals. Previously there were quite a
few cases where the draft system would say "draft saved", when in fact
we just skipped saving.
This commit ensures the draft system deals with draft ownership handover in
a predictable way.
For example:
- Window 1 editing draft
- Window 2 editing same draft at the same time
Previously we would allow window 1 and 2 to just fight on the same draft
each window overwriting the same draft over an over.
This commit introduces an ownership concept where either window 1 or 2 win
and user is prompted on the loser window to reload screen to correct the issue
This also corrects edge cases where a user could have multiple browser windows
open and posts in 1 window, later to post in the second window. Previously
drafts would break in the second window, this corrects it.
* DEV: Add the actual "tag_groups/new" route
Allows refreshing the "new" page without an error.
* DEV: Prevent attempts to create group tags if tagging is disabled
* DEV: Refactor the tag-groups controller
Gets rid of `selectedItem`, `selected`, and `selectTagGroup` action.
* DEV: Rename tag-groups-show to tag-groups-edit
* DEV: Refactor tag-groups form
* Extracted the tag-groups-form that's used by tag-groups-new and tag-groups-edit
* The model is now a buffered property
* Serialization relies more heavily on RestAdapter now
* Data is sent as JSON
* Payload is now namespaced ("tag_group")
* Update app/assets/javascripts/discourse/controllers/tag-groups-new.js.es6
Co-Authored-By: Joffrey JAFFEUX <j.jaffeux@gmail.com>
* Update app/assets/javascripts/discourse/components/tag-groups-form.js.es6
Co-Authored-By: Joffrey JAFFEUX <j.jaffeux@gmail.com>
* Update app/assets/javascripts/discourse/controllers/tag-groups-edit.js.es6
Co-Authored-By: Joffrey JAFFEUX <j.jaffeux@gmail.com>
* Require q param in /tags/filter/search route.
* If not provided this route was causing a 500 error when
DiscourseTagging.clean_tag was called, because .downcase
was being called on the param (which was nil).
* Now return a 400 error instead.
