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.
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
Blake Erickson
Loïc Guitaut
Andrei Prigorshnev
Discourse Translator Bot
Selase Krakani
Alan Guo Xiang Tan
Jarek Radosz
Daniel Waterworth
Mark VanLandingham
David Taylor
Penar Musaraj
chapoi
Martin Brennan
Bianca Nenciu
Natalie Tay
Kris
dependabot[bot]
Krzysztof Kotlarek