Time quantities

If a user needs to "clock in/out" multiple times on a Log, we can potentially provide two choices:

1. Create a separate Time Quantity.
2. Start a new timer, and when it ends, ADD the new duration to the previous total value.

These are perhaps choices for any UI or Field Module that implements the "clock in/out" UI functionality. I just want to mention here that there are different ways that could be represented and still end up with the same results.

Worth noting: since we won't actually be adding any UI for "clocking in/out" at first, we could consider waiting to add the "start" and "end" fields - since that is the only place they would be used.

So a "Time" quantity would only need the additional "User reference" field to start.

Another idea: maybe we want a dedicated "Notes" field, which would allow more than the "Label" field? This would be a way to comment on what was done during the particular session of clocked time.

I dusted this off and pushed an updated 2.x-time-qty branch to the fork. It takes the branch that @paul121 started 2 years ago and just makes a few small changes (for consideration):

• Updated the module description to make it clear that this is designed for time tracking.
• Updated the module dependencies to bring them in line with recent changes in farmOS core to our other quantity type modules.
• Removed the "Notes" field from time quantities. I suggest we punt on this for now and consider it in a follow-up if there is a need for it in practice. Easier to add to this data model in the future than remove from it, so let's start simple. Perhaps the label field will be sufficient to start.
• Removed the time quantity template. We refactored some of the way this works since this branch was created, and none of the other core types provide a template anymore (they used to). It might be worth considering it again, but it seems OK without the extra code to start.
• Hide the start and end time fields in both the form and view displays. In my mind these really should only be used internally for storing the current state of clock-in/out, and ideally wouldn't be exposed to the end-user. They are necessary for UI to be built that allows for clocking-in/out, but exposing them directly in the form/view display UI only makes these quantities more confusing and prone to data issues I think. Ultimately the quantity value is the important piece of information, and will store the total time tracked, which will be calculated by the start/end in cases where the user clocked-in/out. But without that auto-calculation logic in place, I don't think it makes sense to expose these to the user.... not yet at least.

I think overall this probably still needs some minimal UI/UX work before we merge it. We may want to consider hiding the "Measure" field and setting it to time automatically. We did something similar with price quantities, and had some core logic to make that easier, but then removed it here IIRC: #3324839: Refactor price quantity data architecture

We may also want to add the quantity value auto-calculation logic at the data level... so that if a time quantity is saved, and start and end times are provided, the value is filled in automatically. Or we could defer that to UI/UX level logic. Up for debate... and the answer to this might become more clear once we have some UI starting to be built out that uses this data model.