Make sure to indicate that Rehab event notes are from rehab

[johnpauls]

When a pseudo-event is converted to a real event, the event note gets the date of the real event, not the date of the psuedo-event. This has the potential to make the notes a little confusing if the situation changes between the rehab and the event. To minimize this, event notes from rehab should indicate that they are from rehab.

Example - during rehab of GWMP-0254, it was noted that a tree tag was missing. We found the tag, but then we had data for a tree tag and an event note seemingly from the same day that said the tag was not there.

[blcampbell]

Clarification:

Pseudo-Events (Rehabs)

• Have a date when created
• Any associated event notes also have this date

Converted Pseudo-Events (Rehabs) that are now Real Events

• Have as their date the date of the conversion to the real event
• Retain the original pseudo-event event notes and append the text : "Converted MM/DD/YYYY rehab (pseudoevent)" to the end of the event note (MM/DD/YYYY is the date of the original pseudo-event)

Per @johnpauls comments, adding "Rehab note: " or similar to event notes made during a rehab will make it clearer that the notes were made during the fall rehab.

All forest veg personnel should review (@johnpauls, @lizmatthews03 , @abrolis) to ensure this workflow adjustment will avoid the confusion.

[blcampbell]

@johnpauls, @abrolis, @lizmatthews03 -

Currently...

• Event notes are part of the event record.
• There is one note per event.
• A pseudoevent is identified by a flag in the event record.

When an event is still a pseudoevent we can update the event's note to include the phrase with the original pseudoevent's event date. For example "[Converted 6/30/2020 rehab (pseudoevent)]"

However, as @johnpauls noted in this issue - once the event has been changed to a regular event, there is nothing to identify it as a former pseudoevent. Adding the "[Converted 6/30/2020 rehab (pseudoevent)]" message will help, however this remark can be erased with an edit. There also is nothing that retains the original pseudoevent's date as it resides in the same field as the event date since in the end it is a single event record.

To fully address this issue would require the following:

• Move event notes to a separate table vs. leaving them in tbl_Events
• Capture the pseudoevent date, if it exists in its own field possibly in a separate table

This process suggests a re-think of how pseudoevents work. Perhaps they should reside in a separate table for pseudoevents that is displayed via the typical browse display as both are displayed, but actually located in separate tables (tbl_Events & tbl_PseudoEvents - or similar).

Issues #193 and #194 address some ways to retain the pseudoevent / rehab date and its notes separately from regular events.