At the Farmer 2 Farmer event, I got talking about SOPs with a couple other growers and mentioned I had a template that I had gotten from some winter conference along the way. But the template is an actual sheet of paper - how novel!
I scanned it and it’s attached here for everyone to use. Doing more SOPs are definitely on my ‘to do’ list as an important step in ‘growing up’, as far as my business goes.
I like the idea.
Should be shareable on email, or possible to restrict access for users.
I don’t want all my farmOS data to be accessible to other users.
Adding a Document capability could be useful. I’ll try to outline a couple use cases.
I’m in my annual exercise of updating and feeding documentation to my organic certifier so this is sort of top of mind. The pile of docs just gets deeper each year. This year’s add is an Organic Fraud Prevention Plan (OFPP) to add to my Organic System Plan (OSP) this year per new USDA mandates.
Currently I mange the OSP documentation outside of FarmOS in a Google Workspace my wife and I set up for the business. This works okay, but OSP document revision management and coordination of document updates with the certifier is manual and somewhat tedious. Even for a small operation like mine only doing organic crops, my OSP is about 20 different documents. Some of these need to reference FarmOS log entries as evidence of my record keeping system. Pulling out the log entry references with the attached files (like supplier invoices etc) in a form for allowing inspections by the certifier gets to be time consuming. Done right FarmOS could be useful tool in integrating all this and assist interactions with my organic certifier.
Similarly, I have a bunch of documents that get sent back and forth to the USDA Farm Services office with the county. These are at a Farm and/or Tract level across my operation. I force fit my USDA documents (mostly scanned pdf) into FarmOS under Activity logs with a Log Category (USDA Records) for filtering. This allows me to pull up these documents based on field locations (Tracts) and find the latest versions quickly.
A simple first step might be to just create a simple “Document” asset type that appears under “Record > Assets”. This would be trivial to code, and would allow you to move your docs out of Activity logs @graffte. Doing so might inspire next steps, like adding additional ways to categorize/filter them, special reference fields (eg: for referencing logs and assets), etc.
I also like the email and access control ideas you mentioned @pat. The access control stuff could be generally useful for any asset type IMO - might be worth its own forum topic to brainstorm.
What do you think? Worth a quick first step to start experimenting?
I did further investigation into this as well but having trouble finding where I documented the results… but overall I have some reservations about creating general document assets. Again, it really seems like this is a distinct concept from on-farm assets. They certainly need to be associated with assets and logs but perhaps there is a better way to design all of this. The request for a “document center” really illustrates this to me and how that experience is quite different than how you would manage other types of assets.
One thing I do remember finding is that we have an inconsistency between how images and files are handled. Currently only files can have an additional text/description associated with them. Images do not have this capability because the image reference field simply does not include the option. The ability to add some simple metadata for each uploaded file seems quite important. A document asset would not necessarily solve this issue, especially considering “a document” could have multiple files/images uploaded. This has led me to believe it would be best to replace all file + image references to use some kind of a wrapper entity that illustrates this concept of “documents” or “media” more generally.
Naturally, this makes the Drupal core Media module look quite appealing. Out of the box there are a lot of features this could provide, an important one being that each type of media could have separate bundle fields to store metadata specific to that type of media. It is also likely that we would get various UI features like the Media browser “for free”. The biggest issue I remember (and it is significant) is that the permissions associated with media entities are quite complicated and they very much default to being public.
And just to clarify, I was thinking about making a contrib module to experiment with this, not a core module. Something that could be installed on @graffte and @pat’s instances as early as this week. Nothing would preclude migrating from a document asset to a different entity type in the future once that is settled (although care should be taken by anyone experimenting with it to be aware that not everything might be transferable).
On the point of “first class entities” (which was also mentioned in the thread on “Farm Assets”: Interest in a new Farm asset type?) I think a good question to ask is also: what features of assets DO we want on the new entity type? In many cases, we may find that a lot of the asset entity features are in fact desirable. So it’s worth doing a comparative analysis along those lines too…
For example:
Do Documents need to be marked as active/archive? Yes.
Do Documents need to have an Owner? Maybe?
Do Documents need to have flags applied to them like “Needs Review”, “Priority”, etc? Seems useful!
Do Documents need to have location and be moved around? Sure, if you are using them to track physical documents.
Do Documents need to be grouped, and to change group? I don’t see why not?
Do Documents need inventory? Probably not.
ID tags? Probably not either… but maybe useful.
The benefit of using the existing asset type is consistency and we get all that other stuff for free. Plus we don’t need to maintain another entity type.
Also worth noting: in farmOS v1 “Areas” were not assets, because they seemed like they needed to be their own thing, but over time more and more overlap of requirements with assets became clear, so we made them into asset types in v2. So if it seems like I’m too often championing the “everthing’s an asset!” idea, some of it is historical.
Not disagreeing at all that we should give it more thought before adding something to core! Also not opposed to experimenting with trivial solutions in contrib to feel out where the pluses and minuses are.
in farmOS v1 “Areas” were not assets, … we made them into asset types in v2
Also worth noting: this was not without it’s challenges too. We needed to add the ability to “turn off” movements for location assets, and we added the is_fixed, is_location, and intrinsic_geometry fields as part of that. Just to say… if there are some features of asset entities that “feel weird” in certain cases (like farm asset or document asset types), perhaps we could also explore ways of disabling those features for certain types too.
Maybe worth mentioning that Drupal does have some functionality for content management built-in that aren’t normally used in farmOS but might also be a starting point for managing documents. i.e. the Node entity type and lots of modules that extend that functionality.
I made an experimentalfarm_document module for @pat to test out, and I spun off a separate forum topic for discussing the pros/cons of that approach here: Experimenting with a Document asset type
@graffte If you’d like to try it too, send me a PM - but please see the “NOTE” in that forum thread.
