To add a components link to the sidebar refactoring was required to create unique URLs for themes and components. Before the query param was used. After changes, we have two URLs `/admin/customize/themes` and `/admin/customize/components`.
Prior to this fix we were manually expanding the composer but not setting the correct height. This commit adds a new `unshrink` function on the composer service to correctly set the state and the height on the composer model.
In discourse-assign the assign menu in the modal is using this `expandedOnInsert` option and was sometimes not opening correctly resulting in a broken state until you click two times on it. This should prevent this issue.
This commit will now change two behaviors:
- If composer is already opened on a specific post and we click on edit again for the same post, we will do nothing and not show the discard draft modal
- if composer is shrinked and we click on edit for the same currently edited post, we will just open the composer and not show the discard draft modal
I needed to run `rake javascript:update_constants` for my previous
commit: 72ac675e4e
The change in this commit though was completely unrelated, so I saved it
for it's own commit.
This fixes a timing issue where, if a user (or the CI) was
on a slow network connection, clicking one of the bookmark
menu options would cause an error because we hadn't yet received
the response from the server after creating the bookmark.
It should be very smooth most of the times because (paraphrasing j.jaffeux):
a) Most likely when user clicks it’s already saved
b) If it’s not saved when user clicks, it should already be almost done so
the perceived wait when click the reminder option should be rather short
The breadcrumbs were updated everytime there were changes to the
categories which was not efficient and caused unnecessary rerendering
of the CategoryDrop elements when "lazy load categories" is enabled.
This commit also ensures that all category fields are serialized for
ancestors too for the categories#search endpoint.
The bulk actions menu for topics has multiple options to work
with tags on topics (append, replace, remove). Our tagging system
along with categories allows for some complicated tag restrictions
to be applied via tag groups. This was a problem for the topic bulk
actions because you couldn't append restricted tags to topics.
This commit allows restricted tags to be used in bulk tagging actions
as long as all selected topics are for a sole category. The category
information will be shown in the modal, and the category ID is used
for the tag search.
Include categories when fetching admin/web_hooks and make
'extras' more useful. 'extras' is the mechanism we use to provide
context for rest objects.
However, previously:
* When you fetched many objects, extras was only set on the ResultSet,
not on each object,
* If you need derived data from extras, there wasn't a sensible place to
put this code. Now, you can create an 'ExtrasClass' static field on
your rest model and this class will be used for your extras data,
This commit changes the identifier displayed in the navigation tree of
the theme objects editor from the generic "category 1" to "<category
name>, <category 2 name>" when a property of typed categories is set as
the identifier.
Example:
For the following theme objects schema:
```
some_setting:
type: objects
default: []
schema:
name: <some scheme name>
identifier: list_of_categories
properties:
list_of_categories:
type: categories
```
If the `list_of_categories` property's value has been set to `category
1` and `category 2`, the navigation tree will display `category 1,
category 2` as the text to represent the object in the navigation tree.
When lazy load categories is enabled, categories should be loaded with
user activity items and drafts because the categories may not be
preloaded on the client side.
This will automatically enable the glimmer header when all installed themes/plugins are ready. This replaces the old group-based site setting.
In 'auto' mode, we check for calls to deprecated APIs (e.g. decorateWidget) which affect the old header. If any are present, we stick to the old header implementation and print a message to the console alongside the normal deprecation messages.
To override this automatic behavior, a new `glimmer_header_mode` site setting can be set to 'disabled' or 'enabled'.
This change also means that our test suite is running with the glimmer header. This unveiled a couple of small issues (e.g. some incorrect `aria-*` and `alt` text) which are now fixed. A number of selectors had to be updated to ensure the tests were clicking the actual `<button>` elements rather than the surrounding `<li>` elements.
This started as a way to prevent "previewUpdated" from doing the same work twice when morphing.
Ended up refactoring "previewUpdated" and extracted into 5 distinct methods for clearer understanding and more consistent debouncing (using the "@debounce" decorator instead of the "discourseDebounce" method).
No "feature" was changed, other than not doing the "decorateCookedElement" when morphing is enabled, since we already did it _before_ morphing.
A lot of plugins are using "api.decorateCookedElement" to decorate the cooked preview.
Some of those plugins, like the "image-grid" ([grid]...[/grid]), changes the DOM. We have to call them _before_ morphing otherwise, there's no real point in morphing the preview.
The missing piece was triggering the "decorate-non-stream-cooked-element" application event.
Chrome's default is already Lax, so this change is a no-op there.
Firefox will soon be follow them, and has started warning about cookies with no samesite attribute. That's the motivation for this commit.
When choosing the "Custom..." option in the new bookmark
menu and then choosing a date + time in the modal for the
reminder, the bookmark icon on the post was not updating to
show the one with the clock to indicate the reminder.
This was just a data syncing issue between BookmarkFormData
and what the modal sets. Ideally all this would be refactored
because the data flow is messy...but hard to find time for
that right now.
Followup 67a8080e33
This commit changes enum typed theme objects property to be optional.
Previously, an enum typed property is always required but we have found
that this might not be ideal so we want to change it.
Display additional confirmation when:
- The public section is going to be updated;
- The public section is going to be deleted;
- The public section is going to be marked as private.
The complexity of the situation is that we don't want to load faker into production by default but fabricators and styleguide are available on production.
This is made possible through app/assets/javascripts/discourse/app/lib/load-faker.js which contains a function to ensure faker is loaded asynchronously (loadFaker) and another function to access the loaded faker (getLoadedFaker).
Note 1: this commit also refactors fabricators to have access to context and use faker where possible
Note 2: this commit moves automation to admin bundle
---------
Co-authored-by: David Taylor <david@taylorhq.com>
It was originally named bootstrap-json because it contacted a 'bootstrap' API in rails to generate the ember-cli html response. However, it has since been overhauled to remove that 'bootstrap' system. Now it is a much simpler proxy server which transforms the HTML sent by Rails.
The bug was due to the fact that the `<DModal />` is displayed inside a if block, when the condition was false to close the menu, the modal was just hidden without calling callbacks. The fix ensures we are correctly calling `modal.close()` before in this case.
This commit adds a new option `@modalForMobile` for `<DMenu />` which allows to display a `<DModal />` when expanding a menu on mobile.
This commit also adds a `@views` options to toasts which is an array accepting `['mobile', 'desktop']` and will control if the toast is show on desktop and/or mobile.
Finally this commit allows to hide the progressBar even if the toast is set to `@autoClose=true`. This is controlled through the `@showProgressBar` option.
This commmit removes the unused `/u/:username/preferences/categories`
route which was merged into the `/u/:username/preferences/tracking`
route in 2fc2d7d828.
Available as a normal synchronous module in tests
Available as an async import in core, or via the `loadFaker` helper in themes/plugins (which cannot use async import directly)
This change adds a progress bar to toast notifications when autoClose is enabled (true by default).
The progress bar allows users to visually see how long is left before the notification disappears.
When hovered on desktop, the progress and autoclose timer will be paused, it will resume again once the mouse is moved away from the toast notification.
Why this change?
For a `typed: objects` theme setting with an enum property, we are
adding a `default` key for `type: enum` fields which will be used
as the default value on the client side.
```
some_objects_setting:
type: objects
schema:
name: field
properties:
enum_field:
type: enum
default: awesome
choices:
- nice
- cool
- awesome
```
Adds the new quick menu for bookmarking. When you bookmark
a post (chat message behaviour will come later) we show this new quick
menu and bookmark the item straight away.
You can then choose a reminder quick option, or choose Custom... to open
the old modal. If you click on an existing bookmark, we show the same quick menu
but with Edit and Delete options.
A later PR will introduce a new bookmark modal, but for now we
are using the old modal for Edit and Custom... options.
When opening the user menu, we display old cached data, and then replace it with fresh data immediately afterwards. The vast majority of the time the data is unchanged, and so there is no visible change. When rendering HTML elements directly, Ember realizes that there is no change, and does not make any changes to the DOM. Great!
However, our `avatar` helper returns a blob of HTML. With raw HTML, Ember does not make any attempt to 'diff' the existing DOM. Instead, it replaces the old string with the new string. That can be a little wasteful, but normally it's not a big deal. But, when it comes to `<img lazy="lazy"`, re-rendering the `img` element causes a visible flicker in Safari.
To work around that, this commit replaces the `{{avatar}}` helper with an ember-rendered `<img` element. Now that Ember is responsible for rendering, it can detect there is no real change to the attributes and skip it, thereby avoiding the flicker.
If we find ourselves doing this more frequently, we may want to consider creating an `<Avatar` component. But for now, I think it's simple enough to justify building the `<img` manually in this case.
The "new topic" route can open the composer with a category preselected.
This commit ensures that the category is loaded before the composer is
opened.
Why this change?
Prior to this change, the input fields were not displaying when adding
an object to a objects typed theme setting which has a default value of
`[]`. This is because the `fields` getter was not being recomputed.
- Add a "Skip tips" button to first notification tip
- Add a "Skip tips" button to the admin guide tip
- Fixes the timeline tip showing when no timeline was present
- Fixes post menu tip showing when no "..." button is present
- Adds system tests
- Marks each tip as seen as soon as it is displayed so that refreshing,
clicking outside, etc. won't show it again
- Change just above means we no longer need a MessageBus track
Co-authored-by: Bianca Nenciu <nbianca@users.noreply.github.com>
Some of the properties, like 'categoriesById', 'parentCategory' and
'subcategories', were updated manually when categories were loaded.
This was not ideal because it required a lot of code to keep the
objects in sync and some of the properties were not updated correctly.
Why this change?
Instead of dealing with a generic object for `Theme#settings`, we want
to always be dealing with `ThemeSettings` objects.` Previously, we
converted the generic objects to `ThemeSettings` objects in the theme's
adapter `afterFindAll` function. This is not correct because updating
or saving the theme individual reverted the `Theme#settings` back to an
array of generic object.
To fix this problem, the proper way with our REST models is to overwrite
the static `munge` method and create `ThemeSettings` instances there.
When a user is manually deactivated, they should not be deleted by our background job that purges inactive users.
In addition, site settings keywords should accept an array of keywords.
Originally we planned to do this rename after dropping the old widget implementation. However, as we continue rolling out the update, there is a risk that people will start depending on the component names (e.g. for modifyClass) so it seems best to make the rename now to reduce risk later.
In this PR, all references in the UI to the word "`upgrade`" are changed to "`update`". This is to differentiate the update process in self-hosted sites from the plan "upgrade" process in hosted sites.
Follow-up to the PR: https://github.com/discourse/docker_manager/pull/208
Prior to this fix the `swipe` modifier could not be disabled and we were not using the `this.dimissable` property to apply/not apply it.
This commit adds a new `enabled` param to the `swipe` modifier, which is used in modals with the value of `this.dismissable`.
Note this commit also adds tests for this modifier.
Why this change?
Before this change, the validation error message shown to the user when
saving a theme objects setting is very cryptic. This commit changes the
validation error messages to be displayed on top of the editor instead.
Note that I don't think this way of displaying is the ideal state we
want to get to but given the time we have this will do for now.
Why this change?
In the categories, groups and tags selectors, we were showing a
validation error message when a property that is not required but
has a min validation is empty. In this case, we should not be displaying
the min validation error message because the property is allowed to be
empty.
Why this change?
When adding a new object, we want to switch to the input fields of the
new object instead of just appending the new object to the list of
objects as we believe this is a better UX flow.
Why this change?
The field components to select categories, groups and tags had quite a
bit of logic duplicated between them. This commit refactors the logic
to remove most of the duplication so that we can introduce changes
without having to make the changes in multiple places.
* DEV: Various bulk-select dropdown tweaks
- Setting is no longer hidden
- descriptions have been moved to the modal
- Removed ... from one of the dropdown titles
... rather than just the category id.
In order for the user to have selected a category, the category must
have been loaded and it's useful for the category chooser to provide
this fetched category so that it doesn't need to be refetched.
In the future, it would be better to store the categories that the
chooser knows about in local component state, so that the category
doesn't need to be fetched from the id map, but this, at least, puts the
API in place.
Why this change?
This is a follow-up to 86b2e3a.
Basically, we want to allow people to select more than 1 group as well.
What does this change do?
1. Change `type: group` to `type: groups` and support `min` and `max`
validations for `type: groups`.
2. Fix the `<SchemaThemeSetting::Types::Groups>` component to support the
`min` and `max` validations and switch it to use the `<GroupChooser>` component
instead of the `<ComboBoxComponent>` component which previously only supported
selecting a single group.
Why this change?
Prior to this change, the `SchemaThemeSetting::Editor#tree` was creating a
new `Tree` instance which holds instances of `Node`. Both classes
consisted of tracked properties. The problem with this approach is that
when any tracked properties is updated, Ember will revaluate
`SchemaThemeSetting::Editor#tree` and because that method always return
a new instance of `Tree`, it causes the whole navigation tree to
rerender just because on tracked property changed.
This rerendering of the whole navigation tree every time made it hard to
implement simple features like hiding a section in
9baa820d53. Instead of being able to just
declare a tracked property to hide/show a section, we end up with a more
complicated solution.
This commit rewrites `SchemaThemeSetting::Editor` to depend on Ember
components to form the tree structure instead. As needed, each component
in the tree structure can declare its own tracked property as necessary.
Why this change?
In cdba864598, we added support for adding
a description which will be displayed under the input of each property
on the client side.
Currently this convention in the locale file is followed:
```
en:
theme_metadata:
settings:
objects_setting:
description: <description> for the setting
schema:
properties:
name: <description for the name property>
links:
name: <description for the name property in link>
url: <description for the url property in link>
```
Since we now want to allow the label to be translated as well, we will
be changing the convention to the following:
```
en:
theme_metadata:
settings:
objects_setting:
description: <description> for the setting
schema:
properties:
name:
label: <label for the name property>
description: <description for the name property>
links:
name:
label: <label for the name property>
description: <description for the name property in link>
url:
label: <label for the url property>
description: <description for the url property in link>
```
If the locale file does not provide a `label` key under the property's
name, the client side will just display the property's name as the
label for the input field.
Applying `overflow: hidden` was not playing well with sticky elements (like the header for example). It appears that we don't really need this to achieve our goal so Im removing this part of body scroll lock for now.
Descriptions for the `category-list`, `file-size-restriction` and `file-types-list` site/theme settings aren't rendered due to a bug that was introduced when those components were migrated to Glimmer components. This commit fixes the bug which is that arguments passed to .gjs components should be accessed as `@argument` and not `this.arugment` inside the `<template>` tag.
This will prevent any scrolling issues with sk when on mobile, especially on iOS and in modals.
Prior to this fix, scrolling could sometimes stop working in dropdowns.
This commit is making the following changes:
- replaces `mobile-keyboard` initializer and `chat-vh` with a new template-less component: `d-vh`
- ensures body scroll lock is released when page/tab focus changes
- correctly locks body on chat channels and chat threads when composer is focused
- removes `bodyScrollFix` as we now use body scroll lock
- `onViewportResize` has been debounced to ensure it's not a bad performance vector
- adds a reverse option do body scroll lock, this is made to support reversed scroll areas (like chat channels and threads)
---------
Co-authored-by: Penar Musaraj <pmusaraj@gmail.com>
Why this change?
This is a follow-up to 86b2e3aa3e.
Basically, we want to allow people to select more than 1 category as well.
What does this change do?
1. Change `type: category` to `type: categories` and support `min` and `max`
validations for `type: categories`.
2. Fix the `<SchemaThemeSetting::Types::Categories>` component to support the
`min` and `max` validations and switch it to use the `<CategorySelector>` component
instead of the `<CategoryChooser>` component which only supports selecting one category.
Prior to this fix the options were not passed down when the user had no default calendar.
No test as it's mostly an interaction between discourse-calendar and core which is hard to test.
This lib will allow us to wait for a keyboard state change. Not waiting for the keyboard to be closed could cause issues when showing a modal at the same time on iOS for example.
Example usage:
- blurSomeInput()
- await waitForClosedKeyboard(this)
- showSomeModal()
Note that this actual behavior has been baked in modals when we call show so you don't have to call the lib yourself.
Why this change?
Previously, we were preloading the necessary metadata for
`adminCustomizeThemes.show.schema` route in the
`adminCustomizeThemes.show` route. This is wasteful because we're
loading data upfront when the objects setting editor may not be used.
This change also lays the ground work for a future commit where we need
to be shipping down additional metadata which may further add to the
payload.
Why this change?
When a property of `type: tags` is required, we should be displaying the
"at least 1 tag is required" validation error message when there are no
tags selected in the `TagChooser` compoment. However, we were passing
`this.min` as the `count` attribute when generating the translation
string which is incorrect as `this.min` is not always set.
This commit mainly improves three things:
- slide up/down animation of the modals on mobile, also allowing swipe down to close the modal
- body scroll locked modals, it means that only the body of the modal can scroll
- a new `<:headerPrimaryAction>` block for `d-modal` which when present will move the cancel button to the left of the modal title, and this primary action to the right of the title
- Converts all header buttons to use `<DButton`
- Updates `<DButton` to render `<a href=` tags when `@href` is passed (previously it was rendering a `<button`, and then using JS to route when clicked)
Why this change?
While working on the tag selector for the theme object editor, I
realised that there is an extremely high possibility that users might want to select
more than one tag. By supporting the ability to select more than one
tag, it also means that we get support for a single tag for free as
well.
What does this change do?
1. Change `type: tag` to `type: tags` and support `min` and `max`
validations for `type: tags`.
2. Fix the `<SchemaThemeSetting::Types::Tags>` component to support the
`min` and `max` validations
Why this change?
Prior to this change, the category selector was not clearable and did
not allow a none value. This is incorrect as the category selector
should be clearable and should allow a none value when the property is
not required.
We are still making improvements to the admin sidebar and
various parts of the admin section. For now, to make the
transition easier, we are moving this link to the top of the
sidebar so it's clear that admins can still get to all settings
if they need to.
Why this change?
Prior to this change, the group selector was using the `<GroupChooser>`
component which is a `<MultiSelectComponent>` and is not ideal in our
situation when we only allow a single group to be selected.
The other problem is that we are doing an async load of the groups when
it is already loaded and available in the `Site` service.
Previously, we had an instant redirect back to the homepage, and clicking avatars would do nothing. This made things feel 'broken' for anon when 'hide_user_profiles_from_public' was enabled.
This commit does a few things to resolve this:
1. Improve our 'exception' system for routes so that developers can deliberately trigger it without an ajax error
2. Improve 'exception' system so that the browser URL bar is updated correctly, and the 'back' button works as expected
3. Replace the redirect-to-home with an 'access denied' error page, with specific copy for 'You must log in to view user profiles'
4. Update user-card logic to display this new page instead of doing nothing on click
There is no need to use an initializer and manually update the DOM when
a Glimmer component can do it and ensure that the DOM is updated as more
categories are being loaded (for example, when lazy loaded categories
are enabled).
Why this change?
This is a continuation of a30d73f255
In our schema, we support the `min` and `max` validation
rules like so:
```
some_objects_setting
type: objects
schema:
name: some_object
properties:
id:
type: float
validations:
min: 5
max: 10
```
While the validations used to validate the objects on the server side,
we should also add client side validation for better UX.
What does this change do?
Since the integer and float input fields share very very similar logic
in the component. This commit pulls the common logic into
`admin/components/schema-theme-setting/number-field.gjs` which
`admin/components/schema-theme-setting/types/integer.gjs` and `admin/components/schema-theme-setting/types/float.gjs`
will inherit from.
Why this change?
This is a continuation of 8de869630f.
In our schema, we support the `min` and `max` validation
rules like so:
```
some_objects_setting
type: objects
schema:
name: some_object
properties:
id:
type: integer
validations:
min: 5
max: 10
```
While the validations used to validate the objects on the server side,
we should also add client side validation for better UX.
