Closed gmr closed 2 months ago
occurred_at
Not advocating changing schema or API - just the label, Occurred At works for me.
I'd advocate changing it everywhere, I think it's more accurate and it's sensible to have a shared language between the front and backend. But, changing the frontend is easy.
I'm open to adding the field, and removing recorded_at from the UI and making it automated.
Ah, that's even better
Also while doing this, please make occurred at auto-populate in the UI with the current timestamp.
@gmr & @in-op -- I'm going to pick this one up shortly. We have completed_at
and recorded_at
today. I think that the user expectation is that we have a field that is the occurrence (start?) time that is required where completed_at
is optional and assumed to be used for longer running operations. I want to keep recorded_at
along side of recorded_by
since it is a common audit field throughout the application. It shouldn't be something that the user sees at all.
I completely agree that we should add a field here to represent the time that the event started at and have it default to "now" in the UI. The only paint that remains is what should it be named? I'm good with occurred_at
but I wanted to ask before I start changing code since started_at
aligns slightly better with completed_at
.
Is everyone cool with:
occurred_at
to the schemarecorded_at
to occured_at
during table creationAnother option that we can consider is throwing away completed_at
altogether though I was sorta surprised when I scanned some data and found that 37% of our rows have a completed_at
set with durations ranging from a few seconds to up to 99d.
Recorded At in the UI doesn't quite align with user expectations with what the field is intended to be.
Thinking it should be renamed to Performed At, but am open to suggestions.