- Add a safeguard until we implement pagination for the index, it
ensures we won't try to load more than 500 automations ever.
- Includes the fields of the automation so we don't have an N+1 and also
filter them in ruby land instead of doing two additional queries
- Ensures a field object in the field serializer is capable to find the
loaded automation associated to it instead of trying to reload it
- Includes pending_automations to avoid an N+1
…Outlet (#32742)"
This reverts commit 707a91243c35ea1693b80249e1c00fb5320f47cb.
This is causing some unexpected re-rendering. Reverting while we
investigate
Fixes for recent regressions:
- da6b82f7767cbeb038dfbebda92a4474626ff1e8
- 2a18834db1cb6b9c8f071eeab8554257336b2802
These tests should stop it happening for a third time 😅
Historically, plugin outlet arguments had to be accessed like
`@outletArgs.foo` in templates, or `this.args.outletArgs.foo` in
javascript. Following this commit, outletArgs will be passed to
connectors at the top level, so they can be accessed like `@foo` in
templates or `this.args.foo` in JS.
`@outletArgs` remains available for compatibility, and there are no
plans to remove it.
For custom classic component connectors, these new arguments may clash
with functions/fields defined on the component class. This rare case
will be automatically detected, protected against, and a deprecation
will be shown.
This avoids making unnecessary database queries when routing to paths
that were positioned below this entry, e.g.
```
curl http://localhost:3000/form-templates
# SELECT 1 AS one FROM "permalinks" WHERE "permalinks"."url" = 'form-templates' LIMIT 1
# …
```
What is the problem?
When we construct the admin search component, we fire off a call to get data from the back-end. When this is done, there's an async callback that re-does the search. This can result in confusing flickering of the results.
This was compounded by a separate issue that caused the data endpoint to be extremely slow if we had two specific plugins installed at the same time. That issue has already been resolved.
The first time we construct the component (and fetch the data) we initialize it with a flag to indicate that data is still loading. Until the data is loaded, we will show the regular loading spinner if the admin starts typing.
On Meta the endpoint takes ~600ms. That countdown starts when you click or use the shortcut, then you need to start typing as well, so this delay shouldn't be a big issue.
`strict_loading` was added to prevent it happening in the future. Few
adjustments had to be made:
- include color_scheme and color_scheme_colors, also for parent and
child themes;
- internal translations were using preload_fields, but it was too deep
to correctly use preloaded tables. I had to pass
`preloaded_locale_fields` manually;
- include theme in color_scheme.
Before:
<img width="663" alt="Screenshot 2025-05-15 at 3 43 47 pm"
src="https://github.com/user-attachments/assets/b55ce11e-80cb-43eb-8e31-940b0e9859f3"
/>
After:
<img width="665" alt="Screenshot 2025-05-16 at 11 29 00 am"
src="https://github.com/user-attachments/assets/f00bac19-f64b-4048-b220-4d0a9d90a929"
/>
The proper fix was to apply what has been reverted in
7558e2c7cd
but we would have to break the API to apply this fix so I will just skip
these specs for now.
This test is about testing that we can set notification_level, which it
does correctly. The rest of the spec was testing some undefined behavior
which is flaky.
I suspect the within is doing a memoization of the preview at a moment
where the emoji has not been rendered yet, when we render the emoji we
might have a different instance of the preview in the within which
doesn't have the emoji.
Im not super confident about this theory, but the within is useless here
so it seems like a good thing to try first.
The error we have is:
```
Failure/Error: super
Playwright::Error:
TypeError: Cannot read properties of null (reading 'namespaceURI')
at eval (eval at evaluate (:313:29), <anonymous>:17:12)
at UtilityScript.evaluate (<anonymous>:320:18)
at UtilityScript.<anonymous> (<anonymous>:1:44)
Call log:
[Screenshot Image]: /__w/discourse/discourse/tmp/capybara/failures_r_spec_example_groups_composer_using_review_media_does_not_flag_a_post_with_an_emoji_250.png
~~~~~~~ JS LOGS ~~~~~~~
ℹ️ Discourse v3.5.0.beta5-dev — https://github.com/discourse/discourse/commits/94932de163 — Ember v5.12.0
DEBUG: For more advanced debugging, install the Ember Inspector from https://chrome.google.com/webstore/detail/ember-inspector/bmdblncegkenkacieihfhpjfppoconhi
Failed to load resource: net::ERR_CONNECTION_REFUSED
~~~~~ END JS LOGS ~~~~~
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:1268:in `raise'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:1268:in `wait_until_resolved!'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:1482:in `value!'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/connection.rb:121:in `send_message_to_server'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/channel.rb:35:in `block in send_message_to_server_result'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/channel.rb:67:in `with_logging'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/channel.rb:34:in `send_message_to_server_result'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/channel.rb:20:in `send_message_to_server'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/javascript/expression.rb:10:in `evaluate'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/channel_owners/js_handle.rb:19:in `evaluate'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright_api/js_handle.rb:46:in `evaluate'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-playwright-driver-0.5.6/lib/capybara/playwright/node.rb:885:in `block in path'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-playwright-driver-0.5.6/lib/capybara/playwright/node.rb:87:in `assert_element_not_stale'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-playwright-driver-0.5.6/lib/capybara/playwright/node.rb:884:in `path'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/element.rb:578:in `inspect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/queries/selector_query.rb:106:in `description'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/queries/selector_query.rb:115:in `applied_description'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/queries/selector_query.rb:180:in `failure_message'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/result.rb:114:in `failure_message'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/matchers.rb:112:in `block in assert_selector'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/matchers.rb:869:in `block in _verify_selector_result'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/base.rb:84:in `synchronize'
./spec/rails_helper.rb:421:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/matchers.rb:868:in `_verify_selector_result'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/matchers.rb:110:in `assert_selector'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/session.rb:774:in `assert_selector'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/rspec/matchers/have_selector.rb:18:in `element_matches?'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/rspec/matchers/base.rb:52:in `matches?'
./spec/system/composer/review_media_unless_trust_level_spec.rb:20:in `block (3 levels) in <main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/session.rb:366:in `within'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/dsl.rb:52:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/dsl.rb:52:in `within_element'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/rspec/matcher_proxies.rb:15:in `within'
./spec/system/composer/review_media_unless_trust_level_spec.rb:20:in `block (2 levels) in <main>'
```
I suspect that by having an integer and not a float sometimes the value
we get is converted to 0.
This is the error we have atm:
```
Failure/Error: measurement = Benchmark.measure { example.run }
expected: 0.75
got: 0.0
(compared using ==)
```
This might not fix it, but it feels right to make this change.
A spec could potentially go so fast that it would attempt to fill in the
input before we have gone through the various redirects resulting in an
error.
```
Failure/Error: super
Playwright::Error:
TypeError: Cannot read properties of null (reading 'namespaceURI')
at eval (eval at evaluate (:313:29), <anonymous>:17:12)
at UtilityScript.evaluate (<anonymous>:320:18)
at UtilityScript.<anonymous> (<anonymous>:1:44)
Call log:
```
Now that we ensure that we have the current final state path we should
avoid this error.
Reported here:
https://meta.discourse.org/t/dashboard-freezes-until-sidebar-is-opened/366402
This is a follow-up to
https://github.com/discourse/discourse/pull/32651, when navigating from
the homepage to admin the hamburger gets force-hidden because we switch
from the dropdown to the sidebar nav but the scrollLock was
unintentionally left behind.
This makes sure we're only messing with hamburger state when the sidebar
is hidden (with ` {{hideApplicationSidebar}}`) and also removes the
scroll lock when the hamburger is force-hidden.
Fixing this everywhere will be a very large undertaking, so we're
deferring it until there is a concrete timeline for it becoming an error
in sass.
In the meantime, we'll be adding a stylelint rule to enforce ordering of
declarations/nested-blocks/mixins, so that will go some way towards
avoiding this deprecation.
Check to see if the user needs to be added to any groups before redirecting. To avoid introducing a CSRF issue, force the user through the normal invite acceptance flow, ensuring there's user interaction before being added to any groups.
This change also tweaks the behaviour of 2e10fe9 to not follow redirects of expired invitations.
Co-authored-by: Krzysztof Kotlarek <kotlarek.krzysztof@gmail.com>
