This reverts commit 766ff723f8.
Ensure that we create the sidekiq log file first before opening it for
logging. This avoids any issue of the log file not being present when we
initialize an instance of the `Logger`.
Some pages like new/edit item should not display admin header. New attribute called `@shouldDisplay` was added.
As a proof of concept, the flags page was updated.
This PR resolves an issue where the "Experimental" badge would break onto a new line when the title was too long, causing the badge text to separate from the icon. The fix ensures the badge text and icon remain aligned, even with longer titles.
In 6cafe59c76, we added a monkey patch to
`Unicorn::HtppServer#murder_lazy_workers` to log a message and send a
`USR2` signal to the Unicorn worker process when they Unicorn worker
process is 2 seconds away from being timed out by the Unicorn master
process. However, we ended up loggging multiple messages and sending
multiple USR2 signal during the 2 seconds before the Unicorn worker
process hit the time out.
To overcome this problem, we will now set an instance variable on the
`Unicorn::Worker` instance and use it to ensure that the log message is
only logged once and USR2 signal to the Unicorn worker process is only
sent one as well.
In `Jobs::Base::JobInstrumenter.raw_log`, we were creating an instance
of `Queue` and then pushing messages to the queue before popping it off
the queue in a thread. However, this complexity is not necessary when
we can just write directly to the logger without much overhead. This is
how all logging is done in other parts of the app as well.
We identify and deny blocked crawlers here in anonymous_cache.
Separating the notion of the crawler identifier here lets plugins perform an
override if they perform more advanced detection.
In 806e37aaec, I improved the conflict handling when editing a post to account for title and tags.
This fixes an edge cases when a topic has a hidden tag the current editor can't see. When they submit their edit, we automatically add the hidden tags before checking with the tags stored in the database.
Reported in https://meta.discourse.org/t/341375
Since 3e7f0867ea, I started seeing some specs fail due to the following error
```plain
Error occurred while rendering: top-level application > discourse-root > topic > discourse-topic > topic-navigation > plugin-outlet > plugin-connector > topic-presence-display
/assets/plugins/discourse-presence.js - Uncaught TypeError: Cannot destructure property 'whisperer' of 'this.currentUser' as it is null.
```
For some reasons I can't fanthom, the presence components seem to be rendered even though they're using outlets that are only rendered when a user is signed in... 🤷♂️
Lost too much time trying to reproduce so I ended up adding this `if (!this.currentUser) { return; }` condition to both "presence display" component to (hopefully) fix these flakes.
This change creates a shallow copy of the public message channels so we don't change the original array while sorting.
Without this change the publicMessageChannels getter cache gets invalidated and cached again with the sorted channels array instead, which causes a bug where the sidebar channel list sorting order is updated by activity when user interacts with the chat drawer.
We've seen in some communities abuse of user profile where bios and other fields are used in malicious ways, such as malware distribution. A common pattern between all the abuse cases we've seen is that the malicious actors tend to have 0 posts and have a low trust level.
To eliminate this abuse vector, or at least make it much less effective, we're making the following changes to user profiles:
1. Anonymous, TL0 and TL1 users cannot see any user profiles for users with 0 posts except for staff users
2. Anonymous and TL0 users can only see profiles of TL1 users and above
Users can always see their own profile, and they can still hide their profiles via the "Hide my public profile" preference. Staff can always see any user's profile.
Internal topic: t/142853.
Followup 35ecd0335c
Since we have the moderators_manage_categories_and_groups setting,
more than admins can manage groups, so we need to allow others to
see this Automatic tooltip as well.
Also fixes an inconsistency with canManageGroup between the User
model and Group controller, the latter is correct, allowing management
of automatic groups if can_admin_group permission is true
The modal was disabling body scroll lock and select-kit collection was not whitelisted which was preventing users to be able to scroll a select-kit collection on iOS.
It's been set to this value as a workaround for long thread titles, but we now have standalone thread titles in the thread body which makes this not needed. People had troubles understanding why they couldn't resize more the thread panel.
Some users are seeing consistent "Error 5" crashes in chrome when saving/deleting bookmarks on chat messages.
When crash logging is enabled, the message is:
`[33466:259:1206/122312.195048:ERROR:ax_object.cc(3400)] Check failed: !NeedsToUpdateCachedValues(). Stale values: "Group" axid#7543 <svg#discourse-emojis> needsToUpdateCachedValues/disallowed isIgnored inUserAgentShadowRoot:<use> isInert needsToUpdateChildren hasDirtyDescendants`
This seems to be influenced by a few factors, including the re-render of the bookmarks button, the adjacent 'reactions' button, and also the opening/closing of the modal.
Adding this `activeElement.blur` seems to avoid the issue in my manual testing. Hopefully, this can be dropped after future chrome releases.
Internal topic: t/143485
Currently when copy an OP to another topic, the link is to the topic that wasn't moved. The notification should instead be to the new topic the OP was moved to -- we have duplicate logic already for this but first post creation get special treatment, and this applies the same treatment.
Follow up to #28630 which added the tooltip on automatic group.
It was missing a check to ensure the current user is an admin, since only admins can manage automatic groups.
Reported in https://meta.discourse.org/t/324215 by @moin-Jana
Follow up to #30127.
Normally when viewing a channel with tracked threads, we dismiss the blue dot next to the channel name even though the thread has not been read yet.
This change applies the same criteria to determine if we should bold the channel name.
This is a follow-up to e6fdfcdcd2 which
did not remove the site setting from `config/site_settings.yml` and drop
the site setting value from the database.
Follow-up from this commit - 9b8af0ea9f
Adds helpful data into MovedPost records for later lookup. ALSO fixes notifications for freeze_original to point to the newly created post, not the moved post.
