See https://github.com/discourse/discourse/pull/18437,
we are removing any references to enable_personal_messages
in core and using only personal_message_enabled_groups,
which requires auto groups to be assigned in certain specs
for them to keep working.
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.
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 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.
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.
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
* 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.
* DEV: use group ids to allow assign on groups (#38) [Undo Revert]
This reverts commit 8f92c5f9bd.
* Set the default inside a migration based on the core migration. Improve migration check to work against tests-passed/beta/stable.
* Update db/migrate/20190718144722_set_assign_allowed_on_groups_default.rb
Co-Authored-By: Robin Ward <robin.ward@gmail.com>
* FIX: Skip enqueuing reminders if no groups are allowed.
With an empty SiteSetting.assign_allowed_on_groups, it used to generate
an invalid query containing "group_users.group_id IN ()".
* Feature: Allow assign on groups
* Use type: group_list option
* Track group changes and update the setting accordingly. Restrict reminders frequency to assign allowed users instead of staff
* FEATURE: Users can override reminders frequency
* Changes:
- Avoid creating a user custom field when the used didn't override the frequency
- Sanitize frequency value using coercion
- Minor fixes
* Sanitize query and user query single
* FEATURE: Display PMs in assigned activity and differentiate them.
* FEATURE: Unassign/Re-assign tasks from the activity view
* Remove bulkAssign. Reuse assign/unassign with a service. Change PM icon position
* Reuse ListItemDefaults instead of duplicating code.
* Conditionally show/hide feature if list items defaults is present in core
* FEATURE: Limit the amount of assigned topics an user can have.
* Do not enfore the limit when self-assigning
* Avoid computing the query when self-assigning. Do not count self-assigns when enforcing the limit