This change allows us to distinguish between regular user generated chat messages and those created via the Chat SDK.
A new created_by_sdk boolean column is added to the Chat Messages table. When this value is true, we will not include the message in the user summary email that is sent to users.
Prior to this fix the following sequence would cause an overflow:
- open a thread
- expand thread panel to maximum width
- close panel
- reduce window width
- open thread again
- 💥
The fix is now ensuring that we never use or set a width which would cause the main panel + side panel to be larger than the chat container. We also removed the service as it was overkill for this case and it's easier to have all the implementation at one place.
This commit also uses JS animation api to set the width of the panel.
<!-- 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. -->
During migration of Poll plugin from widget basis to glimmer, some functionality was inadvertently dropped:
- A single button should appear instead of the dropdown menu when there is only one valid "poll admin" action
- No button should appear when there are no valid "poll admin" actions for current user
This PR restores the original behaviour and adds test coverage (that didn't exist prior to migration, partly why it wasn't caught earlier)
relates to #27204
related meta topic: https://meta.discourse.org/t/what-is-the-gear-button-under-the-poll-for/315477/2
Prior to this fix we would show the message after a round trip to the server. If you had a too long message error, at this point your input would be empty and we would show an error in chat. It's important to have this server side safety net, but we can have a better UX by showing an error on the frontend before sending the message, that way you can correct your message before sending it and not lose it.
Fixes a flaky test. `afterUpdate` from chart.js is not integrated with the runloop and component lifecycle, as a result we have no guarantee on when it will happen. The easiest change we can do for now is ensuring we actually have the DOM we expect to have, and if not, we exit early.
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: merefield <merefield@gmail.com>
The "migration to Glimmer" has been broken out here from #27155 to make the review process less onerous and reduce change risk:
* DEV: migrates most of the widget code to Glimmer in prep for IRV additions
* NB This already incorporates significant amounts of review and feedback from the prior PR.
* NB because there was significant additional feedback relating to older Poll code that I've improved with feedback, there are some additional changes here that are general improvements to the plugin and not specific to IRV nor Glimmer!
* There should be no trace of IRV code here.
Once this is finalised and merged we can continue to progress with #27155.
Follow up to #27631 to account for group mentions in channels.
We only want to show mentions for groups that are currently mentionable and those that the current user belongs to.
I am changing many of these to notes or resolving them as is,
most of these I have not actively worked on in years so someone
else can work on them when we get to these areas again.
A previous refactor has prevented errors to show correctly. The guilt of the issue is that we were not calling the error variable correctly in the templates.
This commit also adds a spec for this case, and removes the need for `I18n.backend.store_translations` in specs so we don't have to write too much boilerplate each time we write a spec.
We want to allow admins to make new required fields apply to existing users. In order for this to work we need to have a way to make those users fill up the fields on their next page load. This is very similar to how adding a 2FA requirement post-fact works. Users will be redirected to a page where they can fill up the remaining required fields, and until they do that they won't be able to do anything else.
In 53b3d2f0dc we introduced a stricter BBCode Tag parser. It prevents having "values" with spaces when they're not surrounded by a valid pair of quotes.
The `[details=` BBCode Tag is popular enough that it's worth adding a special case for it (especially since it doesn't support other parameters).
This also adds the Finnish pair of quotes.
Context - https://meta.discourse.org/t/details-accepts-only-one-word-as-summary/313019
* DEV: Upgrade Rails to 7.1
* FIX: Remove references to `Rails.logger.chained`
`Rails.logger.chained` was provided by Logster before Rails 7.1
introduced their broadcast logger. Now all the loggers are added to
`Rails.logger.broadcasts`.
Some code in our initializers was still using `chained` instead of
`broadcasts`.
* DEV: Make parameters optional to all FakeLogger methods
* FIX: Set `override_level` on Logster loggers (#27519)
A followup to f595d599dd
* FIX: Don’t duplicate Rack response
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
Gabriel Grubba
David Battersby
Joffrey JAFFEUX
Robert
Kris
Régis Hanol
Discourse Translator Bot
Jarek Radosz
Alan Guo Xiang Tan
ScottMastro
chapoi
Loïc Guitaut
锦心
Krzysztof Kotlarek
Keegan George
Jan Cernik
Martin Brennan
Ted Johansson
pangbo13