[development] Multiple user aliases - Multiple user node ownership

[ekes]

I've been quite heartened that in this case it's not just me being in a
marginal group. There certainly are a couple of layers to the
discussion. I'm putting everything into one mail, a reply to the longer
term, bigger picture, first. Then the immediate work-round after.

Michael Prasuhn wrote in reference to the ORM article
(http://groups.drupal.org/node/8001)
> I think that's probably the solution to more Drupal problems than we
>  realize. Once Author and all node fields are stored as multiple
> value CCK fields, multiple authors becomes trivial.

and Karen Stevenson wrote:
> Actually, we really do need a core solution for this because of the 
> fact that users are tied to nodes in so many ways other than what 
> they display to the end user.
---%<---
> I do think this may be an example of what CCK in core might do in D7 
> -- the node author becomes a multiple value userreference field 
> instead of a single value field.

and possibly alternatively Earnie Boyd wrote:
> I would suggest a more drastic change to core functionality and add a
>  node_uid table with column of nid, vid and uid.

I think it's pretty much common here to go for an
object/reference/node_uid that is the 'node author'. I'm not sure how
this then fits with revisions - in a technical sense of the references
or objects (but also see my note below).

FWIW I'll mention here that one of the things that occurred to me while
working idea (further below) was the problem of clashes between
'registered username' and identified 'registered node owner' username.

Generally if there is some way to move towards an abstracted object
owning the node that's brilliant! I suppose I can help somehow?

Karen Stevenson also wrote:
> Also, for whatever it's worth, whether you need this at all depends 
> on your environment.
--%<--
> But when you start talking about books or when you're publishing 
> material in the business or academic world, 'authorship' and 
> 'ownership' of nodes needs to be more flexible.

This is the revisions thing. For most of the groups I work with
(activist, NGO...) there is also an (admittedly small, but inverse to
above) element of deniability that can be worked in here, so for me the
revisions would also want to be 'owned' by the 'node author'. Tracking
individual users is nice, but for these purposes it helps when it's
optional.

On a more immediate solutions Scott Reynolds wrote:
> My approach did not involve just the node_access table, it used the
> og table  (to determine if the user is an admin of the group). Just
> get rid of the og stuff and put in your node_uid table
> 
> So revised using node_uid table like as follows
> 
> hook__node_access_records()
...

I had also thought about this relating to OG and being able to have
actual group posts.

The workaround (suggested in the original e-mail) I wanted to avoid
using hook_node_access... Not touching the node_acccess table is
interesting, but I was looking not to get involved in moderating access
between modules at all.

Given the interest I'm still wondering if there is anything about my
solution, or I should say workaround (above are solutions), is good. I'm
guessing it's not going to run-aground so I'll give it a go!

Cheers,

ekes

Original suggested answer^H^H^H^H^H^H^H workaround:
> Write module that - (i) Creates a (blocked) user to
> register 'nicks' (ii) Links 'nicks' with user(s) 1->1 or 1->many (iii)
> uses nodeapi to add 'nick' to node form (iv) adds edit/delete to nodes
> that relate to user 'nick's (just skipping and adding different access
> control to present node functions).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.drupal.org/pipermail/development/attachments/20080115/80641089/attachment.pgp