I’ve duplicated a view, and try to change the late task block.
Is it possible to make a list of all medical logs currently in a meat withdrawal period?
The “meat_withdrawal” field contains number of days
So filter for logs where timestamp + meat_withdrawal days > today
I don’t think that the built-in filter in your screenshot will work for what you want. It’s a very simple filter that comes with Drupal core and doesn’t offer much (as you can see).
You will probably need to write a custom Views Filter or Argument plugin to customize the SQL query with the logic you want.
Tip: You can turn on a Views setting to show the actual SQL query that is being run by a View. I like to start with that, paste it into a database browser so I can experiment with queries directly until I know exactly what the query needs to look like. Then I work backwards from that to build the Views plugin.
Before going too deep, it might be worth asking: is it really LOGS that you want to be showing in the block? Or do you want to show ANIMALS that are currently within a withdrawal period?
I believe @paul121’s REI module adds a dashboard block to show assets that are currently under a restricted entry. You might take a look at that to see how it works.
I wonder would it be easier to calculate the withdrawal end date when saving the log then show a list of logs with withdrawal end dates in the future?
It would need an extra field as entering the withdrawal in days makes most sense, but calculating and storing the end date shouldn’t be too difficult. It would also be best if this is done only if the log is marked done.
Yes, that’s been on my list as an alternative too.
But I think I’m pretty close to nailing it with custom fields now.
Last piece of the puzzle is to reference the days value in the trimmed withdrawal field.
The rest is ok. I can manipulate the date if I hardcode the number.
A custom text field with the following calculates the latest withdrawal date.
Had to show the log’s timestamp field as timestamp and not date-string.
I was going to hide it, so no problem with that.
{# ---get withdrawal days as a number--- #}
{% if meat_withdrawal_value is not empty %}
{% set withdrawal_days = meat_withdrawal_value|replace({' days': ''})|trim %}
{% set withdrawal_days_num = withdrawal_days|length > 0 ? withdrawal_days|number_format(0, '.', '')|trim : 0 %}
{% else %}
{% set withdrawal_days_num = 0 %}
{% endif %}
{% set current_timestamp = "now"|date('U') %}
{% set one_day_in_seconds = 86400 %}
{#{% set nothing_integer = nothing|trim|number_format(0, '.', '')|trim %}#}
{% set days = withdrawal_days_num * one_day_in_seconds %}
{% set log_timestamp = timestamp|striptags|trim %}
{% set new_timestamp = log_timestamp + days %}
{{ new_timestamp|date('d. F')}}
The view shows only the log name, and the last withdrawal date.
Perfect for a dashboard pane.
But from here I’m a bit lost.
Do the views survive a farmOS update?
I guess I should try to wrap it as a module, and that what I see in the Devel tab represent the code of the view??
Wow great investigating @pat. I didn’t know so much was possible with just a custom text field!
Views are saved as “config entities” in Drupal. This means they can be exported as YML files. This YML file can then be placed in a module’s config/install directory and it will create the View when the module is installed.
To export the YML:
Enable the “Configuration Manager” (config) module.
Go to Administration > Configuration > Development > Configuration sychronization
Click the “Export” tab.
Click the “Single item” tab.
Under “Configuration type”, select “View”.
Select your View in the “Configuration name” dropdown.
Copy the YML that appears in the box.
Under the box of YML, you will see " Filename: views.view.[your-View-ID].yml" - this is what the YML file should be named.
Yes, if you create your own Views, they will not be touched by a farmOS update.
This is important: If you override an existing View (that is provided by a module), and you have the “farmOS Update” (farm_update) module enabled, then that View will be reverted to the config defined in the module whenever caches are cleared. The farm_update module only reverts config that is defined in a module’s config/install directory.
If you disable farm_update, then you can be in full control of your configuration. But that means you will need to manually review and revert any config that changes in new releases of farmOS. We cover two use-cases this way: 1) users who aren’t doing advanced stuff and just want easy updates to “default” farmOS behavior and config (keep farm_update enabled), and 2) advanced users who want full control over their config (disable farm_update and ideally manage your config in source control).