Changes made using the ember-native-class-codemod, plus some manual tweaks
Also ensures our implicit injections applied to the prototype immediately. Without this, they will only be applied on the next `.extend()` call, which is now later than the first native-class extension.
When the tooltip items are tooltipItem = [{parsed: {y:12} }, {parsed: {y:10} } ], reducing without a initial value as a number would result in Javascript thinking it is a string. Thanks, Javascript!
There are no tests here yet since this makes use of an external library Chart.js.
Why all the manual setting of `width` and `height`? Without it all ace editors were 0x0, invisible.
Why didn't it affect the tests before? ace-editor tests only confirms that there is an element, theme-settings-editor tests were effectively unit tests before 7317b5a, fk-code test avoids interacting with ace.
Makes it easier to reach the group from the category security
tab, and moves the trash button to the right to avoid misclicks.
Also converts the category permission row to gjs
The `notifications.id` has been migrated to bigint in previous commit
799a45a291. This commit migrates one of
the related columns, `user_badges.notification_id`, to `bigint`.
This commit changes the cutoff number for the admins and mods lists on the new /about page from 12 to 6. If the admins or mods lists are bigger than 6, the about page will display the 6 most recently seen admins/mods, and tuck the rest away behind a "view more" button.
Given we are a single-page-app, we hijack the browser's default behavior
for keyboard shortcuts like End because on long topics (20+ posts) we
need to load the last post before really reaching the end of the page.
However, when the last post is already rendered, the End shortcut
currently does nothing, it takes the user to the start of the last post.
If that post is too long, the user will have to scroll down manually.
This change ensures that if the last post of a topic is already rendered
(whether it is in the viewport or not), pressing End will take the user
to the very bottom of the page.
Note for the reviewer: the test added here is for the general case, it
is too hard to test the case where the last post is already rendered,
that isn't covered here.
In FormKit you can add error on an existing field existing in the DOM, but you can also set an arbitrary error on a virtual field not existing in the DOM.
When revalidating existing data, we are only resetting real fields. This commit adds `removeError(name)` to allow you to manually manage virtual fields. `removeError` is available in the same helpers where `addError` is available.
<!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
Prior to this fix using:
- `replaceText(...)`
- `selectText(..., ..., { scroll: true})`
Wouldn't have the expected behaviour as the scroll from selectText will attempt to save the scroll position and restore it AFTER the replacement happened. This commit allows scroll to be a Boolean or a Number, when a number, it will be used to restore the scrollTop position.
I tried to write tests for this specific behavior but couldn't reproduce the issue in tests.
A follow-up to dd1abf91ef.
Because `ember-cli-deprecation-workflow` relied on `@ember/string` 3.1.1, that was the effective version used in the app.
Turns out there's a compatiblity issue with 4.0.0. Let's lock it to 3.x so we can easily update deprecation-workflow and then we can look into the ember/string issue.
Follow-up to e3ae57ea7a
The previous commit added an `after_create` callback that triggers a refresh for the user directory whenever a `User` record is created. Theoretically, this approach should work, however, there's a gotcha in practice, because during a real user registration, when the `User` record is created in the database, it's not marked as active until the user verifies their email address and the user directory excludes inactive users, so the initial directory refresh triggered by the `after_create` callback becomes pointless.
To make a new user appear in the user directory immediately after sign up, we need to trigger a refresh via an `after_save` callback when they verify their email address and become active.
Currently, `FlagSerializer#short_description` properly provides
`base_path` to its translations, but `FlagSerializer#description` does
not. This breaks the link to guidelines when flagging a post, for
example.
This patch provides `base_path` for `FlagSerializer#description` too.
All those addons import it but didn't have it in their package.jsons. And because the only thing that had it as a dependency (ember-cli-deprecation-workflow) removed it in the latest version, the build breaks.
File it under: a problem we wouldn't have with pnpm :P
Prior this fix a topic created in the future could generate this exception:
```
Job exception: ERROR: a negative number raised to a non-integer power yields a complex result
```
This fix and spec should ensure we don't consider topics in the future as the rest of the `update_scores` function is doing at other places.
In GroupRequestsController, request_count is incorrectly written as
user_count, which causes group member requests to be loaded infinitely
when user_count is greater than request_count.
This check was checking the wrong scope, causing problems in certain edge conditions, for example:
1. Admin adds an "on signup" field that isn't editable after signup.
2. Admin adds a "for all users" field.
3. User goes and fills up the "for all users" field from 2.
4. User is now stuck on the required fields page without any fields showing.
With this change, we only consider "for all users" fields when asking if required custom fields are filled in.
The `notifications.id` column is the most probable column to run out of
values. This is because it is an `int` column that has only 2147483647
values and many notifications are generated on a regular basis in an
active community. This commit migrates the column to `bigint`.
These migrations do not use `ALTER TABLE ... COLUMN ... TYPE` in order
to avoid the `ACCESS EXCLUSIVE` lock on the entire table. Instead, they
create a new `bigint` column, copy the values to the new column and
then sets the new column as primary key.
Related columns (see `user_badges`, `shelved_notifications`) will
be migrated in a follow-up commit.
When searching for site texts for admin using the english
version of the text, previously we would show the english
version in the results _even if_ there was another locale
translated version available when a locale was selected
from the dropdown.
This commit adds a "Only show results in selected locale"
checkbox option which will instead make it so the results
shown are in the target locale, making it easier for translators
to tell when there is actually translations vs. missing tranlsations.
Followup 76c56c8284
The change introduced above made it so the expired
bookmark reminders were cleared when using the bulk
action menu for bookmarks. However this also affected
clearing reminders for bookmarks when sending notifications.
When clearing bookmark reminders after sending notifications,
we take into account the auto delete preference:
* never - The bookmark `reminder_at` date should not be cleared,
and the bookmark is kept.
* clear_reminder - The bookmark `reminder_at` date is cleared and
the bookmark is kept
The `never` option made it so "expired" bookmark reminder show
on the user's bookmark list.
This commit fixes the change from the other commit and only
forces clearing of `reminder_at` if using the bookmark bulk
action service.
If there is a codec issue or something trying to process a video file
for thumbnail generation, uploads could hang indefinitely. This fix
ensures that we continue the upload process even if we encounter an
error trying to generate a thumbnail for it.
If you’re viewing a tag and you switch to a different tag via the sidebar or the tags dropdown, after expanding the info section of the tag page via the wrench button, the info section keeps showing the previous tag's details instead of the new one.
This happens because the tag info section makes an ajax request to load the tag's details, and this request is made inside the `didInsertElement` hook which is only fired once when the component is rendered. To fix this, we need to set the result from the ajax request to null and add a `didUpdateAttrs` hook to trigger another request to load the info of the new tag.
Internal topic: t/134809.