* WIP
* more messing around
* undos, notes to self
* WIP notes
* completed logic and added tests for existing code and implemented code
* fixed failing tests
* fixed failing tests
* added suggested changes
* added suggested changes
* fix merge
* fix linting issues
* possible flaky test
* removed comment
* further user name display changes
* implemented suggested change
* fixed bug in small action post when assigning or unassigning
* fixed breaking tests
* refactored test
---------
Co-authored-by: Juan David Martinez <juan@discourse.org>
* 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
Before this commit, the reminder was leaking the total assigned topics count in the title.
In the post raw it was ensured that it was not being leaked but the title was still leaking the count.
Also add specs and updated existing specs to ensure that the count is not leaked in the title.
* 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>
* FEATURE: Add pending assign reminder threshold setting
User can define a threshold for the pending assign reminder.
* DEV: rename REMINDER_THRESHOLD with SiteSetting
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`.
Currently, when the auto-assign logic can’t find a user to assign, it
will fail saying there was no one to assign. The current logic is this
one:
- Don’t pick anyone who’s been picked in the last 180 days
- If no one has been found, then try the same thing but only for the
last 14 days.
While this is working relatively well for large enough groups, it
doesn’t work at all with very small groups (like 2 people) and it
creates unnecessary noise.
This patch addresses this issue by adding a fallback to the current
logic. Now, if the two first rules fail, instead of saying that no one
was assigned, we assign the least recently assigned person. This way,
the logic will continue to work with large groups but will also work
nicely with small groups.
Currently, we display a mix of topics and notifications in the user menu
assignments tab. This has a number of issues like having to maintain
hard to understand code instead of simply relying on the notifications
system we have, we can’t display more than one assignment per topic and
it’s not clear if an assignment is for a topic or a post nor if it’s a
group assignment or an individual one.
This patch addresses those issues by relying on the notifications system
we’re using for most of the other user menu tabs instead of a custom
implementation. This led to some heavy refactoring but it was
worthwhile as things are a bit more normalized and easier to reason
about. Instead of serializing topics with different attributes to access
various assignments, we now simply return a notification for each
existing assignment.
The UI changed a bit: tooltips are now explaining if the assignment is
for a topic or a post and if it’s for an individual or a group. Icons
are also properly set (so no more individual icon for group assignments)
and the assigned group name is displayed.
The background jobs signatures changed a bit (`assignment_id` is now
needed for the unassign job) so when deploying this patch, it’s expected
to have some jobs failing. That’s why a post-migration has been written
to handle the creation of missing notifications and the deletion of
extra notifications too.
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.
This commit updates the plugin to follow the latest guidelines, as
shown in discourse-plugin-skeleton, removing the explicit require calls
and using config/routes.rb for defining all routes.
This commit updates the plugin to follow the latest guidelines, as
shown in discourse-plugin-skeleton, removing the explicit require calls
and using config/routes.rb for defining all routes.
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.
Juan David Martínez Cubillos
benj
David Battersby
Régis Hanol
Gabriel Grubba
Alan Guo Xiang Tan
Bianca Nenciu
Joffrey JAFFEUX
Krzysztof Kotlarek
Andrei Prigorshnev
Loïc Guitaut
Jarek Radosz
Natalie Tay
Vinoth Kannan
Penar Musaraj
Jan Cernik
David Taylor
Osama Sayegh
Rafael dos Santos Silva