This project is read-only.

AnonymOwnerPart for anonymous user submissions (like comments)?

Topics: Core, General
Jul 1, 2012 at 9:30 PM
Edited Jul 14, 2012 at 8:23 PM

My idea is the following: have a general-purpose AnonymOwnerPart that can be attached to any type one wants to permit "outer" users and anonymous users to edit/create (typical scenario is comments). This would have the following functionality:

  • Be active only when the user is not logged in
  • Store a name and e-mail address
  • Logic to check if the name corresponds to an already registered user; if yes, send back a validation error
  • Ability to set per content type whether the e-mail should be optional or not

This is basically all coded in Comments, but I think could be useful in other modules too. That's why I think it should be in a separate module for general re-usability, then other modules like Comments could depend on it.

I've opened an issue for this here.

What do you think?

Jul 1, 2012 at 9:43 PM
Edited Jul 1, 2012 at 9:43 PM

It sounds interesting. Are there more benefits to this than: The anonymous user only has to enter his name, email and url once during his session; his next comments would be linked to this one anonynous user record?


Jul 1, 2012 at 11:36 PM

I wouldn't store the website of the user in this part frankly: it's nice to have in comments, but I don't think it'd needed generally everywhere where anonymous submissions. Yeah, the data entered could be persisted, good idea! Though I'd go with a cookie here and store user data (name and e-mail) denormalized, per item.

Jul 2, 2012 at 1:44 AM

How is that different from what Sébastien has done in CustomForms and Orchard 1.5 item permissions?

Jul 2, 2012 at 6:24 PM

Frankly I can't name anything they have in common :-).

What I'm outlining here is a part that contains the anonymous user data storing and validation (i.e. check if the username is that of a registered user) logic that currently is in Comments, and make it generally usable. This wouldn't deal with permissions at all (well, apart from that it would only appear if the user is not authenticated, but that would be just a simple authentication check).

I don't fully know what's now in Custom Forms, but I don't know of any work on such user-checking logic. Or is there anything? If not, this part could be used when building forms from the admin UI too, if appropriate.

Jul 4, 2012 at 4:52 AM

mmm, ok, well if they don't have anything in common, I suppose that's a good thing.

Jul 28, 2012 at 1:10 PM
Edited Jul 28, 2012 at 1:17 PM

Let's see a scenario when someone registers to the site with a name that is already used by an anonym user. In this case, the module that controls the AnonymOwnerPart should hook into the registration process and go through AnonymUserRecord and change the conflicting name (eg. appending something after the name until it founds a name that is not taken by either anonym or registrated users). This would maintain consistency among anonym and registrated users.

Jul 28, 2012 at 1:22 PM

A slightly different approach:

  1. When a user registers, check if there is an AnonymOwner with the same name.
  2. If there is one, change all AnonymOwner records that have this name to [name] Guest.

This would make it possible though to as a guest to create items with the name e.g. "Jon Guest", then registering with the name "Jon Guest" what in turn would turn all anonym "Jon Guest" submissions to "Jon Guest Guest" :-).

Another possibility: all anonym submissions would have some text clarifying that the submitter is not registered, e.g. displaying the text "Guest" along with the name in an undisturbing manner. So there could be anonym submissions by "Jon". Later someone registers with the name "Jon", what would prevent further anonym submissions with the same name. Now there could be submissions along each other by the guest and by the registered Jon - what could cause confusion, but the "Guest" text would be there to mitigate it.