* 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>
Currently, when reopening a topic that has assignments, the
notifications in the user menu aren’t recreated.
This patch fixes that issue. It also addresses the same type of issue
with posts being destroyed and recovered.
Starting from b3a1199493 we stop using deprecated "WithStatus" serializers. Instead we'll be passing an 'include_status' option to serilaizers, for example:
```ruby
# before
BasicUserWithStatusSerializer.new(user)
ArraySerializer.new(users, each_serializer: BasicUserWithStatusSerializer)
# now
BasicUserSerializer.new(user, include_status: true)
ArraySerializer.new(users, each_serializer: BasicUserSerializer, include_status: true)
```
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.
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 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.
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.
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>
After a topic is closed, the assignment is not deleted but becomes
inactive. When this happened, it was not removed from the assignments
count or list.
There is an active flag for assignments. It is used to bring assignments back when topic is reopened.
However, when assignment is inactive, it should not be displayed on assigned list or search.
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
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)
On the group assignment page, we should be able to display
- all topics assigned to that group + to user belonging to that group
- all topics assigned directly to group
- all topics assigned to individual user
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.
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>
Gabriel Grubba
Alan Guo Xiang Tan
Mark VanLandingham
Krzysztof Kotlarek
Loïc Guitaut
Andrei Prigorshnev
Jarek Radosz
Martin Brennan
Natalie Tay
Bianca Nenciu
Penar Musaraj
Rafael dos Santos Silva
Roman Rizzi
Osama Sayegh
Natalie Tay
janzenisaac
Ahmed Gagan