Followup 2a65bf4522
With the above change, we inadvertently made it so that
when you edited the topic title or category, we bumped
the topic.
This fix makes it so we do not bump topics when only title, category,
or tags are changed, to restore the previous behaviour.
In addition, we are making it so the following settings no longer
influence topic bump behaviour, keeping only their intended notification
behaviour around. The site setting description never mentioned anything
about topic bumps:
* disable_category_edit_notifications
* disable_tag_edit_notifications
Context: The `btn` mixin is used for every functional button, but this
includes button elements that are not, or should not be, styled like our
default or primary buttons.
To change how this works this commit:
* stripped down the mixin to the bare essentials, mainly limiting to the
properties that use variables.
* moved most things into the `btn` class
* moved some things into specific descriptive classes (default, danger,
success) such as border-radius
Example of button that does not need a border-radius and would benefit
from this:
<img width="464" height="184" alt="CleanShot 2025-09-19 at 12 56 04@2x"
src="https://github.com/user-attachments/assets/e908b2cf-971f-4c1f-aade-7492bad2f89c"
/>
* Deprecated…
* FlatButton component
* btn-active: we should use the proper pseudoclass :active or a –-active
modifier in code if we need it
* btn-text: every button by default is a btn-text. We already have a
class to indicate when it isn’t (no-text)
* fixed btn-link property to make DButton component behave like an
inline link (no padding, link-styling)
* Since I moved styling from .btn, ths means every button now needs a
specific declaration. So I’ve added btn-default where necessary.
* Fixed btn-flat hover effect: The difference between btn-flat and
btn-transparent was getting very ambiguous. I’ve fixed the hover effect
for btn-flat so that the distinction is:
<img width="1094" height="408" alt="image"
src="https://github.com/user-attachments/assets/addf56a9-1f61-463d-abd9-5028a3b88fad"
/>
* Changed the custom icon colour from header icons so it follows the
normal btn-flat styling, the way the sidebar icon already was doing.
(Consistency)
**Other small button-related change along the way**
What | BC | AC |
|----| ----|--------|
Inconsistent save/cancel colours | <img width="1720" height="1084"
alt="CleanShot 2025-09-19 at 15 31 40@2x"
src="https://github.com/user-attachments/assets/227289c3-6ded-4633-868d-6e33c32d83c3"
/> | <img width="1720" height="1084" alt="CleanShot 2025-09-19 at 15 30
56@2x"
src="https://github.com/user-attachments/assets/b23f96c9-04f3-40ea-9fba-2be59eae8e64"
/> |
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
Allows for surfacing all tags by adding a `every_tag` option to the
`tags` property. This value is then passed to the `everyTag` option on
the `TagChooser` component
Demo:
```yml
type: objects
client: true
default: "[]"
schema:
name: "state"
properties:
tags:
type: tags
min: 2
every_tag: true
```
Defaults to `false` (current behavior)
Some topic buttons or dropdown items are displayed conditionally based
on the viewport width (e.g. via `site.mobileView`). Previously, the
topic-footer-button API wasn't designed to support autotracking.
Instead, it required plugins to pass a list of string-based keys, which
it then attached to a computed property.
This commit updates it to be fully 'autotracking-native'. Old dependent
keys are accessed internally via `.get()` to maintain backwards
compatibility.
Now, dependencies on autotrackable property like `site.mobileView` will
be reflected in real-time.
This commitreworks the validation and handling of color pickers in
the category edit page so they're simpler and more predictable. In
particular:
* It no longer attempts to "autocomplete" 3-digits hex values to the
equivalent 6-digits format -- we now accept both 3 and 6 digits formats
* It no longer disables the save button if the input color value is
invalid. The save button is always clickable, and if the admin attempts
to save with an invalid color value, the form will display errors
explaining which input is invalid and what's wrong with the color value
Internal topic: t/163062.
Reverts discourse/discourse#34639
We understood the main culprit for cookie overflows was storing
`destination_url` in the session, so we don’t really need that debug
code anymore.
We have this slightly awkward UX on the Preferences > Security page, where we offer to remove the password from an account if it has other means of signing in. You need to first click a cryptic Show button which may or may not lead you to the button you want. This button loads the associated accounts so we can evaluate whether to show the Remove password button or not.
This PR loads that data when entering the route, so that we can just show the button up-front. If removing password isn't possible, the button is disabled and shows an explainer underneath.
Before this change, impersonating a user would result in that user's
`last_seen_at` being updated. This PR fixes that for the new
impersonation feature gated behind the `experimental_impersonation` site
setting.
The old impersonation feature that logs in as the impersonated user has
a completely separate code path. If we decide to backport this change it
will be in a separate PR.
We need to initially create a MediaConvert client without an endpoint.
Rather than passing in nil for the endpoint just don't pass the endpoint
parameter at all otherwise you will get an error from aws.
Followup 9a9a0e5c1b
The "Show more" button in the sidebar categories modal was not working
when a root-level category had more than 5 subcategories (e.g., a
grandparent category with 6+ parent categories as children).
Root-level categories have `parent_category_id: undefined`, but the
`findPartialCategories` function was checking `categoriesById.has(id)`
before creating "Show more" buttons. Since `undefined` is never in the
categoriesById map, no button was created for root-level pagination.
The fix adds special handling for `undefined` parent IDs throughout the
component, treating root-level categories as a valid case for
pagination.
When authenticating to aws mediaconvert we need to also allow the use of
`iam_profile` and not just assume `s3_access_key_id` and
`s3_secret_access_key` are being used.
Added subfolder support for #discourse-id automated registration in
874c875e02 but we were missing returning the "path" in the response
from the "discourse_id_challenge".
This ensures we also return the "path" field in the challenge so it can
properly be validatated by id.discourse.com.
Internal ref - t/161934/21
### What is this change?
Scheduled problem checks without trackers weren't being run. This is
because we directly tried to look for trackers instead of going through
the checks.
When overriding, we should keep the breadcrumb and header. This change
ensures consistency with other outlets (webhooks, themes).
See also internal ticket t/161658
Now that `ServerSession` can store arbitrary data, we can move some more
data into it.
This PR moves some data related to authentication into it, as sometimes
that kind of data can be pretty big.
was showing up inconditionnaly even if you didn't have the permissions
to edit other people's comments.
This was only a UX issue as the server is doing the correct check.
The issue was the `hasPermission` method which wasn't a getter so it
wasn't checked for all the instances of the post comments but rather
once.
Also added some acceptance tests to ensure we don't regress.
Internal ref - t/163347
Following the update to v5.100.0, changes to files under `app/static/*`
are no longer reflected live in development mode.
Previously pinned in 712af920ce, but it
was undone by dependabot. This time I've removed the `^` from the
version specifiers, so it shouldn't be auto-upgraded any more.
Long term we're planning to move away from webpack, so it's not worth
the investment to find the cause of the bug.
