Proposal on the use of flags

[gbathree]

Hi all - I am working SurveyStack forms which push data to farmOS via the Aggregator and API. We have some internal conventions on how we store info - like conventions for log_categories, where and how to store certain quantity info, etc.

One convention that I’d like to add is to use flags as a way to convey high-level information about management. Many other orgs who I’d like to use farmOS so it can grow will need this to. I need a more clear one sentence rule, but something like:

A flag is a production strategy/regimes/certification which may be applied to a planting and/or a field

The reason this is useful is we are comparing information across farmOS instances, and while you may have the granular details about all the plantings you want to compare, it’s still hard to know if this planting is (or this field has been) managed in a certain way.

I can’t just add willy nilly to flags - in farmOS they are enforced and require a module to add options. What’s nice is there are existing modules which have some of what I need - farm_organic and farm_biodynamic, which add the following flags:

• organic
• transitionalorganic
• notorganic
• biodynamic

I think the idea was good here, but I’d like to propose (I think) a new module which maintains all the management strategies/regimes/certifications in one place. That way, if a farm starts a new regime or gets a new certification, it’s already on the list.

I’d also like to propose to stick to a format which uses _ to separate words. This may seem trivial but actually it’s really useful because it makes use the slug in human readable format in JS super easy…

${certified_organic} .replace("_", " ") → certified organic

1. Slug is human readable when replacing _ with space
2. List maintains all major US-based practices + certifications
3. List is maintained and added to through a collaborative process (kind of like the Plant Data Service) or perhaps by identifying feeding in ‘other’ responses from other surveys to identify new practices which may get missed.

This would be really useful for me, wondering if this is useful for others… and/or if this feels like the right strategy. I know at least in the next few days I need some basic flags in place, but I’d love to establish a bigger vision here so next year it’s more fleshed out.

[paul121]

@gbathree

I’d like to propose (I think) a new module which maintains all the management strategies/regimes/certifications in one place. That way, if a farm starts a new regime or gets a new certification, it’s already on the list.

@gbathree I like the motivation for this! Having a curated list would be great. Although I do worry about lumping all management types into a single module.

The main reason being if any of the management types are associated with other special business logic, it would be better to keep each management type as a separate module & repository. Both the farm_organic and farm_biodynamic modules are simple in that they only provide flags, but it seems likely that some management types could come with features like a special plan or quick forms too. This could start to get complicated.

So this makes me think of two alternatives:

1. Maybe a simple repository of flag config entities?

In 2.x since flags are implemented as config entities, I’m curious if just starting a repo of flag config entity definitions would be sufficient for the purposes of assembling a list? Arguably this would look nearly identical to a module that provides all these flags, but I think it could serve the same purpose without encouraging that an additional module be installed.

It’s pretty easy for site admins to import config entities from a .yml file (although this might not be available to users on Farmier hosting). As an example, the farm_flag.flag.biodynamic.yml config entity. But importing extra config isn’t without its own issues; it can cause problems down the road if another module tries to install a config entity with the same ID.

2. A higher level repository of conventions?

It seems that curating a list of these different management types is goal #1, and making them readily available & usable by users is goal #2? Extending on the config entity idea, maybe it would make sense to start a repository of conventions? These wouldn’t be installable modules themselves, but could include things like a directory of the config entities included in the convention. This could link to the module(s) that implement (subsets?) of the convention.

It would be neat if we could allow users to “browse” the convention repository from within farmOS and import config like flags all via the UI.

@gbathree

I’d also like to propose to stick to a format which uses _ to separate words. This may seem trivial but actually it’s really useful because it makes use the slug in human readable format in JS super easy…

+1 for using the _ to separate words, but it seems a bit fragile for creating proper labels Outside of the farmOS/Drupal context it might be harder, but config entities do provide a label field to help with this.

If flag config entities are provided as module(s) on drupal.org, we would get a free translation server for all such management types… (worth noting farm_biodynamic already exists as separate project there)

[mstenta]

Thanks for starting this thread @gbathree ! (I wonder if we should consider making a new “Conventions” category for organizing discussions like these?)

I love the idea of a central repository of practices/flags (and for other conventions) which can be used as a more-or-less “official” list to draw from.

Although I do worry about lumping all management types into a single module.

I agree with @paul121 - we should think about whether or not this should be a farmOS module, for all the reasons mentioned above.

