Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notes set against a key do not render when key:value is present #7293

Closed
mdeuk opened this issue Sep 10, 2022 · 3 comments · Fixed by #8408
Closed

Notes set against a key do not render when key:value is present #7293

mdeuk opened this issue Sep 10, 2022 · 3 comments · Fixed by #8408
Labels
bug Breaks expected functionality f:notes f:request-management stale Issues with no activity for 12 months x:uk

Comments

@mdeuk
Copy link
Collaborator

mdeuk commented Sep 10, 2022

On WhatDoTheyKnow, we're considering using the new generalised notes functionality to display messaging on requests, e.g. where a generic event has occurred that effects multiple requests, or where a right to be forgotten indication has arrived from a search engine.

The best way for us to do this, would be to present both a key (e.g. rtbf) and a value (e.g. GDPR/SE/20220910-1) so that we can tie our internal records together.

It is possible to render a note on a request if a key is presented but if key and value are presented, a note linked to the key tag doesn't render on a request.

How to reproduce

  1. Create a new request in a test authority
  2. If one doesn't already exist, create a new note linked to a tag (e.g. rtbf)
  3. Add the tag to the request via /admin, and note that on the request view, the tag is now present.
  4. Amend the tag on the request to key:value format, e.g. rtbf:test.
  5. Refresh the public view of the request, and note the tag is no longer rendered.

Expected behaviour

Note should display wherever the tag matches a key that has a note assigned.

Actual behaviour

Adding the value to the tag removes the note.

Reproducibility

I have tested this on WDTK requests 651067 and 896135, using note 8296. The former is embargoed, the latter is not. I used note 8296, setup against tag rtbf.

The issue is always reproducible; it is possible to reverse it by removing :value from the tag, but re-adding it will cause the issue to re-appear. This does not appear to be related to a cache.

Curio

After a value is added to the tag on a request, the request still shows on /admin/tags at key level. E.g. if I tag a request in the format above, it will still show on the admin page for the rtbf tag (under requests).

@RichardTaylor
Copy link

We could work around this by adding tags of key to bodies with a key:value tag. This could be achieved via spreadsheet wrangling and the csv upload feature.

A tweak in the code would be preferable though.

@RichardTaylor
Copy link

This could be achieved via spreadsheet wrangling and the csv upload feature.

That doesn't help for newly added tags, we'd need to remember to add both key and key:value so a code tweak is certainly the best approach.

gbp added a commit that referenced this issue Oct 11, 2024
Update the concern so that records tagged with `name:value` will be
associated with notes tagged as `name`.

Fixes #7293
@HelenWDTK HelenWDTK added the stale Issues with no activity for 12 months label Nov 19, 2024
@HelenWDTK
Copy link
Contributor

This issue has been automatically closed due to a lack of discussion or resolution for over 12 months.
Should we decide to revisit this issue in the future, it can be reopened.

@HelenWDTK HelenWDTK closed this as not planned Won't fix, can't repro, duplicate, stale Nov 19, 2024
gbp added a commit that referenced this issue Nov 22, 2024
Update the concern so that records tagged with `name:value` will be
associated with notes tagged as `name`.

Fixes #7293
@gbp gbp closed this as completed in #8408 Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Breaks expected functionality f:notes f:request-management stale Issues with no activity for 12 months x:uk
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants