How to model activity types

Development
1

I know we’ve discussed this & similar issues before, but I couldn’t find anything that covered all the bases, so I’m starting this post :slight_smile:

I’m starting to work on a use case where I want to keep track of different activities (simple metadata like timestamp, notes, and photos) that are associated with plant assets. Some example activities are training, pruning, mowing and harvests.

Naturally, it makes sense to use Activity and Harvest logs that reference the plant asset(s) to model these records. This provides the metadata values & asset references I need. But it doesn’t provide a way to specify which “activity type” the activity log represents. This is important so that I can later query which “activities” have been completed for the asset.

I see a few options for representing this:

  • Create a new log type for each activity. This would work, but seems unnecessary since all of my activities need the same metadata (with the exception of the “harvest” activity, which already has its own log type).
  • Create log categories for each activity type (training, pruning and mowing log categories). This has been recommended before and is actually my current approach for a similar use case. This works because it’s possible to query activity logs in the training category that reference a specific asset. But this doesn’t seem like the correct solution since activity logs would be the ONLY log type assigned to these categories. In other words, it seems like log categories should only be used when logs of multiple types might represent the same “category”. A good example of this is the “Tillage” category that was created here: https://www.drupal.org/project/farm/issues/2965739
  • Create a custom Plan type to track which activities have been completed for the plant assets. This could be another option, where a custom Plan type could have specific fields for “Training logs”, “Pruning logs”, etc. The limitation with this approach is that it becomes much more challenging (currently impossible in 1.x) to create these records via the API, such as in Field Kit. Even with the ability to update a Plan & its fields via the API, this means the 3rd party has the added requirement of updating the Plan via the API. This all seems unnecessary to simply model “activity types” on assets.

I’m curious about another option: Creating an optional “type” field on Activity logs that references pre-defined “activity types” configured in the farmOS instance. For farmOS 2.x it would make sense to model these “Activity types” as config entities. This would make it possible to query all activity logs that reference an asset, but then limit results by specifying an activity.type value.

Adding such a field to activity logs would make it possible to model “activity types” without requiring custom code/modules to provide another log or plant type. You could argue this is already possible without custom code by using log categories, but this seems like a better solution IMO. This is similar to the method field on Input logs too, although that is only a simple text field right now.

Thoughts?

2 Likes
2

Ah, my proposal is actually very similar to the new Lab test log which has a log.lab_test_type list_string *field whose options are provided by lab_test_type config entities, by default “Soil” or “Water” test types.: https://www.drupal.org/project/farm/issues/2994734

1 Like
3

I like the idea of adding an Activity Type field, similar to the Lab Test Type field. I could see the same argument for adding an Observation Type field as well - maybe others, but perhaps we just start with those.

It strikes me as a nice next-step refinement between “Log type” and “Log category”.

Notably, “Flags” work the same way in 2.x: they are config entities as well. But they cover an even broader set of records than “Log type” and “Log category”, as they can be applied to Log, Asset, and Plan entities.

Lab test log which has a log.lab_test_type list_string *field

FWIW (and maybe more technical than is necessary for this forum post) I decided to use a list_string field for Flags (and Lab test type) instead of an entity reference field (that would reference the config entity itself) for two reasons:

  1. It should make API querying/filtering a bit easier, because you can simply use the known machine name of the flag for filtering, rather than needing to look up the UUID of the config entity.
  2. The Flag field in 1.x was a list_string field as well, so migration might miss flags that didn’t have corresponding config entities in 2.x. I felt it was better to preserve this data.
1 Like
4

The main risk here, it seems, is ambiguity and learning curve to understand the differences between “Log type”, “Log category”, “Flags”, and now “Activity/Observation/Lab test type”. They have subtle differences, which I think we can explain with some better documentation, but to a newcomer it will be confusing.

Apart from documentation, some UI/UX could help. Simply moving a lot of these meta fields into a right-hand column (like the Gin theme does for node forms) with good descriptions and links to documentation would help I think. The mental overhead of having all fields in the same “content” region in 2.x right now is significant, IMO.

1 Like
5

Ah yes, UI/UX is a good consideration. Roughly speaking, would the right hand column then contain all fields that are specific to certain log/asset/plan types?

1 Like
6

Oh no, I was just thinking that “meta-ish” fields could be put into the right column, to separate it from more of the “content-ish” fields. :slight_smile:

Eg: Activity type, Flags, Log categories, Assigned to, and maybe “Is movement” would be good candidates for the right column, IMO. Whereas the log name, notes, asset/equipment references, files, and type-specific fields would be in the left column.