GSoC 2018 Ideas: Users as Content

Plone Support Customizing Plone
, ,
1

This is one post in a series to begin focused discussion about ideas that came out of our 2018 GSoC Brainstorm.

Please use this post as a place to begin to discuss this idea more in depth.

This idea was suggested by @cbc, who has suggested @cewing as a mentor.

The description:

"Plone users need to be a content type so that they can undergo workflow. Currently, users either self-register and then are fully a member, or an admin or other designated role adds them. What is needed are users who self-register and then go through an approval or other workflow before becoming a member. Users also could then be put in other states (like suspended, or moderated, etc). Users are the most basic of content to a CMS. They should be treated as content. (Remember Python 1.x when the basic data types were not actual Python types but something more analogous to Java "primitives?" I feel that the current situation in Plone with users is similarly primitive and inflexible.)"

Go on folks, work this one through.

2 Likes
2

I like this concept. It would allow a site administrator or other role increased flexibility to manage new registrants in specific ways.

3

There's https://pypi.python.org/pypi/dexterity.membrane/2.0 for that, but still room for improvement

4

We solved this in a reasonably flexible way by creating this plugin - https://github.com/collective/collective.pfg.signup.

It works with PFG and allows approval workflows with different people approving different groups. No content types were abused in process of creating this plugin. Membrane is really a bad idea. Content is content. Users are users. DB's are DBs. Overusing reuse is a bad idea.

5

Having lived off of Faculty/Staff Directory for years @djay I have to strongly disagree that membrane is a bad idea. However, I can get behind the concept of solving a smaller class of problems in a smaller way.

1 Like
6

We have users as content object in our e-procurement system for 2 years...not very much coupled with the existing plone user management...works for everyone like a charm.

-aj

7

