Notes administration improvements/considerations

[gbp]

With the roll out of the new notes feature we should consider the next steps:

1. Show some or all of Note#body on admin body show action so admins have an idea which notes are which.
2. Be able to change the ordering of notes
3. Split a existing note into multiple notes
4. WYSIWYG editor - Action Text?
5. Restore ability to import notes by CSV?
6. Notes on embargoed InfoRequest - non-pro admins could see/edit notes through changing the URL, does this matter?

[gbp]

7. Record version history of notes

[garethrees]

8. Add prominence to notes so that we can e.g. show a requester_only note, or prep a note prior to publishing. We could add backpage so that the note's body is excluded from the text that gets indexed, but obviously can't stop external search engines finding it so might be a bit confusing. The reason for backpage would be for adding notes to poor requests where we want to minimise the attention given to them, but still keep them relatively public.

8. https://github.com/mysociety/alaveteli/issues/7564

[mdeuk]

8. Add prominence to notes so that we can e.g. show a requester_only note, or prep a note prior to publishing.

+1, this would be extremely useful for GDPR / Takedown requests on WDTK.

[RichardTaylor]

9. "Comment for this edit" field for changes to notes.

[RichardTaylor]

10. Use the new notes styling to show special annotations, such as important admin notes on a thread, or a summary of a thread. This has, perhaps, been achieved already but we might need/want extra features? https://github.com/mysociety/alaveteli/issues/34 10.1 Optionally show who made a note, and show if they were an admin when they made the note. (And have an easy way to make a note as the site's official user).

[RichardTaylor]

11. Bring the notes admin links up from the bottom of admin pages. (Some admin pages are very long)

[RichardTaylor]

Consider if and how we can use the new generalised notes features to address other tickets eg.

• https://github.com/mysociety/alaveteli/issues/3090
• https://github.com/mysociety/alaveteli/issues/6386
• https://github.com/mysociety/alaveteli/issues/2686

Some of these might now, or soon, be policy/practice questions as much as issues requiring specific development.

[RichardTaylor]

When following a body update request link the notes field isn't easily accessible to edit any-more.

[RichardTaylor]

Record version history of notes

and show that history on the admin page for the entity the note applies to.

The recent change has meant body notes changes no longer appear under the "history" section on the body admin page. (Thanks for retaining the history of changes, it's just new notes changes which are not shown).

[RichardTaylor]

I think that even though the underlying structure has now changed we should put the field for adding/editing body notes back alongside other fields in the general body edit/create form.

• As an admin I want to be able to add body specific notes easily when creating a body.
• As an admin I want to be able to change body specific notes easily when editing a body.

I don't want to have to go through more clicks / to another page to make a [body specific] note edit.

There may be analogous situations on other admin pages. A consistent approach should be taken.

To degree this is a repetition of my previous comments on this ticket, but I have expanded here.

[RichardTaylor]

I see progress on this

Notes was changed from The Armed Forces’ Pay Review Body (AFPRB) provides independent advice to the Prime Minister and the Secretary of State for Defence on the pay and charges for members of the Naval, Military and Air Forces of the Crown. to [#<Note id: 340, notable_type: "PublicBody", notable_id: 1056, notable_tag: nil, created_at: "2022-09-05 12:06:53.136895000 +0100", updated_at: "2022-09-05 12:06:53.136895000 +0100", body: "The Armed Forces’ Pay Review Body (AFPRB) provides...">]

Some opportunity to work on the presentation there and remove, or reduce the prominence of, some of the data.

The precision of those timestamps!

In an ideal world it'd be a nicely presented diff!

[RichardTaylor]

12. Add an "Admin" link on every note and make it only visible to admins.

Perhaps add such a link in the bottom right of the notes box so it's consistent with the presentation used for messages.

This would make it easier for admins to edit the note, and indeed make it easier to find out what is prompting the note's display.

[RichardTaylor]

13. Ability to bring context specific text, and links, into notes.

eg. if I mention [[body name]] in a note display the body name, if I write [[contact link]] show the contact form link.

The [in]ability to include a "link to the body-specific change request form" is mentioned at https://github.com/mysociety/alaveteli/issues/7285

-- Keywords: Dynamic contextual includes for notes.

[RichardTaylor]

There are a few things which have emerged or arisen through the use of notes which could perhaps be helped with some in-line help text:

• admins are using <h3> tags to add titles to notes. Help text in the system could note this is possible / suggested practice.
• it's not entirely obvious who the note is by/from. Notes stating "We ... " can be ambiguous to the reader. This could be resolved by careful wording of notes (which could be assisted by some in-line help/advice).
• care needs to be taken over notes which refer to times/dates, as notes are not currently displayed along with a timestamp. If the date is important then it needs to be included in the text, eg. "At the time of writing (January 2023) ..."

[HelenWDTK]

Note reordering would be really helpful in terms of signpost authorities. I'd be good to be able to bump the signpost note to the top - eg:

[gbp]

@HelenWDTK I can envision ordering of notes being awkward to implement as notes can be associated by tags and or directly. It would be easier if say... all tagged notes were first then orderable list of directly associated notes but I'm guessing that wouldn't really solve the issue.

[HelenWDTK]

It might help. The signpost notes are on the signpost tag, so if they came first we could pin it I guess. It might be that this issue is better solved by adding actual signpost pages.