The clientside allowPersonalMessages function introduced
in e62e93f83a sometimes did not
work correctly, because the currentUser.groups property
only contained **visible** groups for the current user, which
could exclude auto groups that had their permissions set to
be owner-only visible.
It was unnecessary to add this anyway since we already have
can_send_private_messages on the CurrentUserSerializer. It's
better the backend does this calculation anyway. Use that
in the clientside code instead and get rid of allowPersonalMessages
This will replace `enable_personal_messages` and
`min_trust_to_send_messages`, this commit introduces
the setting `personal_message_enabled_groups`
and uses it in all places that `enable_personal_messages`
and `min_trust_to_send_messages` currently apply.
A migration is included to set `personal_message_enabled_groups`
based on the following rules:
* If `enable_personal_messages` was false, then set
`personal_message_enabled_groups` to `3`, which is
the staff auto group
* If `min_trust_to_send_messages` is not default (1)
and the above condition is false, then set the
`personal_message_enabled_groups` setting to
the appropriate auto group based on the trust level
* Otherwise just set `personal_message_enabled_groups` to
11 which is the TL1 auto group
After follow-up PRs to plugins using these old settings, we will be
able to drop the old settings from core, in the meantime I've added
DEPRECATED notices to their descriptions and added them
to the deprecated site settings list.
This commit also introduces a `_map` shortcut method definition
for all `group_list` site settings, e.g. `SiteSetting.personal_message_enabled_groups`
also has `SiteSetting.personal_message_enabled_groups_map` available,
which automatically splits the setting by `|` and converts it into
an array of integers.
If a widget toggles between displaying two different RenderGlimmer instances, the Widget framework treats them as the same, and so `update()` is called rather than destroy/init. This commit detects this scenario and manually destroys/inits to ensure the correct component is being rendered.
This will allow consumers to inject it using `site: service()` in preparation for the removal of implicit injections in Ember 4.0. `site:main` is still available and will print a deprecation notice.
This will allow consumers to inject it using `currentUser: service()` in preparation for the removal of implicit injections in Ember 4.0. `current-user:main` is still available and will print a deprecation notice.
This allows an arbitrary Glimmer template to be rendered inside a Widget. That template can include any kind content, including Classic Ember components and Glimmer components. This leans on Ember's official `{{#in-element}}` helper which means that all component lifecycle hooks are called correctly.
This is a modern replacement for our existing `ComponentConnector` implementation. We'll deprecate `ComponentConnector` in the near future.
Example usage:
```javascript
// (inside an existing widget)
html(){
return [
new RenderGlimmer(
this,
"div.my-wrapper-class",
hbs`<MyComponent @arg1={{@data.arg1}} />`,
{
arg1: "some argument value"
}
),
]
}
```
See `widgets/render-glimmer.js` for documentation, and `render-glimmer-test` for more example uses.
The `unread_not_too_old` attribute is a little odd because there should never be a case where
the user's first_unread_at column is less than the `Topic#updated_at`
column of an unread topic. The `unread_not_too_old` attribute is causing
a bug where topic states synced into `TopicTrackingState` do not appear
as unread because the attribute does not exsist on a normal `Topic`
object and hence never set.
* Use QUnit `module` instead of `discourseModule`
* Use QUnit `test` instead of `componentTest`
* Use angle-bracket syntax
* Remove jQuery usage
* Improve assertions (and actually fix some of them)
