Termination events

[mstenta]

I think we are conflating the solutions to two separate “problems” (or requirements is a better word):

1. Creating a concept of “when an asset was terminated”.
2. Archiving terminated assets.

I think it’s important to note that “archived” status doesn’t have any implicit meaning in farmOS. It is only used as a visibility mechanism to hide assets from lists/maps/etc in the UI.

It does not mean that the asset is “terminated”. So the farmOS Asset Termination module solves problem 1 first and foremost by providing this explicit meaning to assets. It just happens to also be trying to solve problem #2 at the same time, which makes sense, but I think it helps to keep them separate in our minds.

@wotnak

I would consider a log marked as done with timestamp set in the future as being in invalid state.

What is valid/invalid “state” of logs doesn’t really matter from a data model perspective. farmOS determines location by asking: “what is the most recent done log with a timestamp less than or equal to now” - but now is a parameter of that function. Granted, it’s the default parameter, and therefore affects most of the default behavior - but we shouldn’t conflate the behavior with the data model and how it represents things, which is essentially timeless.

For all intents and purposes, a future log that is marked done IS DONE… in the future. It may not be “the future” right now, but it will be eventually… without making any changes to data in farmOS. So as time goes on, the state of farmOS changes automatically - without making any changes to the database. Think about it like playing a cassette tape: you can rewind/fast forward the “present moment” and it changes the current state without changing what’s recorded on the tape. Maybe this way of thinking is a little esoteric, and I’m not sure if it helps this conversation but it is worth stating I think.

In practice, I agree that logs should be marked done when they are actually completed. Creating logs in the future with a status of “done” leaves open the possibility that you’re creating future incorrect data, because maybe it doesn’t happen as planned! But, that’s a different problem, IMO. And we should NOT disallow future “done” logs from being created.

I just say all of this so that we can take a step back and ask what problems we’re trying to solve.

@gbathree Some of these questions might depend on specifically what you’re trying to achieve. I know in private chat you and I discovered that “done termination logs in the future archive the asset” and that was an issue… but in practice you won’t be creating done logs in the future, right? If you are, then maybe we should be digging into that more and asking why, but I don’t think you are.

It seems like @wotnak fixed that specific issue… basically by limiting the logic so that it only archives assets when a termination log is save if the log timestamp <= now. That makes sense to me. It means that assets WON’T be archived in those circumstances, though, so then the next step is asking: should there be logic to automatically archive them in those circumstances?

I think one could argue: NO, that is a weird case (done logs in the future), so leave it alone. It’s not farm_asset_termination module’s problem. The user can archive those assets themselves later if/when they want to (again, trying to separate the two intentions/problems we’re trying to solve here).

Or, it could use a cron job to automatically find and archive assets, like @wotnak suggested:

• in a background job run in cron?
  • it looks better from the perspective of good programming practices
  • but since farmOS documentation recommends scheduling cron jobs once a week in many cases, it would probably take few days from the actual termination event for the asset to be archived

If the module must handle this weird case, then that seems to be the best way to do it, from my perspective. But I still don’t know if it’s actually a problem that needs to be solved. (Again: @gbathree will you actually have future done logs ever??)

[mstenta]

@mstenta

but in practice you won’t be creating done logs in the future, right? If you are, then maybe we should be digging into that more and asking why, but I don’t think you are.

Oops I should have finished reading your comment @gbathree before I sent my reply …

@gbathree

I do think I’ve been using logs willy nilly in the future, marking everything as done when in reality that’s not appropriate… at a minimum someone should be confirming that the action was completed (or not… or move the date if it was a different date, etc.) even through that’s somewhat of a pain if you’re using farmOS primarily as a data store and not an active management system (as we often are).

I can’t really imagine a situation where you would need to submit future done logs, but I also don’t think it should disallowed. It raises some potential issues like I described above, but conceptually speaking it’s perfectly OK from a data model perspective.

So, like I said, it really boils down to the fact that you ALSO want to archive assets at the same time… which is a separate intention - and the only reason you would need to do that is to prevent them from showing up in default UI lists etc.

So… long story short… I think @wotnak’s suggestion to auto-archive terminated assets via cron could be a valid option that the module provides… but I still question whether or not it would be widely necessary.

[mstenta]

@Symbioquine

The better option I was alluding to - and I’m not sure it is reasonable to try and do it in a contrib module - is to actually change the core asset status field to work like location or group does. That is, to make it not store any data directly, but always be computed as a function of the logs (in this case termination logs) that reference the asset.

I wanted to respond to this idea too @Symbioquine, because I’ve had the same idea pop to mind before too.

To reiterate what I said above, the status field should probably be called visible or something, because it is largely just a UI visibility toggle. The “state” of an asset could be described in a much more elaborate and nuanced way. For example many farm management systems that focus on row crops like corn will describe the status based on the growth stage of the corn. Making a more elaborate concept of “asset state” based on logs (similar to location) would be a really fun thing to explore! Another forum topic perhaps…

[gbathree]

In short - my problem is solved thanks @wotnak - the behavior is now like is_movement and works for me - so thanks! Future done doesn’t make sense IMO but it’s not an immediate problem I need fixing either.

My many other notes that you can ignore but already wrote so I guess I’ll throw them in…

@mstenta

I think it’s important to note that “archived” status doesn’t have any implicit meaning in farmOS. It is only used as a visibility mechanism to hide assets from lists/maps/etc in the UI.

That’s actually all I want it to do. In the convention we’ve used, termination is defined in log_category as termination. So all I want is to archive the asset so that it won’t show up in dropdown lists for user for entering plantings in future years. In short - archiving is exactly what I think is needed!

@mstenta

And we should NOT disallow future “done” logs from being created.

I’m fine not requiring done status to only occur past the date. But I still would say that a very typical and high level and highly recommended convention is to not mark done until something is actually done In that sense a pending_until_date status would support that very common and reasonable convention, and not otherwise prevent other actions from occurring. But… probably it probably is a different module or (if broad agreement) core.

@mstenta

I know in private chat you and I discovered that “done termination logs in the future archive the asset” and that was an issue… but in practice you won’t be creating done logs in the future, right?

Well, in theory, but in practice, it’s going to happen. Pasa farmers will fill this out on December 21st and they’ll put some items they know they’re going to do on December 28th - pretty much guaranteed. So generally speaking, this won’t happen. But also, the behavior I’m trying to solve remains useful IMO outside my specific application, and is consistent with the types of future logs people would want to make.

@mstenta

It seems like @wotnak fixed that specific issue… basically by limiting the logic so that it only archives assets when a termination log is save if the log timestamp <= now.

I agree, he did! But he also brought up a good point about the intention and function of status, which perhaps is a separate issue but one that I think remains valid.