Make Metadata Display Entities Revisionable

[DiegoPino]

What?

Since metadata display entities drive almost every user facing and import facing transformation we should make them revision able so small changes/mistakes (logic ones, since we already validate them) can be reverted and also there exposed log of the evolution of a twig template in the form of these entities

How?

The task at hand is well document

• https://www.drupal.org/docs/drupal-apis/entity-api/converting-a-content-entity-type-to-be-revisionable-and-publishable

And involves:

• Updating the Annotations on the Entity
• Adding new Form routing for the Entity
• Extending the Entity to a different Class
• Making Update Hooks for already ingested Entities
  An on our side/integration
• Making sure that we always use the latest published Entity whenever we load it (testing first, then checking where we fail)

Twig templates (our metadata display entities) are used on

• Format Strawberry Field
• Webform (not too much, probably a small check on the current webform elements is enough)
• AMI

@aksm this should not take more than a week. Please open a pull as soon as you start working on this so we can have an ongoing discussion. Thanks!

[aksm]

As of now, Metadata Display Entities are revisionable in #216, but there is no UI/routing/access control to manage the revisions that are generated. There is an RTBC patch in this Drupal issue that hopefully gets committed to core soon, which means we won't have to duplicate existing core code (from nodes for example) or make everything from scratch. We could roll with this as is and users would be able to generate revisions for now that they'd be able to work with in the next release, but maybe that would just be confusing? Otherwise, we can bump this to 1.1.0. @DiegoPino thoughts?

[patdunlavey]

@aksm and @DiegoPino I see that the Drupal issue has been marked as "Closed (fixed)". Is there further work needed on this PR (other than review/testing)?

[DiegoPino]

Review and testing is a lot! Do you want to review/test? That would be helpful. Also if its marked as closed fixed, composer.json needs to be mark the version were it was fixed

[patdunlavey]

@DiegoPino The Drupal core revision for that update is 10.1.0. Should I put this in a PR against @aksm 's format_strawberryfield/composer.json?

[DiegoPino]

Ah gosh friend. Not yet then. I don't think we can go Drupal 10.1.0 yet. Too much not tested and a big Company just fired the main Drupal Core Committers ... so... let's tag this then for 1.2.0?

[patdunlavey]

Ah, that's a big disappointment! Looking at what will be involved (running composer update with drupal/core set at 10.1.0 in the root composer.json) shows a scary amount of stuff, including the php version (8.1).

Here's I think a complete list for the current archipelago composer.json (culled from running composer update on my local, whose composer.json includes a good number of additional dependencies - I removed those from this list):

• archipelago/ami 0.5.0.x-dev requires drupal/core ^9
• strawberryfield/strawberry_runners 0.5.0.x-dev requires drupal/core ^8.9 || ^9
• strawberryfield/strawberryfield 0.5.0.x-dev requires drupal/core ^8.9 || ^9
• drupal/core 10.1.x-dev requires php >=8.1.0 -> your php version (8.0.16) does not satisfy that requirement.
• drupal/config_inspector dev-1.x requires drupal/core ^8 || ^9 (has D10 compatible update)
• drupal/display_field_copy[2.0.0, ..., 2.x-dev] require drupal/core ^8 || ^9 (D10 compatibility ticket)
• drupal/jquery_ui_slider[1.1.0, ..., 1.x-dev] require drupal/core ^8 || ^9 ( D10 compatibility ticket)
• drupal/tokenuuid 2.0.2 requires drupal/core ^8.8 || ^9 (D10 compatibility ticket)
• drupal/twig_tweak[2.6.0, ..., 2.x-dev] require drupal/core ^8.7 || ^9.0 (has D10 compatible update)
• drupal/views_bulk_operations 4.1.2 requires drupal/core ^9 (has D10 compatible update)
• drupal/webform[6.2.0-beta3, ..., 6.2.x-dev] require drupal/core ^9.4 (D10 compatibility ticket)

[DiegoPino]

@patdunlavey reviving this here. Now that I have #391 we can start moving to D10.1. I will open a pull this week. Should not be hard

[DiegoPino]

A side note about this. Making Entities revision able does not mean we can migrate via JSON API the revisions. we can only ingest a Default revision via the API

[DiegoPino]

Ok, now dealing with this:

https://www.drupal.org/project/drupal/issues/3317361

Unanswered for 7 months .... mmmmmm

[DiegoPino]

First pass solved via 7f6b946
For more work on this (when the time comes) I will open a new ISSUE. The main thing that comes to my mind is that we will need a custom access handler (entity annotations) to allow more fine grained permissions regarding restoring/editing revisions @alliomeria. But we can cross that bridge when we get there (as some wise co-worker once said)