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)
```