Include the enable_filtered_replies_view site setting in the admin UI
Adds title label to in-reply-to widget
Invokes the filtered UI when using replies_to_post_number as a query
parameter
Replaces the "Show All" button icon
Fixes grammar for "Viewing 1 reply to..." label
Being that system badges ship with every instance of Discourse, we've opted to define the name, description, and long description in our locales files to promote translation into other languages. When an admin visited the overview page of a system badge in their admin panel, they were met with disabled inputs for these text properties. The problem is that we failed to educate the admin that the text needs to be managed via the site text customization settings.
This change adds a small "Customize Text" link under theses inputs that takes the admin to the specific site text customization where they can make desired changes.
You can let non-staff users use shared drafts by modifying the `shared_drafts_min_trust_level` site setting. These users must have access to the shared draft category.
Force pushing a commit to a theme repository used to break the updater,
because the system was not able to count the commits behind the old and
new version. This operation failed because a force push deleted the old
commits.
The user was prompted with a simple "500 server error" message.
Themes marked for auto update will be automatically updated when
Discourse is updated. This is triggered by discourse_docker or
docker_manager running Rake task 'themes:update'.
This makes it much easier to check the staff action logs for a specific site setting. A small history icon will appear when hovering over a site setting name. On click, you will be taken to the pre-filtered staff action log for the site setting.
this copy is also shown when viewing invite tabs of other users, so the instructions don't make sense in all cases. shortened it to just say "No invitations to display on this page." users can discover this on their own.
We remove the slow mode composer message and provide better messages when rejecting new posts and edits. The client now validates if the user tries to post again immediately. Finally, we replaced the `hourglass-end` icon with the `hourglass-start` one.
When `must_approve_users` is enabled then staff users assume that all
users will have to be approved manually. But in case of invite we
auto-approve users if they are invited by users. This commit adds an
info on the bottom of invite modal informing staff users that new users
will be auto-approved as soon as they accept invite.
Before deleting a topic that has a high number of views (default of 5000), the user will be prompted with a confirmation popup. This works for all delete buttons on the topic located in: topic-timeline, topic-admin-menu, topic-footer-buttons, and post-menu if the post's ID is 1.
The delete button will be disabled while deletion is in progress, to prevent any unwanted behavior.
A site setting is also available to change the minimum amount of views required to display the confirmation popup.
All kudos are going to @RickyC0626. I only rebased with master and added few qunit tests to ensure that this feature works as expected.
Original PR: #10459
* Move new/edit category modals to its own page
* Fix JS tests
* Minor fixes to new-category UI
* Add mobile toggle
* Use global pretender endpoint so plugins can benefit too
* Alignment fix
* Minor review fixes
* Styling refactor
* Move some SCSS out of the modal
Showing this button is confusing for sites which are using external authentication. Clicking 'log in' already pops up the login modal, which includes a forgot password link when appropriate.
This PR introduces a feature that will detect a date inside the post that a user is bookmarking, and offer that date as an option in the bookmark modal.
The logic is that we get the first date/time detected in the post. If it does not have a time, just a date, then we default to 8:00am for the time.
* FIX: Ensure slow mode duration is correctly edited and displayed.
This commit fixes a bug where you were forced to set hours, minutes, and seconds or you won't be able to set the slow mode. Also, the duration was not displayed correctly due to the seconds not being truncated.
Additionally, we'll always display the hours, minutes, and seconds inputs for clarity and remove the blue banner.
* Set slow mode modal tweaks.
Uses labels instead of placeholders.
Input fields only visible when custom option selected.
Replace "Custom Duration" with "Pick Duration".
Additionally, place the `Set slow mode` button at the bottom of the topic actions menu.
* Perform the slow_mode validation also on the client-side before saving trying to save the post. This way, the post won't be staged.
Adds a new slow mode for topics that are heating up. Users will have to wait for a period of time before being able to post again.
We store this interval inside the topics table and track the last time a user posted using the last_posted_at datetime in the TopicUser relation.
* FEATURE: add penalty options for take action
Add the ability to silence or suspend users from the "take action"
button when moderators are flagging posts. This allows for a more streamlined
active moderation workflow, when moderating against a topic directly.
See https://meta.discourse.org/t/changing-a-users-email/164512 for additional context.
Previously when an admin user changed a user's email we assumed that they would need a password reset too because they likely did not have access to their account. This proved to be incorrect, as there are other reasons a user needs admin to change their email. This PR:
* Changes the admin change email for user flow so the user is sent an email to confirm the change
* We now record who the email change request was requested by
* If the requested by user is admin and not the user we note this in the email sent to the user
* We also make the confirm change email route open to anonymous users, so it can be clicked by the user even if they do not have access to their account. If there is a logged in user we make sure the confirmation matches the current user.
See https://meta.discourse.org/t/changing-a-users-email/164512 for context.
When admin changes an email for a user, we were incorrectly sending the password reset email to the user's old address. Also the new email does not come into effect until the reset password process is done, so this PR adds some notes to the admin to make this clearer.
