This topic is about the proposal to add a new “Organization” entity type in farmOS, for storing “organization-level” data (also referred to as “farm-level” data in other conversations).
This is a continuation/alternative to the idea of a “Farm” asset type that was proposed here: Interest in a new Farm asset type? Read that thread for the full context and conversation.
This new Organization type would allow for sub-types, in the same way that we provide an Asset type with sub-types like Land, Plant, Animal, etc. For this intitial proposal, we would include a single “Farm” Organization type with farmOS core. But it would be possible for add-on modules to provide additional types, and we could consider adding more to core in the future.
We discussed this on the monthly community call today, and there seems to be broad agreement that this is a good idea, and that it will be a better approach than simply adding a new “Farm” asset type.
I’d like to open up this forum topic for broader community feedback, and to start thinking about what the very first pass needs to include. Here are some questions we identified on the call today:
- What fields should the
farm organization type include? Some that were mentioned in the Farm asset thread include: Mailing address, Telephone, …
- How should other records be related to Organizations? I’m thinking of an
organization reference field on asset and log entities.
- What initial UI is needed? One of the biggest things we described in the other thread is the ability to see per-farm location hierarchies. That feels like a straightforward first step. What else?
- There were probably other questions… I forget.
3 Likes
Actually, now I’m thinking it might be better to start specific, with a farm reference field that is only used to reference farm organizations. It seems to me that the purpose of this field (as discussed thusfar) is very specifically for associating records with specific farms, for filtering purposes. It is hard to predict how a more generic field that can reference any type of organization might get used. It could be harder to tease apart data if we needed to separate a more general field in the future. Whereas its conceptually easier to generalize a specific field. So IMO it’s safer to start specific with this one.
I also wonder if there would be any sense in marking one or both of these modules (the organization module generally and/or the farm organization type module specifically) as “experimental” in our first release of it. It feels like a pretty solid concept, and I don’t expect we would remove it once it’s added, but the “experimental” flag might help to set expectations as we start to think about how to use it more in practice, and what additional supporting UI will be necessary.
1 Like
FYI I have started working on this in a 3.x-organization branch in my fork: Comparing farmOS:3.x...mstenta:3.x-organization · farmOS/farmOS · GitHub
I will open a pull request when it feels like it’s ready for potential merge review.
1 Like
Can we all agree that address and telephone are good fields to start with?
Should they be on ALL organization entities (base fields)? Or only farm entities (bundle fields)? It seems to me they would make sense as base fields, if the purpose of an “organization” is to represent a legal or informal entity that assets/logs are associated with.
What other fields should we consider? I would lean towards keeping them very limited to start, and experiment more in contrib.
@paul121 posed the question in chat: Is it necessary to have a farm reference on Logs? Or is it sufficient to only associate Assets with Farms directly? Most of the time the Logs will reference Assets. And requiring it on Logs adds burden to make sure that’s always filled in properly (could be automated in various ways - but it’s more to consider). And having the reference on both the Assets and the Logs means it would be possible for those things to diverge or reference different Farms potentially, which wouldn’t make sense.
Also: should it be possible to associate assets with multiple farms?
1 Like
Two things to consider with these…
- Should they be single-value or multi-value?
@paul121 and I discussed this and are leaning towards single-value to start. Multi-value may be useful (and might come up as a feature request later), but the “simple” ability to “add another” phone/address doesn’t add any additional context to each entry. So if it would be better to have more explicit “types” of phones/addresses then it might be better to leave this as a single-value field to start and consider adding additional fields later.
Or… we could consider taking a next step towards CRM features by adding a “Contact” entity type in the future, which would be associated with organizations like users. Most CRM systems have at least two entities like this (organization + contact) for this exact reason: one organization may have multiple "contact"s, with their own telephones and addresses, for specific purposes. That might be the better long-term way to approach it. In which case, an initial single-value telephone and address field on the organization entity would serve as a simple “default” option for now.
- This will add a new dependency on the Address module.
Drupal core includes a field type for telephone numbers (with validation), but we would need to add a new dependency for address fields. The Address module is stable and very widely used (it is a dependency of Drupal Commerce), and it handles international addresses well. I imagine it will be maintained for a long time, and will have upgrade paths to new versions of Drupal in the future. So I think it’s a safe dependency to add. That said, it’s always good to be careful and considerate about new farmOS dependencies in general.
2 Likes
I opened a draft pull request which implements the initial data architecture, documentation, and minimal UI for this: Add an Organization entity type with a Farm bundle by mstenta · Pull Request #849 · farmOS/farmOS · GitHub
Next steps are largely around adding more UI/UX to make this usable from the frontend. But even as-is it would be useful via the API, so it’s a good time to start getting eyes on it as we work on those next steps.
Discussed on the farmOS dev call today (with @Symbioquine @paul121 @Fosten):
- We decided to wait on adding the “Users” field to Organization entities. There isn’t a direct use for it in the current PR, and we may want to consider putting an Organization reference field on the User records instead.
- We talked about whether or not we should we have a “Farm” reference field on assets or a more generic “Organization” reference field or “Owning Organization” reference field. But we decided that a “Farm” reference field makes sense as a first step. “Ownership” is a bigger can of worms, semantically speaking. And we need a reference to be able to filter the Location Hierarchy by “Farm”, so there is a concrete need for a Farm-specific reference right now.
- We discussed whether or not to add the
telephone and address base fields to the organization entity. We discussed potentially adding a “Contact” entity type in the future to handle multiple phones/addresses of different types. The challenge is that a single “default” telephone/address might not be very useful.
- We wondered if
email and website would be good fields to add as well.