Problem/Motivation

We are beginning to identify potential future changes to farmOS that would be considered "breaking changes", so I'm opening this meta issue to start keeping track of ideas. We can spin off new issues as needed and make them children of this one.

More details tbd...

Comments

m.stenta created an issue. See original summary.

m.stenta’s picture

@symioquine started this forum topic a few months ago, which was the original inspiration for this: https://farmos.discourse.group/t/proposal-for-farmos-3-x-core-datamodel-...

m.stenta’s picture

One thing I'd like to consider is adding more injected dependencies to the QuickFormBase class, like entity_type.manager, asset.location, and other commonly used services.

m.stenta’s picture

Maybe we can refactor some of our classes to take advantage of this technique: https://www.hashbangcode.com/article/drupal-9-extending-drupal-base-clas...

m.stenta’s picture

Allow multiple material terms on material quantities: https://farmos.discourse.group/t/allowing-material-quantities-link-to-mu...

m.stenta’s picture

Deprecate and remove farm_migrate module (for migrating from 1.x). Require that data is migrate from v1 to v2, and then upgrade v2 to v3 (no migration necessary).

Edit 2023-08-23 - Opened a dedicated issue: #3382598: Deprecate farmOS v1 migrations

m.stenta’s picture

Linking to #3285412: Support allowed_values_function so I remember to add a patch for that if it isn't merged before 3.x.

m.stenta’s picture

Another idea that came up in the forum (https://farmos.discourse.group/t/add-setup-page-to-farmos-core/1712/9): should we prevent taxonomy terms from having multiple parents? And if so, how do we deal with terms that may already have multiple parents. This should have a dedicated discussion thread in the forum - I just want to note it here so I don't forget about it.

m.stenta’s picture

m.stenta’s picture

Not a breaking change, but it would be great if we could add Image/File fields to all taxonomy terms too: https://github.com/farmOS/farmOS/pull/536

m.stenta’s picture

m.stenta’s picture

I think all of the breaking changes that we can make are complete in my 3.x branch (except for one that @paul121 is currently working on, mentioned below). We won't have time to make any other big changes, unfortunately, so they will need to wait until 4.x.

I patched jsonapi_schema to fix #3285412: Support allowed_values_function.

#3382616: Remove v1 migrations from farmOS 3.x is done.

#3357679: Allow material quantities to reference multiple material types is done.

The last big one is the upgrade of the simple_oauth module from v5 to v6, which @paul121 is working on currently. We may include that in the 3.x branch when we push it to origin, or open a PR for it after that, but before we tag the first 3.0.0-beta1 release.

m.stenta’s picture

I patched

jsonapi_schema

to fix #3285412: Support allowed_values_function.

Update: I decided to remove this, and instead I'm going to propose we take this approach instead: #3397275: Use OptionsProviderInterface::getPossibleOptions() for allowed field values (anyOf / oneOf) - This will most likely be included in a follow-up release of farmOS 3.x. It is not a breaking change - it only adds to the existing JSON Schema.

m.stenta’s picture

Version: 2.x-dev » 3.x-dev