Group creation and filtering

Hello there,
I want to enter the months under the seasons in taxonomy → farm season.
I made a description as in the picture.

Can I filter the log in the following way?

season → spring → march, april
season → summer → july

When you choose season, spring, summer and winter will come.
when you choose summer july will come .

1 Like

Hey @compact2 thanks for the screenshot example of the seasons! Can you clarify how you want to filter the logs?

First, I believe that Plant assets are the only entities that have a seasons field on them right now. If you want to filter Logs by season you would need to add another field to logs yourself.

Thinking a bit more, I suppose it could be possible to use the (optional) date ranges configured in the seasons without adding a field to logs… this way you could choose a season and filter logs by their timestamps? This would have to be custom code though. Another issue with this is that the date ranges include the year, so you would need to duplicate the “seasons” for each year. This is an interesting idea - we can already filter logs by timestamp, so I guess this could just be a bit of a “shortcut” to specifying a date range.

Or perhaps you could filter by logs that reference a plant asset that references a season… that might be possible too using Views relationships without any custom code. (Looks like this might be a similar (older) feature request: https://www.drupal.org/project/farm/issues/2934719)

As far as integrating this as a Filter with Views, I did a bit of searching and it seems like this might not work out of the box. It gets complicated if you want there to be two UI components because one must update when the other changes. If you only want one UI component it might be easier - for Drupal 7 this module might be necessary: https://www.drupal.org/project/hierarchical_select

1 Like

Just want to mention also: in farmOS 2.x the Season terms no longer have a date range field on them. This field was not being used for anything in farmOS 1.x, so we decided to leave it out of the 2.x data model and migration. So if you are using it in 1.x you will need to migrate that data yourself.