* FIX: Not send notifications when it should never notify assignment
- Added silenced_assignments table and migration to store silenced assignments
- Added tests for silenced assignments
* DEV: Add annotation to model
* DEV: add empty line after early return
* DEV: lint file
* FEATURE: Add `should_notify` option to `Assigner#assign`
This option let's you control whether the added user within a group assignment should be notified or not.
* DEV: stree assign_controller file
* Update app/controllers/discourse_assign/assign_controller.rb
Co-authored-by: David Taylor <david@taylorhq.com>
---------
Co-authored-by: David Taylor <david@taylorhq.com>
At the moment, it's possible to have maximum 5 assignments per topic
(that includes topic and post assignments). When trying to assign more,
a message "Limit of 5 assignments per topic has been reached" appears.
One possible edge case here is _reassigning_ a topic or a post. Reassignment
doesn't lead to exceeding the limit, and therefore it should be possible. But
at the moment we handle correctly only _topic_ reassignments, while when
reassigning a _post_, we show the error message "the limit has been reached".
This commit makes post reassignments work correctly too.
Currently, when only one user is available for the random auto-assign
and if that user was already assigned, then the assign will fail.
This patch addresses this issue by allowing to reassign a user who’s
already assigned. A new parameter (`allow_self_reassign`) has been added
to `Assigner#assign` with a default value of `false`.
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.
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.
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.
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.
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
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)
Régis Hanol
Gabriel Grubba
Andrei Prigorshnev
Loïc Guitaut
Natalie Tay
Vinoth Kannan
Krzysztof Kotlarek
David Taylor
Bianca Nenciu
Penar Musaraj
Alan Guo Xiang Tan
Keegan George
Rafael dos Santos Silva
Natalie Tay
Jarek Radosz
jbrw