In one of the discourse narrative bot tutorial steps, we show the user a
few links and ask them to copy one and paste it in a reply to teach them
about oneboxes. In order to prevent the links from getting oneboxed in
the bot's post, we enclose them in `<>` which makes the links render
as-is without oneboxing.
However, if an admin attempts to customize via site texts the tutorial
step about onebox, the links enclosed in `<>` get removed completely
from the step content because they're interpreted as HTML tags when the
text override goes through sanitization (see [relevant
code](424da95128/app/models/translation_override.rb (L73-L74))).
To prevent that, this commit changes the default content for the onebox step
to use the `[]()` syntax which doesn't get sanitized and also doesn't
get oneboxed.
Internal topic: t/147912.
This feature allows admins to find what they are
looking for in the admin interface via a search modal.
This replaces the admin sidebar filter
as the focus of the Ctrl+/ command, but the sidebar
filter can also still be used. Perhaps at some point
we may remove it or change the shortcut.
The search modal presents the following data for filtering:
* A list of all admin pages, the same as the sidebar,
except also showing "third level" pages like
"Email > Skipped"
* All site settings
* Themes
* Components
* Reports
Admins can also filter which types of items are shown in the modal,
for example hiding Settings if they know they are looking for a Page.
In this PR, I also have the following fixes:
* Site setting filters now clear when moving between
filtered site setting pages, previously it was super
sticky from Ember
* Many translations were moved around, instead of being
in various namespaces for the sidebar links and the admin
page titles and descriptions, now everything is under
`admin.config` namespace, this makes it way easier to reuse
this text for pages, search, and sidebar, and if you change it
in one place then it is changed everywhere.
---------
Co-authored-by: Ella <ella.estigoy@gmail.com>
In the past we had logic to automatically set the search context to the current topic during the tutorial. This hasn't worked for a long time, and clearly people have still been able to complete the tutorial. In fact, it's probably better for us to teach people how to use the search un-assisted anyway.
This commit removes the dead logic, and makes a slight tweak to the copy in the unlikely event of confusion.
Why this change?
Instead of manually loading files, we should just structure the plugin
so that it relies on Rails autoload strategy and avoid all the manual
`require_relative`s.
What does this change do?
1. Structure the plugin to use Rails autoloading convention
2. Remove onceff jobs that were added 5-6 years ago. There is no need to
carry these jobs anymore after such a long time.
3. Move setting of `SiteSetting.discourse_narrative_bot_enabled` to
`false` in the test environment from core into the plugin.
This commit removes any logic in the app and in specs around
enable_experimental_hashtag_autocomplete and deletes some
old category hashtag code that is no longer necessary.
It also adds a `slug_ref` category instance method, which
will generate a reference like `parent:child` for a category,
with an optional depth, which hashtags use. Also refactors
PostRevisor which was using CategoryHashtagDataSource directly
which is a no-no.
Deletes the old hashtag markdown rule as well.
