When Im filtering to find a specific log by using categories it appears that the filter is using an “or” operator. Is there a way to filter with an “and” operator. For example, I was recently looking for breeding records for all my sheep. I wanted to filter for all logs that were tagged with both “sheep” and “breeding”. and not all logs with “sheep” or “breeding”.
Is there a workaround for this type of filtering?
Oh that’s interesting @BOTLFarm - you’re right! It’s currently configured to use the “Is one of” operator, instead of “Is all of”. See attached screenshot of the Views configuration (for /farm/logs page).
I guess the next question is: is it safe to assume that the general expectation would be for it to be “AND” instead of “OR”? I personally think “AND” would make more sense, and that is actually how I would expect it to work. But… is it OK to change it or will that affect existing users?
Another option: there is a checkbox in that screenshot that says “Expose operator”. What this would do is give the user the option to choose how it should work on a case-by-case basis. That would give the ultimate power. But it means the UI gets a bit more complicated… and if we enable that on Categories should it also be enabled on other filters? Probably?
In the meantime, you can modify that yourself by going to Admin > Structure > Views, editing the View you want, and clicking on the “Log: Log category (exposed)” link in the “Filter criteria” group. Note, however, that each log type has its own View so you may need to make the change in multiple places. And it means that you’ll be using an overridden configuration, which may get reverted when you update (although maybe not, in this particular case because Views is pretty well separated in the Features module config management). It does mean that you won’t get any updates that are made to the default Views config though… but you could always revert and reapply your changes after updating too. Ideally we can include a change in farmOS core itself that meets your needs, then you don’t need to worry about that. 
There are some requests to make some other changes to Views too… like click-sortable columns. So I may have my hands in that config in the near future… might be a good time to look at both.
I have never seen the “views” page before. For some reason this module was not enabled. Wow, this lets someone change so much. Thanks for pointing it out. I wil spend some time poking around in here.
I personally think the “AND” makes more sense for categories and all filters, however I do like the flexability of exposing the operator for users to choose with defaults set to “AND”.
Can you explain a bit more about how changing things in views works with updates? I thought after an update everything outside of the “sites” folder is changed. Is the views part of the sites folder?
Yea! Views is super powerful! It’s basically an SQL query builder UI, and we use it for pretty much all the lists in farmOS.
Can you explain a bit more about how changing things in views works with updates? I thought after an update everything outside of the “sites” folder is changed. Is the views part of the sites folder?
Yea, so basically Views is “configuration” and that stuff is potentially stored in two places: in code and in the database. All of the Views that farmOS provides are stored in code in various modules. But, it’s possible to “override” that code by making changes to the Views config in the UI. When that’s done, the new config is saved in the database.
When it comes time to update, if there are upstream changes to Views config, the code files will be changed, but the database config will not (shouldn’t be anyway). Then, you have the option to “revert” the Views to use the config stored in code, and discard your overrides, if you want.
The Features and Diff modules can also be used to examine exactly what is overridden. Try this: make some changes to a View, then go to /admin/structure/features.
There’s a lot more to it, but that’s the basic idea! It’s super powerful for customizing things, but the main consideration is updating. That’s why I wrote this (somewhat vague) page on farmOS.org: Update Safety - farmOS.org
Thanks for the clarification @mstenta. I was able to make some changes last night and revert back to the original code. Thanks for helping me get more confident playing around with the backend of drupal/farmOS
