Needs to be adapted to changes in CMFCore

[pbauer]

In Products.CMFCore the MemberDataTool is now a utility and has some changes that we need to adapt to in order to use Zope 4 (plone/Products.CMFPlone#1351): In zopefoundation/Products.CMFCore@a876001 the functionality of MemberData was moved to a new MemberAdapter.

For more changes see https://github.com/zopefoundation/Products.CMFCore/blob/master/CHANGES.txt

[pbauer]

@jensens @dataflake @mauritsvanrees @esteele you have been working on Products.PlonePAS and Products.PluggableAuthService recently. Since I've never worked on this part of our stack I want to ask for your help to get this issue resolved.
Most errors in http://jenkins.plone.org/view/PLIPs/job/plip-zope4/50/consoleText are like this one:

Error in test test_get_groups_users (plone.api.tests.test_user.TestPloneApiUser)
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.13_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 329, in run
    testMethod()
  File "/Users/pbauer/workspace/coredev/src/plone.api/src/plone/api/tests/test_user.py", line 214, in test_get_groups_users
    password='secret',
  File "/Users/pbauer/workspace/coredev/src/plone.api/src/plone/api/user.py", line 91, in create
    properties=properties,
  File "/Users/pbauer/workspace/coredev/src/Products.CMFCore/Products/CMFCore/RegistrationTool.py", line 162, in addMember
    mtool.addMember(id, password, roles, domains, properties)
  File "/Users/pbauer/workspace/coredev/src/Products.PlonePAS/src/Products/PlonePAS/tools/membership.py", line 167, in addMember
    member.setMemberProperties(properties)
AttributeError: setMemberProperties

If you could guve me guidance on what I'd have to do or even better provide a pull-request you would help a lot! I'm willing to put in some more time to fix some of the remaining issues in plone/Products.CMFPlone#1351 but this currently blocks me.

[esteele]

@pbauer It looks like this MemberAdapter was added and has the method you're after: https://github.com/zopefoundation/Products.CMFCore/blob/master/Products/CMFCore/MemberDataTool.py#L224. Is the member referenced in PlonePAS using that?

[esteele]

This is the relevant changelog entry, I think. https://github.com/zopefoundation/Products.CMFCore/blob/9e8c000416bb6742c2c826cfb9755479dd83d189/CHANGES.txt#L132

[pbauer]

We have to fix the testfailures. The tests did not run because of a error during teardown and we missed that. Now they do and are pretty broken. See http://jenkins.plone.org/job/plone-5.2-python-2.7/

[mauritsvanrees]

I did a few fixes. On PlonePAS tests we are down from 1 failure and 21 errors to 7 failures and 1 error.

The remaining problem seems to be that we expect this acquisition chain:

member data > plone user > acl_users

and instead we get:

member data > acl_users

@davisagli You did some changes to the wrapping here recently. Do you know what is going on?

[mauritsvanrees]

@davisagli When I revert your commit a80db7d, we are down to one failure in test_user_properties, where adding a property to the memberdata tool does not result in an existing member getting this property.

Well, worth a shot. I will commit the revert, and we can see from there.

[mauritsvanrees]

Okay, I reverted my revert. It fixes most PlonePAS errors, but causes lots of failures in other packages, like plone.app.contentmenu and plone.app.dexterity. See http://jenkins.plone.org/job/plone-5.2-python-2.7/69/ (currently still running).

Let me have dinner first. :-)

[davisagli]

What are we missing because of not having the user in the acquisition chain? In the case of getUserId I just copied the implementation to MemberData (my rationale is that reducing the use of crazy acquisition chains is a worthy goal). Maybe we can do something similar for the new failures? (I haven't actually looked at them yet, will try to do that soon.)

[mauritsvanrees]

I must say, I didn't realise until today that the PloneUser is the acquisition parent of the MemberData, so I wouldn't miss this if we get rid of it.
It looks like the goal of the failing PlonePas tests is simply to check the acquisition chain. So we could change the tests to fit the new situation. It does not look like the other failing tests have anything to do with this.

[mauritsvanrees]

I have changed the PlonePAS tests to match the new situation, and have added MemberData.hasProperty. That fixes the PlonePAS tests.

[davisagli]

That seems appropriate to me -- the big change in CMFCore that we are responding to was to turn member data into an adapter rather than a persistent, acquired object itself.