@zopyx, could the code you refer to here be a basis for this project? A reference? Would you be interested in having a GSoC student extend or polish it up and put it in the collective (if it isn't already there)?

8

I do not get the point here. We have a working addon here since years: membrane and its ecosystem.

Lets go through it, step by step:

Plone users need to be a content type so that they can undergo workflow.

membrane feature

Currently, users either self-register and then are fully a member, or an admin or other designated role adds them. What is needed are users who self-register and then go through an approval or other workflow before becoming a member.

membrane feature

Users also could then be put in other states (like suspended, or moderated, etc).

membrane has enabled and disabled. With custom workflows all other funny states are possible.

Users are the most basic of content to a CMS. They should be treated as content.

I disagree. This is one way to deal with users. It is a rare use case in our customer projects (in only about 10% of the projects). Users are coming in from different sources, LDAP, SAML2, OAuth2, ...

(Remember Python 1.x when the basic data types were not actual Python types but something more analogous to Java “primitives?” I feel that the current situation in Plone with users is similarly primitive and inflexible.)”

This analogy is so wrong. Also, the PlugableAuthenticationService (PAS) is very pluggable, extremly flexible (as the name suggests) and the opposite of primitive. I wrote a bunch of PAS-Plugins and its easy to plugin anything. And if you want to have contentish users, plug in membrane.

Membrane and a bunch of other addons are providing us with a bunch of OOTB possibilities one can use in their site.
I strongly oppose to make a contentish user part of Plone core. Its just one use-case.

Conclusion:

The proposal does not make any sense to me. I would moreover propose to take membrane and make it a first class addon for Plone. The current state is - as Peter wrote - still room for improvement

Tasks - off head:

  1. We have Products.membrane and dexterity.membrane. This could be merged.
  2. Archetypes need to be ripped out as an optional feature.
  3. Then membrane has its own catalog. Thats questionable if this makes sense. At time of writing people thought its a good idea to not pollute the main catalog. I doubt that this is an advantage.
  4. The whole codebase is evolutionary grown and could need some refactoring.
  5. With dexterity we could think about a consistent TTW story - though now TTW users are is already possible afaik.
1 Like
9

There is not much to share. We have a "Customer" content-types (Dexterity). It hold the common metadata that you would usually attach as properties to the member object. A customer instance is owned by the related customer and there is an association between the the Plone user ID and a userid field in the customer ID. We don't care much in this project about the registration process since most accounts are coming from LDAP. We use collective.onlogin to send a new user to the add-form of its own Customer entry...and that's it basically. We have registration states new|active|inactive which is just a field on the content-types. The user management for the administrator is based on DataTables.net and it's editor component. There is no further deep integration with the Plone functionality. Inside the applications we are able to get hold of the "customer" object for the currently logged in user and retrieve its member data from there instead ask the properties of the member object. I don't claim that this is a full-fledged and deep-integrated solution but it fits perfectly our usecase(s) - in particular because it is light and not invasive. Membrane would be completely over the top.

-aj

10

@jensens, i tend to agree with you that the existing membrane functionality is our user-as-content story, at least for the most involved use-cases. I think your enumeration of issues with membrane is a solid grounding for a GSoC project that involves fixing those issues and polishing membrane for a Plone 5 world. How much use of membrane is there out there? I know that I used it a couple of times myself for various projects, but are there other users out there interested in collaborating on a GSoC project description?

@djay, it seems like your PFG-based solution is a very nice add-on for simplifying user management when users are not content-ish. Do you think that your add-on requires any creative code work to improve or perfect it? Would that work be enough to constitute a full-on project?

If the work for either of these does not make up a full three-month project, is there a meta-project here that might include fixes for both existing packages and work on documentation of the user management options available in Plone?

11

On a related note, if there isn't already there should be some sort of out-of-the-box implementation of a user using membrane that can serve as a plug-and-go add-on. I can't remember if such a thing already exists.

12

Not really. One thing that would be useful is a decoupled staff directory that doesn't make the users content. ie the idea of a profile database is linked by userid but not the same as the actual user. So you can do things like delete users but still have them as an archive in the directory, or have multiple directories in different parts of the site or allowing bulk upload without requiring the creation of actual users.

13

This is the kind of setup that I think is more flexible and wouldn't classify as users as content. You are just storing a decoupled profile as content. You could equally use something like Plomino to store the user profiles or even replace one with the other without dealing with things like users being deleted.

Users as content == membrane. One content object = one user. Delete the content object you delete the user. Deep integration. I

14

@cewing besides the behaviors dexterity.membrane.behavior.user.IMembraneUser and dexterity.membrane.behavior.password.IProvidePasswords that allow any dx contenttype to act as a member object, dexterity.membrane also has profile that one can load to have membrane example types installed.

15

I thought that might be the case. thanks @agitator!

So @jensens, what do you think? Is the work needed on the membrane code enough to warrant a GSoC project? Could we combine it with docs on user management options? Might also include writeups on how to use LDAP or SAML2 correctly.

16

Tangent, but I'd like to emphasize what's implied in some of the above, namely that having users as content would be helpful in cases where sites (like our http://isaw.nyu.edu on which @cewing has worked in the past) want to have robust, public-facing staff profiles that are tightly tied to (e.g.) news item authorship, member folders, and the like. Hence my +1.

17

This is more like a decoupled profile. The implementation hold a bunch of customer-related logic that is necessary and encapsulated in one place. Instead of fiddling around with the normal Plone/Zope user objects, all our application code uses this customer object. And no, I don't want any more deep integrations of something. Deep integrations break your neck with the next update or a major version change. I am a big fanboy of loosely coupled components - perhaps not always that elegant from the programmers prospective but in general more robust and stable.

-aj

1 Like
18

This would be a code cleanup/refactoring and documentation task.
So, I think yes.

Could we combine it with docs on user management options? Might also include writeups on how to use LDAP or SAML2 correctly.

Yes, that would make sense. I think @fredvd already did great work on the LDAP/AD side. For SAML2 I can not say much about the existing addons, since I only wrote some customer specific solution.

19

@jensens would you be interested in making a more complete writeup of what this cleanup/refactoring/documentation task would be? See the import/export project proposal from last year for an example format. I very much like this idea, and would love to add it to this year's ideas posting.

20

I am ignorant of the technical details, but I wonder if it would make sense to add to this project (if it's too small as is) a new FSD version that piggybacks on this work - that is, uses Dexterity instead of Archetypes content types and maybe other improvements. Thus future-proofing FSD. This would logically include code to upgrade/migrate an existing Plone 5 FSD implementation to the new thing. Could be a nice proof of concept for using the new stuff.

FWIW Previous FSD replacement idea: https://blog.jazkarta.com/2015/04/07/replacing-faculty-staff-directory/