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.
The previous query which uses a subquery in combination with the OR
condition results in the PG planner unable to leverage the indexes we
have available. Instead, the PG planner would loop through each user
record and execute the subquery once per row. As the number of users on
a site increases, this query becomes more and more expensive to run
leading to the query timing out once a certain threshold is reached.
In the new query, we remove the OR condition which allows the PG
planner to the existing indexes more effectively. We also improved the
subquery by removing an unnecessary join against the groups table.
Since `group_users` rows are cleaned up when a group is destroyed so there is
no need for the inner join on the `groups` table.
Discourse Translator Bot
Jarek Radosz
Krzysztof Kotlarek
Bianca Nenciu
Osama Sayegh
Keegan George
Rafael dos Santos Silva
Martin Brennan
Alan Guo Xiang Tan
Isaac Janzen
discoursebot
Natalie Tay
Vinoth Kannan
Jeff Wong