When using the 8.x-2.0-beta1 version of this module, I noticed the entity_legal.document.*.yml configuration file kept updating the "published_version" property, every time a new version of a legal document was added and set as current version.

I did some digging through the code, and found hook_entity_legal_published_version_alter(), which mentions "This value will not be exported and is useful for bypassing features exported values." I suppose this note is a leftover from the D7 version, as implementing this hook didn't stop the exported config from pointing to a specific EntityLegalDocumentVersion entity name.

I want to avoid the situation where the client adds a new version of a legal document to the live site.
When an unrelated feature is later deployed to the live site, and the deployment script does a config import, the current version value would be reset or broken.

I was able to come up with a solution that stores the "published_version" name value in the Drupal State API, rather than the config entity. This keeps the config entity value to NULL at all times, not messing up config exports or imports.

You can check this module at https://github.com/svendecabooter/entity_legal_state

I am wondering if there's a better / easier approach to achieve this. Currently I didn't want to change the functionality of the entity_legal module too much, so I opted for this approach that doesn't require patching entity_legal.
However, it might be interesting to investigate this use case some more, and refactor the entity_legal codebase to (optionally) allow this functionality out of the box. Alternatively the entity_legal_state could be added as a submodule, if there's interest in that.

Comments

svendecabooter created an issue. See original summary.

danielnolde’s picture

danielnolde commented

+1 same situation, assessment and need here, and very probably with any website that uses config managed in code to update a production system.

Also, architecturally, published_version does not belong anywhere in configuration, but is definitely state.

@svendecabooter - could you provide a patch against entity_legal for your solution?
I could review that patch and we might get it into the module with the help of a maintainer.

codesidekick’s picture

codesidekick commented
Assigned: Unassigned » deciphered

We always welcome patches :)

pq’s picture

pq commented
Category: Task » Bug report

Going to suggest this gets bumped to "Major" as the legal consequences of this are very severe.

Having the current version maintained within config when that actual version entities are not results in T&Cs not being presented to users in most cases where config management is in use (which should be pretty much all the time in D8) unless the developer or site builder takes steps to work around this, so this seems like a fairly substantial bug to me.

extexan’s picture

extexan commented

I don't know if this issue is related to: https://www.drupal.org/project/entity_legal/issues/2789127, but I'd like to offer my views on this config question. I have encountered the same error stated in the linked issue. This is after initially installing the module and setting up some T&C docs for testing in my local dev environment. Once I was satisfied the module would do as the client wanted, I exported the config and tried to import it into the staging site. That's when I got the "Attempt to create a field without a field_name" error.

I'm wondering why the legal docs created in entity_legal are treated as configuration settings. Seems to me, they should be considered content, like nodes, or taxonomies. Since entity_legel doesn't really have any settings in the "Configuration" admin menu, I think the only config settings that should be exported are the installation/uninstallation of the module itself.

As mentioned above in this topic, exporting configurations for *any* other modules would cause any changes made by the client in the live site to be overwritten (or broken). But I think it's not just the "current version" - it's all config settings.

pq’s picture

pq commented

@ExTexan, I think at the moment legal documents themselves are treated as structural containers and exported in config, but document versions (where the actual editable text of a document are stored) are considered to be content. So the document could be better described as a document type and is effectively a type of entity bundle.

This seems logical to me as I think adding extra types of documents would be as much a matter of site structure as adding say a taxonomy vocabulary. The problem being discussed in this issue is that versions are not exported in config but the reference to the current version is, which causes a bunch of issues as you might expect.

claudiu.cristea’s picture

claudiu.cristea
Primary language Romanian
Location Arad 🇷🇴
commented
Status: Active » Closed (duplicate)

I confirm the problem, but I don't see it fixable with states. The "published version" is neither config, nor state -- it's content. The solution I'm proposing is described in #3067028: Move the "published_version" field from bundle to content entity. I'm closing this as duplicate as the others offers a viable patch that waits your review.