Background: I wanted to see `categories.latest_by` translation in context in a live app but couldn't find it, so I traced it throughout the code.
My step-by-step reasoning for the removal is:
1. `categories-only` does not use `latestTopicOnly`, so there's no need to call it with that argument
2. `parent-category-row` is never called with `latestTopicOnly` argument, so the reference to that arg can be removed from its template
3. after that, `featured-topic` is now no longer ever called with `latestTopicOnly` argument (except in the `ghost` theme, but that's because its override of `categories-only` template 4e2fba963c/common/header.html (L119) is based on the old version of that template from core), so it seems safe to remove it there too (`categories.latest_by` i18n string is also no longer needed)
4. then, nothing is using `latestTopicOnly` anymore so it can be removed from `categories` hbs/js
I checked in each step that there are no plugins or themes (in all-the-plugins/all-the-themes) using those properties/arguments/strings.
After this, the only remaining issue preventing Discourse from booting on apple silicon is mini_racer/libv8. See upstream discussion at https://github.com/rubyjs/mini_racer/pull/186 for an experimental solution.
This change fixes an issue with the user group chooser of a tag group's settings. It was impossible to clear any selected groups through the UI.
The `setPermissionsGroups` function determines which groups appear selected in the group-chooser based on the passed-in `groupIds` array.
It starts with `updatedPermissions` being set to the group permissions as they were prior to the action that called the function. From there, we were correctly adding a group permission to `updatedPermissions` whenever a group appeared in `groupIds`. This addressed newly added groups and also maintained any group permissions that had been set before. The problem was that there was no logic to remove a group permission when the associated group no longer appeared in `groupIds`. If a group isn't included in `groupIds`, we can simply attempt to delete an associated group permission if it exists.
The user summary's delete button UX relied on the "admin-user.js" destroy function, which was called through the "admin-tools" service. After #11724, we no longer put UX behavior on Ember models.
User title in the current-user header-dropdown was sometimes `title="null"` if user doesn’t have a name. This is fixed as part of this commit to improve accessibility of this part of the UI.
Includes:
* FIX: Don't override computed properties
* FIX: Prevent a set-after-destroy error
* FIX: Get rid of select-kit deprecations
* FIX: Replace removed admin-group-selector
* FIX: Provide onChange action to fix warnings
* FIX: Remove an element with an invalid id
* DEV: Remove topic-notifications-button from dropdowns
It has its own styleguide section under "Molecules".
* UX: Styleguide tweaks
* DEV: Make the dropdowns useable
Run the 'MigrateSearchDataAfterDefaultLocaleRename' post migration in batches of 500k records.
This will hopefully prevent any potential deadlocks on large tables.
Not when doing a site-wide search like we do in the Directory.
This solves the following specfailure:
1) DirectoryItemsController with data finds user by name
Failure/Error: expect(json['directory_items'].length).to eq(1)
expected: 1
got: 0
(compared using ==)
# ./spec/requests/directory_items_controller_spec.rb:88:in `block (3 levels) in <main>'
# ./spec/rails_helper.rb:271:in `block (2 levels) in <top (required)>'
# ./bundle/ruby/2.7.0/gems/webmock-3.11.1/lib/webmock/rspec.rb:37:in `block (2 levels) in <top (required)>'
When doing a user search (eg. when mentioning a user) we will not prioritie
users who hasn't been seen in over a year.
REFACTOR the user-search specs to be more precise regarding the ordering
This cookie is only used during login. Having it persist after that can
cause some unusual behavior, especially for sites with short session
lengths.
We were already deleting the cookie following a new signup, but not for
existing users.
This commit moves the cookie deletion logic out of the erb template, and
adds logic and tests to ensure it is always deleted consistently.
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
A simplified version of the logic used in the function before my fix is as follow:
```ruby
result = []
things = [0,1,2,3]
max_values = 2
every = (things.size.to_f / max_values).ceil
things.each_with_index do |t, index|
next unless (t % every) === 0
result << t
end
p result # [0, 2]
# 3 doesn’t get included
```
The problem is that if you get unlucky two times you won't get last tuple(s) and might get a very erroneous date.
Double unlucky:
- last tuple index % computed every !== 0 and you don't get the last tuple
- the last tuple is related to a post with a very different date than the previous tuples (on year difference in our case)
Lots of changes but it's mostly a refactoring.
The interesting part that was fix are the 'load_problem_<model>_ids' methods.
They will now return records with no search data associated so they can be properly indexed for the search.
This "bad" state usually happens after a migration.
