Why this change?
We have been seeing tests failures due to errors like
```
Capybara::ElementNotFound:
Unable to find css "#topic-footer-button-assign"
```
when running our system tests in CI. However, I can't quite figure out
why that is happening and have invested way too much time to do so.
Therefore, I'm trying to fix this by closing a topic via the topic
timeline controls instead of the footer button instead.
This was causing the tests to be flaky with the following errors on CI:
```
PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "index_assignments_on_target_id_and_target_type"
DETAIL: Key (target_id, target_type)=(39, Topic) already exists.
```
Otherwise, when an allowed group member is assigned to the PM it invites the user (which is unnecessary) and creates a public small post for the invite.
The goal is to add a class so when assigns are not public, their descriptions can be styled similar to whispers... this is a light way to reassure admins of assign message visibility.
When assignment data is preloaded, cache variable should be set when topic is assigned but also when topic is not assigned to avoid additional queries.
The previous behavior was:
1. Assign a topic to someone
2. Close the topic with the setting unassign_on_close enabled
3. Assign the topic to the same user as before
This caused small broken or empty posts to be displayed.
This commit also introduces system specs
This spec has been detected to be flaky by
https://github.com/discourse/flaky-tests-detective which we run
internally. However, I could not reproduce the flakiness after multiple
attempts so I rewrote the assertions such that we set up the
expectations of what `Assignment#assigned_to_id` should be before and
after the triggering of the DiscourseEvent.
If a topic is initially assigned to user A then reassigned to user B,
this change will make it so that notifications sent to user A are
removed. This matches the plugin's behaviour when unassigning a topic.
There is almost no reason for us to use `Fabricate.build` which does not persist the record to the database and is not what we encounter in production.
See https://github.com/discourse/discourse/pull/18437,
we are removing any references to enable_personal_messages
in core and using only personal_message_enabled_groups,
which requires auto groups to be assigned in certain specs
for them to keep working.
The basic group serializer complains that the flair_upload relation has to be eager loaded when attempting to included assigned groups in search results, which is a consequence of using strict loading during search's preload to
avoid N+1.
Eager loading the association during this would definitely fix the problem, but is it the right solution? It seems to me that this serializer does too much, when we only need a small number of attributes to display the assigned
widget. Instead, this commit adds a lightweight custom serializer which grabs only the essentials for it to work.
Only 5 assignments can exist simultaneously for a topic or its post.
The code that counted the assignments did not ignore the inactive
assignments which made the limit check more strict than it should have
been.
There were two problems with the way current automation script for automatic
assignment works:
- it tried to assign users that were not allowed to be assigned because they
were not part of groups that are allowed to use discourse-assign - fixed by
skipping users that are not a part of assign_allowed_on_groups groups
- it assigned new users - fixed by adding a new user that can skip new users
This commit adds a tab for assignments in the experimental user menu. The assignments tab behaves very similarly to the bookmarks and messages tab in core: it displays the user's unread assign notifications first and then fills the rest of available space in the menu with assignments (same content that the current user menu displays).
More details of the experimental user menu can be found in https://github.com/discourse/discourse/pull/17379.
This change makes it possible to associate an assign notification with the `assignments` record that creates the notification. It'll be needed for the assignments tab in the new experimental user menu, see https://github.com/discourse/discourse/pull/17379.
Adds a new plugin setting that when enabled adds a status field for every assignment. This setting defaults to off.
The possible status for an assignment are customizable via yet another new setting, and the first one on this list will be the default status for new assignments.
The status is not yet show anywhere except the assign modal and the small action posts in topics at the moment. Adding status to the assignment list for users and groups will be handled in the near future.
Co-authored-by: Penar Musaraj <pmusaraj@gmail.com>
We are already checking that assignee has access to the private message. However, admin still can be assigned as technically they have access.
We should ensure that assignee has direct access to the message.
While assigning a random user in group to the topic posts, if we didn't include the users who were assigned to indivitual posts then the same users will be assigned again and again.
It's a minor copyedit to remove group mention from the post raw. Else it sends a notification to all group members when no one is found to be assigned.
Jarek Radosz
Natalie Tay
Krzysztof Kotlarek
Joffrey JAFFEUX
Alan Guo Xiang Tan
Martin Brennan
Vinoth Kannan
Ted Johansson
Arpit Jalan
Bianca Nenciu
Kris
Jan Cernik
Gerhard Schlager
David Taylor
Andrei Prigorshnev
Penar Musaraj
Roman Rizzi
Keegan George
Osama Sayegh
Rafael dos Santos Silva
Natalie Tay