Admin pages that are based off the customize or plugin templates were wrapped in the `admin-container` class, which has slightly different margins to the `admin-config-page` class, which is used on most admin pages.
This change ensures that all the admin pages have the same alignment.
Update the header of the admin Logs page to be more consistent with the rest of the admin UI.
The tabs to access the different sub-pages have also been updated.
The heading role on topic lists is desirable for screenreader users
because they can easily navigate from heading to heading.
Having this role on the link tag directly becomes problematic for Voice
Control users on Apple devices because unfortunately Voice Control
assumes that when given the role of a heading, it is not a link. This
makes it difficult to click.
This PR moves the heading role to the link's wrapper. This change allows
for heading-to-heading navigation for screenreaders, and also makes it
easier to click using Voice Control. The end result is that topic lists
are both navigable for screenreaders and Voice Control users.
* Do not offer "categories with latest" option anymore, it does
not look good with our default Sidebar selection
* Display a sensible item in the dropdown if the admin has not
chosen hot, latest, or category_boxes as the homepage style,
before it was broken. Now we show Custom with a little blurb
about whether topics or categories are shown, and what the landing
page is
Update the header of the admin Email Style page to be more consistent with the rest of the admin UI.
The HTML/CSS tabs have also been updated, which required an extra check being added to the NavItem component.
There are a few changes here to make the Emails admin page more consistent with the rest of the admin UI.
- The header and navigation menu have been updated.
- The sidebar now stays highlighted when visiting the email admin sub-pages.
- Moved the Template editor from /admin/customize/email_templates to /admin/email/templates, so it fit as a sub-page.
- Removed the link to the Template editor from the Customize section of the old top menu, since it's accessible from the Emails section, instead.
When clicking the "new features" notification item for
admins that navigates to /whats-new, the user notification
menu was not closing. This was happening because inside
the UserMenu::Menu component, the `routeDidChange` event
was firing and calling `closeUserMenu()`, however this is already
called inside the `Header` component via `toggleHamburger()`.
This is _only_ happening for the "new features" notification
item, other items have already been destroyed and they do not get
the `routeDidChange` event. No idea why, but this fixes the issue
in a global way.
Not sure why, but it looks like this `z-index: -1` on the composer
causes iOS to crash super quickly when pinch zooming . This change was
introduced in 07e5f8907e2a8de27c42c2d6f5a02fc153212288 and is not
strictly necessary, let's try removing.
In 0ed4b09527857d7751dba7fb2d765e08bf46a65e, this code was moved into
app.js, which means it actually ends up running after all the other
imports have been completed. That's too late, and some deprecations are
triggered before that.
This commit moves `setupDeprecationWorkflow` back into its own module,
with a 'side effect only' import from `app.js`.
Small refactor to move the `DComposerPosition` component to be a
function used on the `setupEditor` editor lifecycle, so it's
recycled/re-added whenever the editor component is mounted.
Additionally, we reference the passed `editor` instead of the
`event.target`, allowing a `contentEditable` editor (which is a DOM
tree) to still work with the positioning hack.
Reported here:
https://meta.discourse.org/t/quoting-a-closed-topic-prefills-category-in-composer-that-should-be-off-limits/260009
Currently, if someone tries to quote a topic they don't have permission
to reply to, we'll open a new topic composer with the quote so they can
"continue the discussion". When doing this, we populate the current
category, even if the user doesn't have permission to post in it.
This is misleading, as when the user attempts to submit their topic they
get an error because they lack the category permissions.
This change checks the category permissions before populating it.
Deprecates `TopicStatusIcons`. Use "after-topic-status" plugin outlet instead.
Replaces both the widget and gjs header implementations with a new gjs topic-status component.
Our test suite now shows no deprecation counts from official
themes/plugins for the FA6 upgrade, and we've done a few rounds of
removing these in direct references & known settings, so it's time to
enable the admin banner.
Adds a loading state to prevent multiple requests when clicking the
drafts menu button.
We are also making a very slight adjustment to button spacing (needed
for both desktop and mobile).
This change updates the header of the admin Components page to be more consistent with the rest of the admin UI.
The Themes and Components pages share the same templates, so this change switches the header based on which tab is active.
This PR addresses an issue where the dropdown container width was
inconsistent, resizing based on its content.
**Changes included:**
- Added a fixed width for the dropdown container.
- Adjusted margin spacing by applying it to the `.identifier` class
instead of `.name`. This prevents awkward spacing when either contains a
large number of characters.
Internal topic: /t/143862
This removes the viewing action type mixin. It was previously setting a
property `userActionType` on the user controller but this property was
actually removed since https://github.com/discourse/discourse/pull/4771
(Mar 2017) and doesn't seem referenced anywhere else.
It also sets the same property on the user activity controller and this
is a 1-liner so I've opted to duplicate that across the routes that need
this.
`discourse-common` was created in the past to share logic between the
'wizard' app and the main 'discourse' app. Since then, the wizard has
been consolidated into the main app, so the separation of
`discourse-common` is no longer useful.
This commit moves `discourse-common/resolver` into `discourse/resolver`,
adds shims for the imports, and updates existing uses in core.
`discourse-common` was created in the past to share logic between the
'wizard' app and the main 'discourse' app. Since then, the wizard has
been consolidated into the main app, so the separation of
`discourse-common` is no longer useful.
This commit moves `discourse-common/(lib|utils)/*` into
`discourse/lib/*`, adds shims for the imports, and updates existing
uses in core.
The "Tag Groups Form" component was using group names to handle
permissions. This works just fine when the default locale is "English"
but breaks as soon as it's changed to a different locale.
The fix is to use the group id's for handling the permissions instead of
the group name.
Reported in https://meta.discourse.org/t/221849
In the groups page (/g) where we list all the groups, we were only
showing one group "name" per group. If a full name was set, we would
show it, otherwise we would show the group's "display name".
This was somewhat inconsistent because we only show the group's names
in all the various controls we use to filter/search by group.
Plus we used a slightly different logic when displaying the names of a
group on the "group page".
So I updated the "GroupsInfo" component to show either 1 or 2 names
depending on whether a full name is set, and it's different from the
display name or the name of the group.
I used this component in the "group page" so the names will be
consistent between the "groups page" and the "group page".
Also renamed the "GroupsInfo" component to "GroupInfo" since it only
ever deals with 1 group at a time.
Ref - https://meta.discourse.org/t/-/345415
---
## When "full name" differs from the "group's name"
(cf. `@admins`, `@staff`, and `@moderators`)
<img width="1250" alt="Screenshot 2025-01-09 at 15 56 29"
src="https://github.com/user-attachments/assets/f8a0ecdd-2715-40d9-a1ed-26288f638d9f"
/>
## When "full name" is the same as the "group's name"
When `unicode` is allowed in usernames, then the group's full name is
the same as the group's name, so we only show one name.
<img width="1249" alt="Screenshot 2025-01-09 at 16 25 53"
src="https://github.com/user-attachments/assets/03438fbd-04f1-4672-91d5-bd6af2b32475"
/>
`discourse-common` was created in the past to share logic between the
'wizard' app and the main 'discourse' app. Since then, the wizard has
been consolidated into the main app, so the separation of
`discourse-common` is no longer useful.
This commit moves `discourse-common/helpers/*` into
`discourse/helpers/*`, removes `discourse-common` from the Ember
resolver config, and adds shims for the imports.
This change adds a new dropdown trigger next to the "New Topic" button.
When clicked a menu will display a list of topic/post drafts that can be
clicked to resume the draft within the composer.
The "New Topic" button will no longer change text to show "Open Draft"
when a draft topic exists, it will still attempt to load the existing
draft if one exists (this will change later when we support multiple
drafts in a separate PR).
The "My Posts" link in desktop sidebar will now be "My Drafts" and only
appear when the current user has existing drafts.
