Display Recieved Date on Postal Mail

[amandabee]

We recently started explicitly displaying the Postmark date on postal mail in requests. It has been helpful to name that explicitly. We would also like to add the date the mail was received and scanned.

These dates (Postmark and "Received and Scanned") are metadata and should probably be displayed inside the grey bar, on the right, under the lozenges (in this case Fix Required and Mail)

The support team spends a fair amount of time reconstructing timelines with users, and often it is confusing when old mail appears out of nowhere. Knowing when the material actually arrived makes it a lot easier to make sense of a request's history.

[morisy]

I think having something like "Mail (Postmarked on October 3, 2023)" similar to the verification makes sense.

[amandabee]

Example: https://www.muckrock.com/foi/st-louis-337/fusion-center-mous-moas-st-louis-metropolitan-police-department-152056/

[amandabee]

I'm also fine with it appearing as text rather than in a lozenge, it just belongs on that side in the metadata grey.

[mitchelljkotler]

This is another one of those issues with more going on than appears at first site. I think I can fairly easily fix this issue in a straight forward way, but want to clarify how it works, so everyone is on the same page.

Each communication has a date. It also used to store how it was sent - by mail, email, fax or portal. This causes problems if a communication needs to be resent, especially by a different method. So now there is a separate database record for the communication itself, and how it was sent. For the vast majority of communications, there is exactly one record for how it was sent with a time that is almost identical to the communication time.

For received postal mail, the postmarked date is going to be fairly off from when we scan it onto the site, due to mailing times and time for us to process it. We used to store the postmarked date on both the communication and the mail record (I am not sure why we did this.) Somewhat recently, we changed that to store the postmark date on the mail and the time it was uploaded on the communication, which is more consistent with other methods of communication. We then put the postmark date in the communication itself. However, we were still showing the postmark date instead of the communication date in the corner of the communication, which was confusing (especially since the communications are sorted by their date on the page). I think showing the communication's date (when it was created) on the page is what we want to fix here. Then we want to stop putting the postmark date in the communication itself, and instead display it in the communication header (just not as the main date).

This will effect other communications in the case that something was resent. We keep track of all send attempts, so it is possible for a communication to have multiple records of how it was sent. For example, we could create a communication on 1/1/2024 and send it via email on 1/1/2024. Then on 1/2/2024 we get an email error, so we mark it as having errored and resend it via snail mail. Now, it would show the last time it was sent in the corner (1/2/2024) rather than when it was created. Which can be confusing, since it can change, but also useful, because if these dates are far enough apart, it causes confusion in how much time the agency took to respond. (ie I create this communication on 1/1/2024, email fails, it doesn't get resent as snail mail until 1/8/2024, the user will think the agency took an extra week to respond.) Right now we do not expose any failed communication or resend metadata on the frontend (for either users or staff). I am not sure if exposing some of this might help ease confusion in these situations, although coming up with a good UI which helps explain what's going on more so than just creating more confusion might be challenging.

[morisy]

Mitch and I discussed briefly, and I think his description of the challenge and proposed solution makes sense. I think we might want to make the short term fixes that deal with displaying postal mail while also planning a later iteration that does things like indicates to users situations where a communication was submitted multiple times in different ways — it shows the behind-the-scenes work but also provides clarity.

It would also be easy for this to get very noisy so want to make sure the design doesn't get in the way.

One principle I'll just state is that our request pages should be able to be viewed by our staff, the requester, and the agency and feel like a fair and at least accurate representation to all three of those of what the request timeline was.