General comment field improvements

[kwa20]

Feature Description

General comment field (wherever applicable)

Problem Description

Thus far, the general comment field only provides an option to freely enter comments or anything further in one field. Often enough, users use this field to enter a lot of additional data. However, it cannot be inferred, who entered data or when it was entered.

Proposed Change

To optimize the comment field for internal communication of users, change this section to allow stacking of comments. A comment should be added by pressing "new comment". After saving the comment, user name, user role and creation date and time should be displayed in a comment header. The individual comment fields should be able to be minimized (hidden) and maximized. This is important to maintain clarity and not having to scroll for very long to reach the discard and save buttons on the form. When a comment is minimized, merely the header should be visible with the arrow implying that the field can be maximized. When a user comes back to his comment, they should have an option to edit it. The time of the edit should then update the time stamp and the edit symbol should be added to show that the comment was edited.

Pseudonymize entries for users outside of the jurisdiction and read only access.

Additional Information

Development Specifications

• Add a new Comment entity extending CoreAdo with the following fields:
  • caze
  • contact
  • person
  • creatingUser (must not be required because we need to migrate the current comment field)
  • editingUser
  • pinned (boolean)
  • content (text)
• Add a similar entity to the Android app; needs to have the @EmbeddedAdo annotation (i.e. it should be synchronized automatically alongside cases, contacts and persons, not individually)
• Migrate the current additionalInformation fields of cases, contacts and persons via SQL:
  • If the field is not null or empty, create a new comment and attach it to the respective entity; add the content of the additionalInformation field to the content field; don't specify a creatingUser
  • Do this in the Android app as well ONLY for cases, contacts and persons where changeDate = 0 and snapshot = 0 (not with SQL, but in a similar way to how we migrated epi data to exposures, etc.)
  • Drop the additionalInformation columns from cases, contacts and persons (in Android, just set them to deprecated); don't drop them from history tables
• Add lazily fetched lists of comments to cases, contacts and persons (similar to e.g. samples or tasks on cases)
  • Update the delete methods in CaseService and ContactService to also delete associated comments
• Add new user rights:
  • COMMENT_EDIT_ALL: Given to admins, national users and supervisor roles
  • COMMENT_DELETE_ALL: Given to admins

User interface (Vaadin only for now):

