GSoC 2018 Ideas: Users as Content

IIRC, one reason that Archetypes is currently still a dependency of Products.membrane, is because Products.membrane installs its own catalog.

A catalog in Plone offers a way to search for items in the Plone database (ZODB, Zope Object DataBase) without 'waking up' all objects. The catalog has indexes, just like PostgreSQL or MySQL. The standard catalog in Plone is an object with the id 'portal_catalog'. It is used heavily in Plone for building the navigation and of course for the search form.

Products.membrane uses its own catalog, with the id 'membrane_tool'. This was originally done to avoid adding even more indexes to the already index-heavy portal_catalog.

Problem: whenever a user-as-content object gets changed, or added or deleted, all catalogs must be updated. For the portal_catalog this happens automatically. For all other catalogs, you currently need Archetypes. It has some code and configuration that allows you to say: "when an instance of this portal_type (some user-as-content type here) gets updated, Plone must inform this extra catalog as well (membrane_tool here)."

The consensus seems to be that it is better to put the extra indexes (and metadata) that Products.membrane needs, into the original portal_catalog. That would mean we can lose the dependency on Archetypes.

Yes, that is the idea.

Actually, from looking at this is no longer the case. For updating multiple catalogs, we no longer need Products.Archetypes, but can use collective.indexing, and that package has actually been merged into Plone 5.1. My memory on membrane is rusty: I am not using it in any current projects.

Yes, it is big. Or at least the Plone code is big, and you may need to get acquainted with lots of its code. Or at least a bit more familiar with several concepts used throughout Plone.

This issue seems to be the birth of the idea of merging Products.membrane and dexterity.membrane:

Products.membrane does authentication, so it helps to know how authentication in Plone works. The basis is the acl_users object in Plone, which is the central part of PAS or Products.PluggableAuthService. It is 'pluggable', which means you can write plugins to add new features. Products.membrane is such a PAS plugin.

It could be interesting for you (or others considering this GSOC project) to compare the standard user management plugin from PAS (which would also work on bare Zope) with the Plone specific user management plugin in Products.PlonePAS and the membrane user management plugin. Maybe compare a recent LDAP plugin too.

Thanks for helping me out with trying to figure out the code!

You said that:

Does this then mean that Product.membrane is independent of Archetypes? I went through the source code again, and IMHO, the only places we need to use Archetypes are for the examples or the tests. The only case in which we would need Archetypes would be if we decide to implement an AT membrane type. Did I get that right?

@mauritsvanrees It seems like Products.membrane still depends on the AT framework for implementations of the Authentication interfaces. For example in the following line:

We use the implementation of the IMembraneUserAuth interface which is written in

Which has Archetype dependencies. Is this the kind of thing we're trying to eliminate in this project?

Look a few lines above the line you are quoting:

The code says:

auth = user_ifaces.IMembraneUserAuth(member, None)

This code looks for an 'adapter' from member to IMembraneUserAuth. If member is an Archetypes object, then it will find the implementation that you reference. If member is a dexterity object, then it will either find something else (like in dexterity.membrane) or it will find nothing and you get some kind of error.

As you can see, this can get complicated and confusing, which is indeed what we want to get rid of.

'Adapters' are part of the Zope Component Architecture, which is used heavily throughout Plone. It is powerful and makes much of the flexibility and pluggability of Plone possible, including the whole PluggableAuthenticationService. Some documentation:

@mauritsvanrees In that case, I once again get the feeling that Products.Archetype is not a strict dependency of Products.membrane, only required in case we actually need to implement our content types based in Archetypes.

Also, I was wondering if I could run by you guys a rough draft of my GSoC proposal, now that I have a clear idea of the problem statement and a lot of the architecture behind membrane.
@cewing, @mauritsvanrees, @pbauer(proposed mentor for this project) where would be the best place to put up a rough draft and ask for suggestions?
I would also like to bring up that I haven't made a PR to Plone as of yet since I couldn't really find any issues that were relevant to this project. I do have open source experience in general, so I was wondering whether I should maybe take up a simple documentation issue in order to complete that formality.
Anything that you would suggest?

I'd love to see you take on an issue, and a documentation one would be very nice. I think that if you could add "improving the documentation" about how authentication and user management in Plone is handled to your project proposal that would be terrific. And taking on a simple documentation issue would be a great way to learn about how Plone's documentation is put together.

Great work so far, by the way, @vedantc98. You're really digging into this problem!

As for a good place for a rough draft of the proposal, I would say a google doc is your best choice. It works well with the GSoC interface, I believe, and you can allow us all to comment on it.

1 Like

I've made a PR For a documentation issue. It's at

I'd like to submit my initial proposal soon so that I can make whatever improvements are required and submit an acceptable proposal before the deadline.
Thank you so much for helping me with this!

That's the goal, Products.membrane should not import any code from Archetypes and (if possible) should also not know much about dexterity. But in order to not have many packages all Archetypes specific code may live in* and for dexterity in Products.membrane.dx.* using conditional imports (if needed) and conditional zcml.

1 Like

Thanks! That makes sense implementation-wise.

@cewing @pbauer The rough draft of my proposal is ready, should I upload it on the GSoC site or some other channel?

Project mentors will be notified when you upload it to GSoC site. But do notify them to check.

1 Like

@vedantc98, if you submit a draft proposal, we will see it and have a chance to work with you on it. Please do so as soon as you are ready for us to work with you.


I've uploaded the rough draft link to the GSoC site. Comments and suggestions of any kind would be really helpful!

A good first pass, @vedantc98. Please do pay attention to the questions we want you to answer that are spelled out in our organization description. What you have here is a good start on an answer for two of those questions, but there are quite a few more you need to address.

I would suggest treating the questions we ask as "headings" for an outline of what you should submit. Make sure each question has a solid answer.

I'll have some technical feedback as well, but this is a good place to start.

Hi @cewing! Iā€™m Aditya and I am a second year student and this is my first experience with GSoc . Today only I came across plone and I found it very interesting and want to contribute to it as much as possible . I want to know whether this is an appropriate time to start or it's already late enough.

I've changed my draft to integrate all the questions as headings.
Please let me know where else I could improve!

Thanks for your interest, @bhardwajaditya, and welcome to our community.

I can't say that it is too late, but it is certainly growing later with each passing day. You will want to read and work through as many of our steps to getting started on this forum post as you can in the short time remaining before the deadline for student applications (March 27).

We welcome you to Plone, and be assured that if you are unable to get an application done in time for this year's GSoC, there is always next year.

@vedantc98, That's much better. I'll continue working with you in the doc itself. Look for some technical feedback this weekend.

1 Like

@jensens would it be a good idea to implement an entirely new module (called collectives.membrane) or would we be better off just absorbing dexterity.membrane into Products.membrane?

And would Archetypes support depend on this? @datakurre has suggested that if we implement a new module, we will no longer need to have AT support..

Plone Foundation Code of Conduct