User Profile sometimes appears empty

[cdw9]

Tested on Plone 5.1.0.1, 5.1.3-pending

Steps to Reproduce:

• As an admin, go to Site Setup > Users & Groups > Member Fields
• Add a new field, like 'Phone Number'. Set the field to display in the user profile and registration form
• Back on the Users tab, add a new user
• After the user is added, click on their name in the users listing. It may appear empty. If it does not, log in as admin in a new browser and view the profile, it will likely be empty.

Note that the data isn't actually missing, I was able to put a pdb into the user-information template and get the user's properties. Their data is safe as long as you don't click Save on the empty profile page.

The data displays again after restarting the instance, but then may disappear again after another user has been added

[lukebrannon]

Confirmed. Plone 5.1
Plone 5.1.0.1 (5110)
CMF 2.2.12
Zope 2.13.26
Python 2.7.5 (default, Jul 13 2018, 13:06:57) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]
PIL 4.3.0 (Pillow)

[lukebrannon]

I suspect the problem lies in the macro being called in the form template: <metal:b use-macro="context/@@ploneform-macros/titlelessform" /> which is from the plone.app.z3cform package. The member information is directly accessible from plone.app.users.account.AccontPanelForm.member within the account-configlet template.

[rileydog]

I am having the identical issue.

[woolyseal]

I am having the identical issue too - it seems if I restart the Instance/the client after I added a member, this isn't an issue anymore, but I can't just keep restarting everytime I add a member. Any troubleshooting found?

[rileydog]

