The previous behavior was:
1. Assign a topic to someone
2. Close the topic with the setting unassign_on_close enabled
3. Assign the topic to the same user as before
This caused small broken or empty posts to be displayed.
This commit also introduces system specs
This spec has been detected to be flaky by
https://github.com/discourse/flaky-tests-detective which we run
internally. However, I could not reproduce the flakiness after multiple
attempts so I rewrote the assertions such that we set up the
expectations of what `Assignment#assigned_to_id` should be before and
after the triggering of the DiscourseEvent.
Implements a new design that improves the user experience:
- add a clear cancel button
- add an indication the note is optional
- change the plus icon to a search icon
- show an error when the user tries to assign without choosing an assignee
- move suggestions to default search results
- focus search input when modal is displayed
If a topic is initially assigned to user A then reassigned to user B,
this change will make it so that notifications sent to user A are
removed. This matches the plugin's behaviour when unassigning a topic.
There is almost no reason for us to use `Fabricate.build` which does not persist the record to the database and is not what we encounter in production.
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.
As of 496f910f03, core automatically adds title to user menu tabs if an i18n string exists at the key `user_menu.tabs.${tab_id}`. This PR adds a string in the right place so core picks it up and uses it for the assign tab.
As of 12ebdf0ff0, it's possible to make tabs in the experimental user menu link to a page when they're clicked on when they're active. This commit makes the assign tab links to `/my/activity/assigned` when it's active.
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.
Discourse Translator Bot
Jan Cernik
Bianca Nenciu
discoursebot
chapoi
Ted Johansson
David Taylor
Alan Guo Xiang Tan
Gerhard Schlager
dependabot[bot]
Rafael dos Santos Silva
Kris
Andrei Prigorshnev
Joshua Rosenfeld
Penar Musaraj
Martin Brennan
Jarek Radosz
Osama Sayegh
Roman Rizzi
Krzysztof Kotlarek