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
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.
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 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.
If `SiteSetting.unassign_on_close` is enabled, an Assignment record can still exist, but be set to inactive, when a Topic is closed.
Inactivement Assignments should be ignored when comparing to the maximum number of assigned topics.
When topic is closed, we mark assignments as "inactive". Then when it is reopen and setting reassign_on_open is enabled, we bring back previous assignments.
We were already using custom fields for archive message and move to inbox. I changed custom fields solution to use active flag on Assignment model
When post is already assigned to user/group then don't allow assigning a topic to that user/group.
Similarly, right now when topic is already assigned we are not allowing to assign a post that that user.
Build a new workflow that adds a dropdown in place of the old assign button with the ability to
Re-assign a new user / group to an assigned topic
Re-assign yourself to an assigned topic
Unassign a user / group from an assigned topic
Change `topic_id` to polymorphic approach (In the next step we will allow assigning to individual post)
`topic_id` column is still used for efficient display of assigned users on topic list (to avoid scanning posts)
Ability to assign groups.
To assign group, user must have a right to send a message to that group.
In addition, 2 jobs were introduced, - AssignNotification and UnassignNotification to inform interested users in the background about the new assignment.
- Makes a best attempt at being random and assigning people who haven’t been assigned for a long time
- Uses timezones and holidays
- Allows to define a minimum delay between assignments
- Creates a post if no one is available
Included:
* DEV: Post-release cleanup
* DEV: Tests cleanup
* DEV: Import cleanup
* DEV: Drop a compatibility fix
* DEV: Use index_by
* DEV: Use ember imports
* DEV: Use discourseDebounce
* DEV: Use @action
* DEV: Use the optional chaining operator
* DEV: Fix an invalid test
* DEV: Use `discourseModule`
* DEV: Add .prettierrc
* DEV: Sync up the version number
Currently if you try to assign a PM to a user who can't see it, you get an error message that says "@{user} can't be assigned since they don't belong to assigned allowed groups". This commit improves the message and now it tells you the user doesn't have access to the PM and that you need to invite the user before you can assign them.
Signed-off-by: OsamaSayegh <asooomaasoooma90@gmail.com>
* FEATURE: Trigger webhook when assigning and unassigning topics
This PR creates a custom webhook event that you can now select when
creating a webhook to trigger only when a topic has been assigned or
unassigned.
* removed unused file
* Removed functionality that was added to core
This PR into discourse core:
https://github.com/discourse/discourse/pull/9110
adds what was removed in this commit.
It is better to have this logic in core so that it is discoverable and
future webhooks won't end up accidentally using the same ID.
Remove any quoted text and code blocks before matching the "assign self" or "assign other" regexps.
Added tests to ensure it does not regress.
Also cleaned up some TODOs.
Jan Cernik
David Taylor
Andrei Prigorshnev
Penar Musaraj
Bianca Nenciu
Osama Sayegh
Rafael dos Santos Silva
Krzysztof Kotlarek
Vinoth Kannan
Natalie Tay
Joffrey JAFFEUX
jbrw
communiteq
Roman Rizzi
janzenisaac
Jarek Radosz
Guo Xiang Tan
Martin Brennan
Blake Erickson
Robin Ward
Dan Ungureanu
Régis Hanol
Vinoth Kannan