* FEATURE: Add pending assign reminder threshold setting
User can define a threshold for the pending assign reminder.
* DEV: rename REMINDER_THRESHOLD with SiteSetting
This adds a new dropdown to the topic level assign modal. A topic may contain several assignments, the topic itself may be assigned and also some of the replies may be assigned. With this new dropdown, it's possible to edit all the assignments from this modal.
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
The label touches the avatar when a topic has several assignments,
and those contain assignments to users _and_ to groups. We don't show
avatars for groups, but the code sees there are several assignees and
applies overlapping styling.
This commit corrects the logic and fixes the issue.
Here is how avatars on the button behave:
1. If there are from one to many assignments on the topic, but all
the assignees are groups, we don't show avatars, only label.
2. If there are from one to many assignments to the same user, we show
the avatar of that user.
3. And if there are from two to many assignments to different users, we
show avatars of first two users.
Prior to this fix the state change was not reflected in the UI when changing the "who can assign" preference of a group.
This was actually saved in the backend but would require a full page refresh to see the updated state on the group preferences page.
We've noticed that when unassigning a topic on the `activity/assigned` one of
two incorrect things happens when pressing this button:
1. The first topic on the page gets unassigned instead of the selected one
2. No topics get unassigned (that happens when the first topic on the list is
not assigned and only has assigned _posts_)
That happens because this handler for all buttons somehow always use the
same state - the state of the first topic on the page:
f2906e0885/assets/javascripts/discourse/components/assign-actions-dropdown.js (L55-L68)
There seem to be some nuances in select-kit and I'm not sure whether
this should be qualified as a bug in select-kit. However, I've noticed that in other cases when we use `DropdownSelectBoxComponent` we use the `onChange` handler rather
than `onSelect`.
So I switched this code to using `onChange` and that resolved the issue,
the `onChange` handler has access to correct state.
Tests will be in a follow-up.
Before, we only had buttons for assigning and unassigning topic on
the topic level assign menu. This commit adds dynamic buttons for
unassigning posts to the menu.
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 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)
```
Why this change?
We have been getting flaky test failures from these specs and the
failure screenshot shows that the user is not logged in when it is
supposed to be. Futher investigation shows that when the test flakes, it
is because the request to view the topic is using an auth token that is
different from the one which was created when the user was signed in.
What does this change do?
1. Add the `capture_log` metadata to all the tests in this file.
2. Enables the `verbose_auth_token_logging` site setting to give us more
debugging information in the logs.
Why this change?
The spec is flaky and it seems to be DB transaction related where after
signing in as a user, the failure screenshot shows that the user has not
been signed in.
What does this change do?
Set `capture_log: true` which will log all ActiveRecord DB statements
execute while running the spec.
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`.
Sometimes, the topic id actually exists for that spec (id being 1) and
it will raise about not finding the group id instead of not finding the
provided topic because the assignees group wasn’t provided in the
`fields` parameter.
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.