sadly, no. I am still occasionally get the problem. I posed on community.plone (https://community.plone.org/t/is-anyone-else-having-this-issue-with-user-data-not-being-saved/7257) and had experienced programmer @lukebrannon study issue and post on community.

[woolyseal]

So, I am looking into this problem now. I printed the widget Informations in the Macro and the widget values seem to be empty. May be there is a problem with the function in the view. I'll keep you posted. By the way, I can't reproduce the problem after I restarted my client...

[rileydog]

Hi, thanks for the update. I've only had reason to update my site a few times and seems to be working. but I'm sure it's just waiting for a time when I really need to make and update. Then....

[woolyseal]

Hi. I'm not certain, but I just exported the Profiles (including member_data.xml und userschema.xml) and put them into my Theme-Profile-Folder. Afterwards i reinstalled the theme, added a new user, logged in (as the new user) and got on my "personal-information" page. This time my fields weren't empty anymore. May be this could be a solution?

[terapyon]

We have same problem on Plone 5.2 on Python 3.7. We checked Plone default site is no problem, but we got the problem when we have quick-installed our custom product.

[terapyon]

@cdw9 Did you fix this issue? or Do you have any workaround?

[cdw9]

@terapyon the only workaround I found was to restart the instance. But the data may "disappear" again after another user is added.

[terapyon]

@cdw9 Thank you for your workaround. But it is very troublesome for managing a lot of users.
However, Plone default has never happened it, I think. I think it related any customize, but I don't know what is related.

[terapyon]

@cdw9 Do you have any idea for resolved without restarting.

[cdw9]

@terapyon Sorry, I do not.

[gutow]

I am seeing this in a new install of 5.2.1 as well. This needs a fix other than restarting the instance after users are added. I am currently not in a position to trace the problem. I vote for labeling as a bug and making this a relatively high priority to solve for this module.

[ekulos]

this bug still presents in Plone 5.2.3 (5210). I tested with a new Plone without any custom modules.

I investigated this bug and after opening the @@new-user form the schema of @@user-information changes from plone.supermodel.model.member-fields to plone.app.users.browser.interfaces.IAccountPanelForm
with this schema the check on https://github.com/plone/plone.app.users/blob/master/plone/app/users/browser/account.py#L81
fails and an AttributeError(name) is raised, but is catched.

the bug is raised only in background mode

[csanahuja]

I just hit this problem aswell in Plone 5.2.5 (5213)

And after reading ekulos report all I did was commeting this line:
https://github.com/plone/plone.app.users/blob/master/plone/app/users/browser/register.py#L59

I don't know why it is required but without it the problem goes away and edition / creation keeps working as the schema it is not changed.

[tkimnguyen]

@csanahuja no test failures when you do that?

[csanahuja]

@tkimnguyen Not sure if I did something wrong but I get the same result either way (with/without change)
The 5 failures are 5 robots test not finding a control.

I did

# Added 'plone.app.robotframework' to buildout
sudo -u plone_buildout ./bin/buildout -c .src/plone.app.users/buildout.cfg
./src/plone.app.users/bin/test

The result

Total: 53 tests, 5 failures, 0 errors and 0 skipped in 1 minutes 46.500 seconds.

[csanahuja]

After a while I got an error on creation, I suspect it is because the usage of the _v_ attribute and having different clients/instances.

So I have remade the function to not use it:

def getRegisterSchema():
    schema = getFromBaseSchema(
        ICombinedRegisterSchema,
        form_name=u'On Registration'
    )
    return schema

I will report back if another error popups after this change

[csanahuja]

Sorry, I deleted my previous post as it was missleading, I hope this one is not.

So there are two functions to get the schema:

plone.app.users/plone/app/users/browser/userdatapanel.py

Line 100 in cbc6474

def getUserDataSchema():

plone.app.users/plone/app/users/browser/register.py

Line 49 in cbc6474

def getRegisterSchema():

I think they replace each other their adapters so when the schema is cached they stop replacing the adapters leading to the schema switch.

I did rewrite the two functions deleting the schema caching part

def getRegisterSchema():
    schema = getFromBaseSchema(
        ICombinedRegisterSchema,
        form_name=u'On Registration',
    )
    provideAdapter(AccountPanelSchemaAdapter, (IPloneSiteRoot,), schema)
    return schema

def getUserDataSchema():
    schema = getFromBaseSchema(
        IUserDataSchema,
        form_name=u'In User Profile',
    )
    provideAdapter(UserDataPanelAdapter, (IPloneSiteRoot,), schema)
    provideAdapter(UserDataPanelAdapter, (INavigationRoot,), schema)
    return schema

[mauritsvanrees]

I am seeing this too at a site that we migrated this week from 4.3 to 6.0, and that I talk about next week at the Plone conference. I am having a look, but this is some seriously complicated code, with too much indirection.

[woolyseal]

Hi. I'm not certain, but I just exported the Profiles (including member_data.xml und userschema.xml) and put them into my Theme-Profile-Folder. Afterwards i reinstalled the theme, added a new user, logged in (as the new user) and got on my "personal-information" page. This time my fields weren't empty anymore. May be this could be a solution?

This helped me the other day, but still don't know if it could anyone else?

[mauritsvanrees]

What I see:

• Create a Plone 6.0.0b3 site (or use buildout.coredev).
• Add a test field to the user properties in the user data schema in the UI.
• Add a user test1 for testing, fill in all fields. Fine to do this as admin.
• Restart for good measure.
• Go to the user information page, http://localhost:8080/Plone/@@user-information?userid=test1. All is fine.
• Go to the registration form, but don't fill anything in. Visiting is enough. http://localhost:8080/Plone/@@new-user
• Go back to the user information page of user test1. The fields are empty.

So what goes wrong?

• The user information page is handled by the UserDataPanel class.
• When accessing the schema, this calls the getUserDataSchema function, which calls this code:

provideAdapter(UserDataPanelAdapter, (IPloneSiteRoot,), schema)

• So the UserDataPanelAdapter is found when loading the user information page.
• When you go to the registration page, the AddUserForm is used.
• This inherits from BaseRegistrationForm in the same file.
• When accessing the schema, this calls the getRegisterSchema function, which calls this code:

provideAdapter(AccountPanelSchemaAdapter, (IPloneSiteRoot,), schema)

• Now the next time that you visit the user information page, you start on top again, getting the UserDataPanel form which calls getUserDataSchema. Same as before, so all should be well, right? Wrong.
• The first call of getUserDataSchema got the schema and stored it on a volatile attribute _v_userdata_schema (or _v_userdata_manager_schema ) on the portal.
• The next calls of getUserDataSchema see this attribute, get the schema from there, and do not call provideAdapter.
• Now z3c.form does its magic somewhere and gets a data adapter for a field, say the fullname field. And what does it find? Not the UserDataPanelAdapter, but the AccountPanelSchemaAdapter.
• And what schema does this adapter have? IAccountPanelForm, which is practically empty.
• So it user information page can show no information.

One small remark: calling provideAdapter over and over again with the same information, or only differing in the first argument, does not result in dozens of adapters being registered. They overwrite each other. I feared there might be a leak here, where the adapter registry would grow and grow, but that seems to work fine.

Let me first add this comment, before I lose it in an accident. :-)

[mauritsvanrees]

So how do we solve this mess? One way, as indicated by others above, is to completely ignore the volatile attributes: do not use this caching. But this code is called quite a lot when looking at user information, so I would rather keep this.

What I am thinking of, is this: whenever we set the volatile attribute, remove the other volatile attributes. This means when you switch between user/personal information and registration form, you need to get the schema fresh and provide the adapter. So a bit more work than now, but at least the provided adapter will match the cached schema.

But wait, are the volatile attributes per thread? I think so. So you can only remove them from the current thread, which means this idea does not completely work.

We could cache it on the request instead of the portal. Does that seem like a good idea? I can try that.