Another reason: as this central list grows, we do not want these to automatically appear as options in all farmOS instances. Most of these flags would be extraneous to most farms. So we can’t dump them all in as default options. There has to be a selection process for farms to say “I want to include these flags as options” (which is currently achieved by choosing which flag-providing modules to install).

It would be neat if we could allow users to “browse” the convention repository from within farmOS and import config like flags all via the UI.

This feels like it may be the best all-around approach.

Taking this through to it’s logical next step… this would probably mean removing the flags from the farm_organic and farm_biodynamic modules, and instead creating a (probably core) module that simply provides the ability to import desired flags from the central repository.

This import process could be manual (by selecting the flags you want via UI) and/or automated perhaps (eg: a module that depends on certain flags could declare these, which would download them automatically upon installation).

A higher level repository of conventions?

Agreed! And I think this could be a useful pattern for sharing conventions more broadly in the future too!

+1 for using the _ to separate words, but it seems a bit fragile for creating proper labels

Agree with this as well. I prefer including the underscores, but I would caution against using that as the means to generating labels, especially considering that a translatable label is already provided with each flag config entity. Best practice would be to use that anywhere labels are displayed.

That said, I would support opening an issue to migrate transitionalorganic to transitional_organic in the farm_organic module, if you want to propose that @gbathree. It would mean writing an update hook in the module’s 1.x branch to convert any previously saved flags to the new one, but also including migration logic in the 2.x branch to ensure that folks migrating from 1.x to 2.x are converted as well. Not trivial, but probably not too complicated. Is it worth it?

[gbathree]

I like this:

It would be neat if we could allow users to “browse” the convention repository from within farmOS and import config like flags all via the UI.

I’ve always had trouble with understanding the use of modules with very specific or partial changes (like adding a single flag) because it puts so much burden on users to search and know what to look for. The above idea (in a good UI) would enable users to quickly select the items they want, and could be extended to other things that also don’t require major changes to code, just minor changes to lists (like flags, maybe log categories, etc.).

I guess I need a bit more exploration of how this would work and some visualization of the UX and maybe a better understanding of the initial farmOS setup process (which we don’t do, because we have them set up ahead of time). But I definitely like it.

[gbathree]

Oh one more thing - in terms of using the human readable version of the tag -

From SurveyStack, we don’t really have access to everything in farmOS - so reading the human readable version of a tag isn’t feasible. The ideal here (and it relates to the previous issue) is have a common point from which both the farmOS instance and SurveyStack (or other services) pull from.

This is kind of the idea for the plant data service - it provides a no auth way to share an ontology. So it means in the farmOS instance, I can say ‘use PDS tillage list’, and in SurveyStack I can say the same, and then I’m golden. I can synch up with that list for offline use and vice versa. It also means that for our users, we can ensure we’ve both consistent within our own user base, but also consistent with everyone else.

So the coolest would be to link to the PDS from farmOS in some way so that things like flags and log_categories etc. can get populated from there in a setup or admin process, rather than explicitly adding an additional module.

[mstenta]

burden on users to search and know what to look for. The above idea (in a good UI) would enable users to quickly select the items they want

Agreed! The seeds for these ideas have come up before. In 2.x we added a “Farm Settings” section, which shows a list of modules that can be enabled. Currently it only includes “core” modules that are included with farmOS, but we plan to also include available “community” modules too (before beta): https://www.drupal.org/project/farm/issues/3220609

The idea of a flag selection UI would be similar (perhaps in /farm/settings/flags?), but more specifically for importing flags from a central repository. I think this pattern could be useful for other types of conventions too in the future!

From SurveyStack, we don’t really have access to everything in farmOS - so reading the human readable version of a tag isn’t feasible. The ideal here (and it relates to the previous issue) is have a common point from which both the farmOS instance and SurveyStack (or other services) pull from.

Yea agreed! Having a central collection would solve this too!

[walt]

+1 this Proposal! Would be great to have. repository of different flag config sets that we might download from/ upload to… And i am moreover interested in collaborating with other farms around a sort of “semantic web” for organic farms (mine is in transition now, b/t/w, schedule to be fully certified organic by end of this year).

Meanwhile: is there some way to have other options for these flags beyond the default? (Priority, Monitor, and Needs Attention -at least in my Farmier-hosted instance)?

At present i am using these flags in combination w/ the Notes field for management purposes, but these options are very limited, leaving too much to be said in the Notes (i.e. unstructured data) field. Dunno if this is a hard-coded pick-list, or user configurable in some way, but i do think usage of this field should be more a matter of Convention than Constraint.

[mstenta]

@walt

