Contrib.social

Private Files Field Loses Reference When Node has a New Revision from Published to Draft

Open on Drupal.org →
Created on 21 May 2024, 4 months ago

Problem/Motivation

Whenever a new revision is created from Published (to Draft), a private files field we have on the node loses the reference to the file. This happens on all users EXCEPT user 1.

The private file system is set up correctly and all users with access are able to view the files when a node is published.

We also have the group module installed which handles permissions in addition to Core on this content type. We believe that this problem might be a permissions issue since user 1 does not have the problem?

Additionally, we are using content moderation for this node type and have workflow buttons set up as well to handle the transitions between content moderation states.

We do have ECA running some tasks in the background depending on the different states in content moderation for this content type but didn't think that was causing this issue.

To be honest, we are not sure where to start to find out where this problem is originating from. It seems like a content moderation issue due to the nature of the problem, but it could be something unrelated and tied to something else like revisions. How do we start to determine the cause of the problem?

Steps to reproduce

We have a content type Article that has a private files field set up. Go into any node that has an attachment in that field and is published. Create a new draft. The new revision has no attachments in the field now.

Proposed resolution

We found that a record was not being inserted into the table for the node revision for that field, and that's why the field loses reference to the file. The file still remains in the private files folder as well. However, we do not know why the record is not being added to that table.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

🐛 Bug report
Status

Closed: works as designed

Version

10.2 ✨

Component
Content moderation  →

Last updated 1 day ago

Created by

🇺🇸United States tyler.hastain

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @tyler.hastain
  • Issue was unassigned.
  • Comment 4 months ago →
    🇺🇸United States tyler.hastain
  • Comment 4 months ago →
    🇺🇸United States cilefen

    Are the steps to reproduce valid on a newly-installed Drupal 10 without contributed modules?

  • Comment 4 months ago →
    🇺🇸United States tyler.hastain

    Thank you for getting us headed in the right direction! In trying a fresh reinstall and trying to reproduce the issue, we discovered that it was an ECA model that we have that was causing the problem. We are going to dive into that instead. Thank you for your help!

  • Assigned to tyler.hastain
  • Status changed to Closed: works as designed 4 months ago
  • Comment 4 months ago →
    🇺🇸United States tyler.hastain

    We realized that this happens because of 2 different ECA models that we have running.

    1st Model: We have an ECA model that when an article is moved to draft from published, that it populates the user who moved the article to draft into a "checked out by" field and resaves the article. We use this field to disable all fields while an article is checked out by someone to everyone except the person in that field.

    2nd Model: This ECA model disables all the fields on an article if the logged in user is not the user in the checked out by field and the article is in the draft state.

    These two models together caused the problem. Model 2 disabled the attachment fields on the initial move from published to draft. Model 1 came in to update the checked out by field and resaved. However, since the attachments field was disabled, it did not save the attachments field correctly on the resave. In other words, it saved the field as empty since it was disabled.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024