Feeds importer enforces feed author in unexpected ways

Created on 5 February 2025, 5 days ago

Problem/Motivation

When running a Feeds Importer as a Super Admin, I encountered unexpected errors related to text formats (e.g., "The value you selected is not a valid choice"). However:

  • The Super Admin role had full permissions to use the "Restricted HTML" format.
  • The import only worked when I set myself as the Feed author.
  • When a different (although, recently deactivated) user (also a Super Admin) was set as the Feed author, the import failed with text format errors on multiple fields.

Steps to reproduce

  1. Hopefully you have a working feed to test. First, try running the import as the original Feed author
  2. Deactivate the user account of the original feed author
  3. Log in as a different user who has the same permissions as the original feed author
  4. Try to import the feed again

Questions

What am I missing here? I understand that a deactivated user won't have any roles or permissions, which could be why I was seeing errors related to invalid text format. But, I was attempting to run the import while logged in as my current, active, Super Admin user. Why was the ghost of the original feed author haunting my import, and causing it to break? Why were the errors related to text format and not user status?

Is there a clever way to debug failed imports that I don't know about?

💬 Support request
Status

Active

Component

Feeds Import (feature)

Created by

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

Comments & Activities

  • Issue created by @joannascript
  • 🇳🇱Netherlands megachriz

    This issue is related to validation that happens during an import.

    1. Feeds performs validation to prevent invalid values from being imported. For example: if a list field only allows A, B and C, then the import of an item should fail if it tries to set D.
    2. Feeds also performs validation to minimize the chance of SQL errors happening, which are less friendly messages to display to users.
    3. The validation that some modules do depend on the current logged in user. So these modules assume that user performs an action in the UI, they don't account for the possibility that validation can also occur programmatically, like is the case for Feeds.
    4. During cron runs, the current logged in user is anonymous. This was problematic for Feeds users, because that user has usually less privileges and users often ran into validation issues because of the point above.
    5. To fix issue 4, a user switch to the feed owner was implemented during cron runs. The feed owner was chosen because during cron runs it is unknown which user exactly initiated the import.
    6. Users reported bugs that some imports ran fine in the UI, but not during cron - or vice versa.
    7. To fix issue 6, a user switch to the feed owner also happens when running imports in the UI. This way, the validation that happens during UI imports and cron imports is the same and that makes things consistent.

    So, long story short, I think you ran into validation errors because one of the feed owners is blocked and therefore some modules think that a certain user is trying to do something it is not allowed to because they are blocked (or perhaps doesn't have the needed role anymore).

    The origin of the issue is - in my opinion - that some validation depends on the current logged in user. I think that this cannot be fixed in Feeds or I don't know how to. So I think that you ran into an edge case here that is there due to limitations in the system.

    You do have the possibility to configure on the feed type to skip validation (and also to only skip certain types of validation), but then you risk the import of invalid values or imports that are crashing because of SQL errors.

    I hope this answers your question. Feel free to reopen this issue if you have follow-up questions. 🙂

  • 🇳🇱Netherlands megachriz

    Is there a clever way to debug failed imports that I don't know about?

    For debugging failed imports, you could activate the Feeds Log module (included with Feeds). This way you can see which items fail exactly. (If you have a lot of imports, be frugal on for which feed types you keep logging active, because Feeds Log can generate a lot of data.)

  • Thanks for a great explanation! We are going to have to set all of our Feeds authors to a generic Super Admin user who will never get deactivated. Makes sense to me. Thanks for breaking it down.

Production build 0.71.5 2024