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.
Adds support for polymorphic bookmarks in the serializer extensions
and preloaders for bookmarks.
Specs are skipped for now for the serializer but they do
work without the use_polymorphic_bookmark guard in the plugin.rb
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.
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
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.
When an assigned post is moved to the new topic, it becomes topic assignment.
When an assigned post is moved to an existing topic it stays post assignment
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.
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>
This significantly reduces the amount of logic we need to carry in the discourse-assign plugin. One side effect is that I had to rename the 'q' parameter to 'search', so that it matches core's implementation.
Adds three new search modifiers:
- in:assigned for assigned topics
- in:unassigned for unassigned topics
- assigned:{username} to list topics assigned to a specific user
These modifiers are all made available in the advanced search sidebar
Krzysztof Kotlarek
Vinoth Kannan
Martin Brennan
Bianca Nenciu
Natalie Tay
Isaac Janzen
Jarek Radosz
Rafael dos Santos Silva
Joffrey JAFFEUX
jbrw
Roman Rizzi
Martin Brennan
Alan Guo Xiang Tan
Arpit Jalan
Osama Sayegh
David Taylor
Ahmed Gagan