Termination events

[mstenta]

@wotnak

I’ve created a custom module adding asset termination farmOS Asset Termination | Drupal.org .

Wow! Well done @wotnak! And welcome to the forum!

I like how consistent this with the way farmOS core handles movements, group membership, etc (with the is_termination boolean + computed field etc). Always a fan of consistency.

@wotnak

Drupal composer packages repo (packages.drupal.org) automatically adds dependencies from .info.yml to composer.json of the module following the logic that if for given dependency there is a project with the same name on drupal.org then add it as required dependency. project_composer.module · 7.x-1.x · project / project_composer · GitLab

Ah yea we discovered this issue as well, and @Mixologic (renowned drupal.org expert ) shared this workaround: https://www.drupal.org/project/farm_forest/issues/3190919

Tl;dr: don’t include farm: in the dependency. That doesn’t help in this case, as you pointed out, because you want to depend on farm:asset, and the asset project exists on drupal.org.

so maybe a good option would be to rename asset module to farm_asset, so it can be declared as dependency by contrib modules.

Unfortunately we most likely won’t be doing this now that farmOS v2 is “stable”. It was farm_asset in v1, but we decided to make it “lower level” for consistency with the log module… with the thought that maybe we could split it out to a separate contrib one day (perhaps taking over the drupal.org/project/asset namespace one day… but that’s certainly not a high priority). Anywho… a bit of a tangent… it might be worth opening an issue in https://www.drupal.org/project/issues/farm_asset_termination to think more about this… happy to add more specific thoughts there!

@gbathree

@mstenta is this kind of how you imagined the implementation?

Not exactly! But this exists and my ideas don’t! So…

I was proposing a more general solution, which could be used to represent termination date. This module creates a more explicit concept of “termination”. I’m still thinking through the costs/benefits, but the whole point of having this “contrib” space for farmOS modules is for experimentation like this, so I’m thrilled to see it! Curious to hear what others think too!

(Perhaps the more general approach could be something we aim for in farmOS 3.x as well, and this module can serve until then… see related: Proposal for farmOS 3.x core datamodel improvements: Immutable Quantities & Soft Entity Deletion)

@wotnak

The best option would be probably to add a machine name field to all taxonomy terms, so they can be unambiguously referenced by it in code, no matter what actual title formatting or language is used on a specific farmOS instance. But this should be probably handled in farmOS core.

To take this idea a step further: one idea that has come up recently is to add some kind of “ontology reference” field to taxonomy terms, which could be used to link to an external ontology ID of some kind. The idea is the same: it would be more specific than the term’s “label” (which could also be represented in other languages perhaps!) Perhaps we should open a dedicated thread to discuss that?

@wotnak

For now, I could add configuration option that allows to select taxonomy term (category) that will be used to mark termination logs and move automatic marking of logs with termination category as termination logs from module install to manual action that can be executed from configuration page.

Making this configurable would be nice IMO. To be honest it feels a bit unnecessary to add a category to the log if it already has is_termination boolean field which can be used for filtering. Seems like it would need a bunch of extra logic to keep those two things in sync if one gets changed but not the other.

@wotnak

Currently, it archives all assets referenced in the termination log. But I could probably add an option to select which referenced assets will be terminated.

I think what @gbathree was asking was whether it ONLY archives assets referenced in the log’s asset field, or if it also looks at the log’s equipment, location, and other asset reference fields. The core convention is that logs are only acting on assets in the asset field, so those are the only ones it should touch IMO.