is there some way to have other options for these flags beyond the default? (Priority, Monitor, and Needs Attention -at least in my Farmier-hosted instance)?

Flags must be added by a module - but it’s very easy to do. For example, here is the “Biodynamic” module, which only adds a single “Biodynamic” flag: GitHub - farmOS/farm_biodynamic: Provides a flag for marking records as "Biodynamic" in farmOS.

This file specifically is what defines the flag: https://github.com/farmOS/farm_biodynamic/blob/2.x/config/install/farm_flag.flag.biodynamic.yml

So a module with a file for each flag is all you need! @walt if you want to start a separate topic for your specific ideas, I’d be happy to discuss further.

[walt]

Cool! Had no idea a module could be so simple; will definitely work up a spec for ours -but first, i want to understand a bit better about this particular proposal, both in terms of (1) the specific flag scheme related to farm/crop management regimes that @gbathree has proposed; and (2) the concept of a system-level affordance to enable alt flag schemes as a user config option.

Regarding these two aspects of the proposal, i’d like to understand:

1. Would that scheme Greg has proposed enable delivery of a filtered view of all records that an organic certification inspector would need to see, and nothing more? I ask, because my farm is well-along in process of getting some of our ag ops certified organic (should be fully certified by end of this calendar year). That is: some ops, but not all - this distinction is important to us.

2. Can it be possible to have different flag-sets in a farmOS instance, depending on the datatype/ category, such that we might have different flag-sets for Logs vs Assets - perhaps further differentiated across different Asset subtypes (e.g. Animals vs Plants)?

NB: If answer(s) to the above would be different, depending if the instance is self-hosted vs at Farmier, it would be good @mstenta if you clarify what any such difference(s) might be.

/walt

@mstenta

Flags must be added by a module - but it’s very easy to do. For example, here is the “Biodynamic” module, which only adds a single “Biodynamic” flag: GitHub - farmOS/farm_biodynamic at 2.x

This file specifically is what defines the flag: farm_biodynamic/farm_flag.flag.biodynamic.yml at 2.x · farmOS/farm_biodynamic · GitHub

So a module with a file for each flag is all you need! @walt if you want to start a separate topic for your specific ideas, I’d be happy to discuss further.

[mstenta]

@walt

Would that scheme Greg has proposed enable delivery of a filtered view of all records that an organic certification inspector would need to see, and nothing more? I ask, because my farm is well-along in process of getting some of our ag ops certified organic (should be fully certified by end of this calendar year). That is: some ops, but not all - this distinction is important to us.

If you flag your records as “Organic” then you can use the existing filters to show only those with the “Organic” flag. This is the primary use-case for flags: filtering records. If you’d like, I can enable the module that provides the organic flags in your instance, @walt

@walt

Can it be possible to have different flag-sets in a farmOS instance, depending on the datatype/ category, such that we might have different flag-sets for Logs vs Assets - perhaps further differentiated across different Asset subtypes (e.g. Animals vs Plants)?

This wasn’t possible in farmOS 1.x, but we did something similar to this in 2.x with Asset ID Tags (which were previously only on Animal assets). So we may be able to reuse that approach for flags, to limit which flags are available on assets vs logs, and further which asset types and log types. This is not implemented currently, but could be opened as a feature request.

@walt

NB: If answer(s) to the above would be different, depending if the instance is self-hosted vs at Farmier, it would be good @mstenta if you clarify what any such difference(s) might be.

The only limitation that Farmier has is the modules that are available. In a self-hosted context you can download any module you want, or create your own. For security reasons Farmier limits to trusted modules, and/or has a review process for custom code before deployment.

If we were to create a central repository of flags, my assumption is that there would be a core feature in farmOS that allows you to browse and import flags from that list. This would be part of farmOS core itself, and therefore would be available on Farmier hosting without the need for additional modules. I really like this idea and I think it makes a lot of sense for the long term (both for flags and potentially other importable config entities in the future).

[graffte]

Just started poking around the 2.x release. Noticing that the Flags are all colored green now. This loses an important visual cue when scanning a long list of log entries. Can the flags have user assigned colors?

[mstenta]

@graffte - Flags are defined/added by modules, and it would be up to the module that defines them to add CSS styling for them. Every flag gets a unique CSS class to use for this. I know some modules (like farm_organic) are providing flags, but are not styling them yet in their 2.x version. We’ll have to open separate issues in each module. I’ll open an issue in the organic module for the three flags it provides.

Edit: Provide CSS for organic module flags [#3244863] | Drupal.org