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.
The recent changes to the user menu changed how we were ordering the
items in it. A small bug was noticed though, as we’re not displaying the
unread assignments at the very top.
This patch fixes the ordering like this:
- Unread individual assignment notifications
- Unread group assignment notifications
- Read individual assignments
- Read group assignments
In each group of items, they are sorted by date, the most recent ones
being at the top.
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 cleans up the markup a bit, so instead of a `div` as a table child we use the `td` and removes the internal wrapper. This fixes an issue with a double highlight while using j/k navigation highlighting caused by the nested `td`.
Uses the router service for redirecting instead of `this.transitionTo`. Also removes the first branch of logic, which was unnecessarily redirecting to the current route (and led to an infinite loop with the modern API)
- Reuse core `<BasicTopicList` instead of reimplementing
- Use raw plugin outlet to add assign controls to topic-list-item (requires https://github.com/discourse/discourse/pull/23592)
- Remove use of `.render()` in route
- Update angle bracket components to use vanilla attributes where possible
- Update how we check for key value after changing to `on "change"` from `onChange`
Re-exporting the BasicTopicList component as-is leads to unexpected behavior when colocating templates because `BasicAssignedTopicList` === `BasicTopicList`. Extending it gives the component its own identity.
Similar to 8ba7b0727a
Re-exporting the TopicList component as-is leads to unexpected behavior when colocating templates because `AssignedTopicList` === `TopicList`. Extending it gives the component its own identity.
The goal is to add a class so when assigns are not public, their descriptions can be styled similar to whispers... this is a light way to reassure admins of assign message visibility.
Joffrey JAFFEUX
Krzysztof Kotlarek
Andrei Prigorshnev
Blake Erickson
Jarek Radosz
David Taylor
Loïc Guitaut
Kris
Isaac Janzen
Keegan George
Arkshine
Arpit Jalan
Bianca Nenciu
chapoi