Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I'm trying out this module but the export json file for users doesn't have email addresses. What am I missing? Thanks.
{
"_links": {
"self": {
"href": "http:\/\/default\/user\/2?_format=hal_json"
},
"type": {
"href": "http:\/\/drupal.org\/rest\/type\/user\/user"
}
},
"uuid": [
{
"value": "c51ca112-5598-4e15-8808-8d9d973abf8c"
}
],
"langcode": [
{
"value": "en",
"lang": "en"
}
],
"name": [
{
"value": "user2"
}
],
"created": [
{
"value": "1448898158"
}
],
"changed": [
{
"value": "1448898158",
"lang": "en"
}
],
"default_langcode": [
{
"value": "1",
"lang": "en"
}
]
}
Comment | File | Size | Author |
---|---|---|---|
#23 | run_drush_export-2625846-23.patch | 2.55 KB | andypost |
| |||
#23 | interdiff.txt | 1.66 KB | andypost |
#22 | default_content-run_as_uid_option_FIXED-2625846.patch | 2.58 KB | AaronBauman |
|
Comments
Comment #2
larowlanEmail is a protected field in core.
If its not being exported then either you don't have permission to see it, or core doesn't export it either - would be my guess
Comment #3
dakala@larowlan: Thanks but when logged in as user 1, I can see everything. An export of users without the email field means they can't be imported to another site later.
The entity is loaded correctly and yes mail is protected, as well as the other fields that have been correctly exported. The problem comes after the serialization and not being able to have emails in the output is a major issue IMO.
Comment #4
larowlanCan you enable the user rest endpoint or create a views rest export of users and see if mail shows there.
I suspect it won't.
Comment #5
dakalaThis is the output of a views rest export of the user.
Comment #6
Saphyel CreditAttribution: Saphyel commentedI confirm this is still happening.
Comment #7
mlncn CreditAttribution: mlncn at Agaric for MASS Design Group commentedSorry i missed this issue and technically posted a duplicate but i think the fix will likely progress in #2699469: User entity exported without status, roles.
Comment #8
dakala@mlncn: Thanks for moving this forward. I couldn't follow this up to see where the problem was.
Comment #9
larowlanThe issue is the drush command.
It needs to call the account switcher service and switch to user 1 before exporting, then switch back afterwards.
Field permissions prevent those fields form being exported.
Comment #10
larowlanMore info in #2625846: Run drush export commands as customized user
Comment #11
codium CreditAttribution: codium as a volunteer commentedI've tried to export content by:
drush --user=1 dcer node 13 --folder=my_path
but still no email & status values in exported json.
Comment #12
AaronBaumanfeature request or bug report?
Comment #13
larowlanPlease import the class instead of using the FQCN. Thanks
I call it a feature request. I didn't really expect anyone to use this to import users.
Comment #14
andypostLooking at patch I think better to refactor switching code into separate function for clarity and to allow drush option for it later
Comment #15
AaronBaumanComment #16
AaronBaumanOK, refactored, and uses a "run_as" argument to enable user switching.
See how you like this one.
Comment #17
AaronBaumanComment #18
andypostLooks great!
Comment #19
larowlan+1
Comment #21
andypostComment #22
AaronBaumanSorry, I guess this slipped past all of us.
"run_as" is defined as an argument in default_content_drush_command(), but is actually implemented as an option.
Attached patch fixes definition in default_content_drush_command()
Also, since it's changing anway, switches from "run_as" with underscore to "run-as" with hyphen instead.
Comment #23
andypostIMO option supposes "optional", just wording changes, please review
Comment #24
larowlan+1
Comment #26
andypostComment #28
ao2 CreditAttribution: ao2 as a volunteer commentedHi,
the
run-as
option is working fine, but isn't it equivalent to using the drush--user
option?I tried a command similar to the one in #11 and the email address get exported fine with:
drush --user=1 default-content-export-references user --folder=$PWD/content_as_user_1
and it gives the same output of:
drush default-content-export-references user --run-as=1 --folder=$PWD/content_run_as_user_1
So maybe the
run-as
option is not strictly necessary, or am I missing something?Also, would you consider a patch to run import/export as user 1 by default?
Thanks,
Antonio
Comment #29
andypostGood points, needs follow-up issue!
Comment #30
smazAdded a follow-up issue.