I have imported text values from a CSV into a series of D7 user fields. These are not the depricated "profile fields" but fields attached to the user entity. They are new fields.

After this import, I can browse all the users as admin and see that values correctly imported into all the users. But, when using a non-admin account to browse users, I see that only some of the users actually show their fields. This is true on the user page as well as in any user related views (Views module).

I have already done these tests to figure out if these are permissions or what:

  1. As an admin, I see that all accounts have values in their fields. As a schlep, I see that only some show values.
  2. All users have permission to view all the user fields according to the main permissions layout as well as the individual field level permissions.
  3. The fields are not set as hidden, not on the account configuration and not on the view.
  4. The views do not have access permissions set, everyone should be able to see them.
  5. If I create a new user and manually enter values in these user fields then everything is peachy.
  6. If I edit a user that has visibility problems then no amount of user editing, value changes, role changes, foot stomping, keyboard smashing, will make the damned fields visible.
  7. Not all fields are showing this symptom. Non-text fields seem to be showing values correctly. Text fields, however, sometimes do and sometimes don't make themselves visible to visitors.
  8. Whole user accounts are affected. If one user's text field doesn't work then none of the text fields work.
  9. My CSV file was squeaky clean, no freaked out characters or anything.

This is everything I could possibly gather about this problem. If anyone has any insight or sees something I'm missing please chime in.

Thanks.

Comments

seaneffel’s picture

seaneffel CreditAttribution: seaneffel commented
Title: Some user fields are not visible to some users after CSV import » Imported fields ignore field permissions, inaccessible to anonymous users
Category: support » bug

I put this issue aside for a couple of weeks and found later that importing any field through the Feeds Importer then breaks the field permissions, making the field values inaccessible or invisible to anonymous users. I have been up and down the permissions board and rebuilt permissions several times. What could be going on?

seaneffel’s picture

seaneffel CreditAttribution: seaneffel commented
Title: Imported fields ignore field permissions, inaccessible to anonymous users » Field Permissions module prevents correct import of fields

Disabling the Field Permissions module PRIOR to importing my feeds is what turned the corner for me. If you run into this problem then try disabling any module that contains any level of access control, such as Field Permissions, Organic Groups, and all those wonky taxonomy access control modules that exist in contrib.

However, this did not solve the issue with file contents of image fields being duplicated upon feed import: http://drupal.org/node/1171114

seaneffel’s picture

seaneffel CreditAttribution: seaneffel commented
Title: Field Permissions module prevents correct import of fields » Field Permissions module prevents correct import of Feeds

Even better title...

frazac’s picture

frazac CreditAttribution: frazac commented

Same problem for me, even if a long time it has been passed.

MegaChriz’s picture

MegaChriz CreditAttribution: MegaChriz as a volunteer commented
Component: Feeds Import » Code

This issue could be related to the user who performs the import: access modules may act on the active user. On cron runs, the active user is anonymous. This would explain the permissions be wrongly set if importing during cron.

I have been working on a patch to switch to a different user during import: either the author of the feed node (if the importer is attached to a content type) or user 1 (when using the standalone import form).
Can you try the patch from #2541944: Switch to feed author or user 1 during imports (taxonomy mapping does not work with cron)?

frazac’s picture

frazac CreditAttribution: frazac commented

Thanks @MegaChriz!
Tried. Same negative result.
Is there any setting to give or just apply the patch?

(now working on feeds 7.x-2.0-beta4)

MegaChriz’s picture

MegaChriz CreditAttribution: MegaChriz as a volunteer commented

@frazac
Only the patch needs to be applied. Settings don't have to be changed.

To replicate your issue, it would be helpful if you can bundle your configuration in a feature module and provide a sample source file.

The feature module should ideally contain the following:

  • Your Feeds importer
  • Feeds Tamper configuration
  • The content type selected on the processor
  • Field bases of fields used on your content type
  • Field instances of your content type
  • Field permission configuration
  • Strongarm variables belonging to your content type (install the Strongarm module to make them available).
  • Eventually other exportable configuration that is related.

Don't forget to also provide a sample source file!

Check your source
It may also be worthwhile to check your source with the Feeds import preview module. This can sometimes reveal possible configuration errors.

frazac’s picture

frazac CreditAttribution: frazac commented

@megaChriz you are very kind, thanks.
I've found an error in the database import and export. Due to a different version of mysql server the mysql tables had broken. I've just reinitialized mysql following this post and now all is working:
https://dba.stackexchange.com/questions/54608/innodb-error-table-mysql-innodb-table-stats-not-found-after-upgrade-to-mys

Thanks for your help and best wishes!

MegaChriz’s picture

MegaChriz CreditAttribution: MegaChriz as a volunteer commented
Category: Bug report » Support request
Status: Active » Fixed

@frazac
Thanks for reporting back! Then this issue can be marked as fixed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.