• Replace the general comment fields with a list of comments according to the mockup; this should behave similarly to other embedded lists we have (e.g. exposures, person contact details or previous hospitalizations), but with a different design and some changes
• Users are allowed to edit and create comments if they have edit rights for the respective entity
• Users are allowed to edit and delete (i.e. set the deleted flag, comments shouldn't be totally removed from the system) comments they have created themselves
• Users with the COMMENT_EDIT_ALL and COMMENT_DELETE_ALL user rights are allowed to edit or delete all comments, respectively
• The header of each comment should show the creating user and the creationDate (including time)
• If the changeDate does not match the creationDate, show an edit icon next to the creationDate; when hovering over it, show the editingUser and the changeDate (including time) in a description popup
• Comments need to be expandable and collapsable (i.e. if they're collapsed, only show the header containing the creation information, but not the content)
• The five most recent comments (based on creationDate) should always be expanded by default, the rest should be collapsed
• If one comment is pinned, always show it on top; if this comment is not among the five newest comments, only expand the four newest comments by default
• Add two buttons below the comments: "Expand all comments" expands all comments, "Collapse all comments" collapses all comments except the pinned one (if it exists)
• When a comment is expanded and the user has the respective rights, show an edit and delete icon at the right side of the content box; clicking the delete icon should bring up a confirmation popup
• On top of the comments (even above the pinned comment), if the user is allowed to edit the entity, show an empty content box that the user can type into and that contains a checkmark and a discard icon. Clicking on the checkmark icon will add the text in the content box as a new comment to the case, reload the list and clear the content box; clicking on the discard icon will clear the content box; the header of this content box should read "Create a new comment" instead of the usual creation information
• Editing comments should work in a similar way, i.e. there should not be a popup when clicking on the "Edit" icon, but the user should be able to edit the comment directly in the content box; when editing, the edit icon should be replaced by a checkmark icon (clicking it will save the comment) and a discard icon (clicking it will discard the changes and restore the original comment)

[kwa20]

Will likely influence #3936 and #3898

[marko-arn]

That would be very good improvement of this field. Thanks for your work on the weekend!

[kwa20]

This issue should also apply to the general comment field that would be added to persons #3936

[markusmann-vg]

@JaquM @kwa20 We will do an internal refinement for this

Examples for our internal refinement:

• Data modeling
• Number of comments to show, before they can be collapsed
• What about editing, deleting comments
• If and how do we migrate the old comments
• Include automated actions or data changes in here?
• Copy comments list or general comment or follow-up comment when converting a contact to a case?

[StefanKock]

This is likely a complete new feature

[markusmann-vg]

to be considered: https://github.com/hzi-braunschweig/SORMAS-Project/issues/3936

[bernardsilenou]

This is similar to whet we have for event actions. It would be good to use the same design and logic in both sections

[kwa20]

@bernardsilenou I actually don't think it should work like event actions since actions are more related to organizing larger endeavours and this section is mainly for internal commentary on department level. Therefore, users should not have to navigate to separate tabs or go through multiple creation windows.

[bernardsilenou]

@kwa20

• I was not referring to adding another tab but the internal documentation of the comment itself.
• I just have a second and validate that this is not the same as actions since history of each change is not documented.
• This looks more like a chat function within the comment section. I understand now, thanks

[maxiheyner]

Issue tracker comment

[MateStrysewske]

Some quick notes based on a discussion we just had:

• The mockup above is basically what we need
• Users should be able to edit and (soft-)delete their own comments, or all comments if they have the user right to do so
• Edit information needs to be shown (who edited last and when)
• Always display the 5 most recent entries, or the 4 most recent entries and one entry that has been pinned (highlight the pinned entry); automatically collapse others
• Add functionality to "expand all other entries" or "collapse all other entries"
• Adding a new comment should not be done by clicking on a "New comment" button; instead, there should be an empty comment on top of the list with a discard & save button that the user can just type into; if they click on save, the comment is added to the list

[MateStrysewske]

@kwa20 What about migration? We should get rid of the "additionalDetails" fields for cases, contacts and persons because those are currently serving as comment fields. However, those fields don't have an associated "creating user", so if we migrate them to the new comments, these comments wouldn't have a user associated with them. We could allow this and introduce a user right to edit unowned comments, but that would be kind of a hacky workaround only for the migration. An alternative could be to automatically assign these comments to a random admin user. What do you suggest here?

[kwa20]

@MateStrysewske We could use the reporting user as the user to be the 'creating user'. The downside is that this might not necessarily be true and I'd therefore discard this option. I also agree that creating an extra user right for this would not be that nice either. However, considering you're previous comment:

Users should be able to edit and (soft-)delete their own comments, or all comments if they have the user right to do so

Would this right not also make respective users able to edit unowned comments? Otherwise, what if we make unowned comments available for edits to everyone (which is pretty much how the general comment field worked before), but assign/associate the first user that changes the unowned comment after initial migration.

[MateStrysewske]

Yeah, good point - I totally missed that. Doesn't seem to be a problem then :)

[marko-arn]

@MateStrysewske @kwa20 I want to point out that there must be also a handling for comments left by users which are leaving the health office. This could be the scouts from RKI, soldiers or just an employee with a new job. I recommend that if the user of the comment is deactivated the comment it editable by any user, but it mus be shown who did the last change. Other option would be to make it editable for admins only.

[kwa20]

@Marko-ilmkreis I think this would be handled by the user rights COMMENT_EDIT_ALL (admins, national users, supervisors) and COMMENT_DELETE_ALL (admins) that will come with the implementation. These could also be allocated to other users after the implementation of the new user roles concept if needed.

[AliciaRaber]

Please be so kind and let me know with which Ver the implementation will be done? Thank you.

[JaquM-HZI]

@AliciaRaber there is no prioritization yet, so no answer possible

[AliciaRaber]

@JaquM I would suggest to prioritize this issue because we face actually a drastic incline of cases and every step less would help us. Thank you.

[bansaj]

Can we replicate the comment to other modules like events, etc, or will it be specifically added the above-mentioned models only?

[JaquM-HZI]

We could have it for every general comment field and it should be possible to add a general comment field for events @bansaj