blake
Fevereiro 2, 2022, 12:43am
9
Este problema deve ter sido corrigido agora!
committed 10:02PM - 18 Jan 22 UTC
* FIX: Tag watching for everyone tag groups
Tags in tag groups that have perm… issions set to everyone were not able
to be saved correctly. A user on their preferences page would mark the
tags that they wanted to save, but the watched_tags in the response
would be empty. This did not apply to admins, just regular users. Even
though the watched tags were being saved in the db, the user serializer
response was filtering them out. When a user refreshed their preferences
pages it would show zero watched tags.
This appears to be a regression introduced by:
0f598ca51e7ada06f91a6a8717909627ee81a67c
The issue that needed to be fixed is that we don't track the "everyone"
group (which has an id of 0) in the group_users table. This is because
everyone has access to it, so why fill a row for every single user, that
would be a lot. The fix was to update the query to include tag groups
that had permissions set to the "everyone" group (group_id 0).
I also added another check to the existing spec for updating
watched tags for tags that aren't in a tag group so that it checks the
response body. I then added a new spec which updates watched tags for
tags in a tag group which has permissions set to everyone.
* Resolve failing tests
Improve SQL query syntax for including the "everyone" group with the id
of 0.
This commit also fixes a few failing tests that were introduced. It
turns out that the Fabrication of the Tag Group Permissions was faulty.
What happens when creating the tag groups without any permissions is
that it sets the permission to "everyone". If we then follow up with
fabricating a tag group permission on the tag group instead of having a
single permission it will have 2 (everyone + the group specified)! We
don't want this. To fix it I removed the fabrication of tag group
permissions and just set the permissions directly when creating the tag
group.
* Use response.parsed_body instead of JSON.parse
Tags em grupos de tags que têm permissões definidas como “todos” não conseguiam ser salvas corretamente. Um usuário em sua página de preferências marcava as tags que desejava salvar, mas as watched_tags na resposta ficavam vazias. Isso não se aplicava a administradores, apenas a usuários regulares. Mesmo que as tags observadas estivessem sendo salvas no banco de dados, a resposta do serializador do usuário as estava filtrando. Quando um usuário atualizava suas páginas de preferências, mostrava zero tags observadas.
@nathank você pode verificar quando tiver uma chance?
2 curtidas