This change ensures native push notifications respect the site setting for push_notification_time_window_mins. Previously only web push notifications would account for the delay, now we can bring more consistency between Discourse in browser vs Hub, by applying the same delay strategy to both forms of push notifications.
See: https://meta.discourse.org/t/cant-edit-topic-with-poll-bug-occurs/320845?u=merefield
When the Poll is set to "results ON_CLOSE", vote numbers for each option are only streamed to the browser when the vote is Closed. It is therefore not possible to render the Results.
The current issue is that when you refresh the page, for those that have voted the default view is results. For this type of poll this should NOT happen. The Results view in this mode should not be possible to see until closure, even for the Author.
Because the votes are not yet serialised when this kind of poll remains open, an attempt to display results causes a JavaScript exception and in any case does not make logical sense.
So the fix here is making sure the default view, for Polls that have results on close, is the voting view until the Poll is Closed.
I've added a test to cover this scenario.
Additionally, this requires a refresh of the page when the poll admin actions a Close to ensure the results are serialized in.
Initially, the poll results display a maximum of 25 voters per option. If the number of voters exceeds this limit, a button allows users to load additional pages of voters.
When this button is clicked, a method is called to retrieve the additional voter information. However, there was a bug where the local tracked object was not properly updated for ranked choice voters. This is due to the existence of two attributes per option: one indicating whether new data is currently loading, and the other containing the list of voters.
Instead of updating the entire option key with the voters list, the fix requires updating the voters attribute only.
This is a small but critical change. The pull request also includes a new test that significantly increases coverage, addressing this issue and beyond.
### Why?
Before, all flags were static. Therefore, they were stored in class variables and serialized by SiteSerializer. Recently, we added an option for admins to add their own flags or disable existing flags. Therefore, the class variable had to be dropped because it was unsafe for a multisite environment. However, it started causing performance problems.
### Solution
When a new Flag system is used, instead of using PostActionType, we can serialize Flags and use fragment cache for performance reasons.
At the same time, we are still supporting deprecated `replace_flags` API call. When it is used, we fall back to the old solution and the admin cannot add custom flags. In a couple of months, we will be able to drop that API function and clean that code properly. However, because it may still be used, redis cache was introduced to improve performance.
To test backward compatibility you can add this code to any plugin
```ruby
replace_flags do |flag_settings|
flag_settings.add(
4,
:inappropriate,
topic_type: true,
notify_type: true,
auto_action_type: true,
)
flag_settings.add(1001, :trolling, topic_type: true, notify_type: true, auto_action_type: true)
end
```
Adds a new statistics (hidden from the UI, but available via the API) that tracks daily participating users.
A user is considered as "participating" if they have
- Reacted to a post
- Replied to a topic
- Created a new topic
- Created a new PM
- Sent a chat message
- Reacted to a chat message
Internal ref - t/131013
* FEATURE: Change tags sent in topic_tags_changed trigger in discourse_automation
Before, it was sending the old tags and the current tags in topic.
Now, it sends the removed tags and the added tags in the topic.
* DEV: update `missing_tags` to be `removed_tags`
* DEV: add spacing for better readability
This commit continues on work laid out by 6039b513fe to redesign the /about page. In this commit, we add sections for showing the site admins and moderators.
The lists of admins and moderators display the 10 most recently seen admins/moderators, with a button to display the rest of admins or moderators. Admins or moderators that have not logged in to the site in the last year will not be shown. Clicking on an admin's or moderator's name/avatar will show their user card.
e.g.
```
WARNING: Binding style attributes may introduce cross-site scripting vulnerabilities; please ensure that values being bound are properly escaped. For more information, including how to disable this warning, see https://deprecations.emberjs.com/v1.x/#toc_binding-style-attributes. Style affected: \"height: 60px\"
```
This message indicates broken behavior, so it should be an error rather than a warning.
An early-return is added, so that we don't even attempt to make the modification. This will make the behavior consistent, and easier to understand.
Also updates the normalization logic to use the resolver's own logic. This will handle all sorts of normalization in addition to our deprecations.
In development, Ember raises an error when previously-used values are updated during a render. This is to avoid 'backtracking', where parts of templates have to be re-rendered multiple times. In general, this kind of pattern should be avoided, and Ember's warning helps us do that.
However, for the deprecation warning banner, it is quite reasonable for some rendering to trigger a deprecation, and thereby require the global-notice to be re-rendered. We can use our `DeferredTrackedSet` to achieve that. Its `.add` method will delay adding an item to the Set until after the current render has completed.
e.g. we map `controller:composer` to `service:composer` in resolver lookups. So, when doing the cache check in modifyClass, we need to check against the normalized name, not the deprecated name.
Very similar to move up/down flag problem fixed here - https://github.com/discourse/discourse/pull/28272
Those are the steps to toggle the flag:
1. click toggle - `saving` CSS class is added;
2. request to backend;
3. `saving` CSS class is removed.
And check if the flag was toggle was:
```ruby
def has_saved_flag?(key)
has_css?(".admin-flag-item.#{key}.saving")
has_no_css?(".admin-flag-item.#{key}.saving")
end
```
If the save action is very fast, then the saving class is removed before the first check.
Therefore I decided to invert it, and once action is finished add `saved` CSS class.
Then we can have a quick positive check:
```ruby
def has_saved_flag?(key)
has_css?(".admin-flag-item.#{key}.saved")
end
```
