Closed (won't fix)
Project:
Node adoption
Version:
5.x-1.0
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
26 May 2007 at 16:38 UTC
Updated:
20 Oct 2013 at 21:51 UTC
Jump to comment: Most recent file
Comments
Comment #1
Leeteq commentedFits nicely into this module, I think.
Note that there is a similar feature request marked "critical" by another user from last year, here:
http://drupal.org/node/84004
If he is still waiting, is this hard to adjust for 4.7?
Many sites will run on 4.7 for long time to come. This is a very practical feature.
Comment #2
ray007 commentedI don't think it's hard to adjust for 4.7, but I won't do it since I only have 5.x sites.
Comment #3
Christefano-oldaccount commentedI'm +1 for this feature and will test this when I have a chance.
Comment #4
ray007 commentedIt probably need another line changing the owner of the last revision in the node_revisions table too. Easy to do.
I'm currently trying to find an interference with another module where changing the owner doesn't give edit-rights to the new owner, but since it's the same problem when changing the owner with the 'author' field in the edit form, it's not a problem of this code.
And another question maybe is if we'd want to create a new revision when we change owner to log the fact of owner change ...
Comment #5
Leeteq commented¤4: agreed. Practical to set a revision that logs the owner change. I think the current settings already provides this opportunity: but it should be possible to protect that revision from being removed by the new owner.
On a different site, I have used the node clone module along with the settings of the book, so that a new owner is allowed to edit the new node when it becomes "his(her) own", but leaving the original node in my name, for example, preventing any changes to that one. Then, when the new node takes over, I used the outline to move the "original" into a "history/log" book whenever that was desireable.
However, not an elegant "solution" as it breaks links etc. since each new one gets a new node id (and title). It also means "unnecessary" (since it is possible to "automate" by providing practical features and configuration options) extra work.
The revision system should ideally provide these effects automatically so that we can concentrate on quality content, not just managing and securing the quality.
Therefore, I wonder if not the node adoption feature should integrate somewhat with a module such as Revision moderation, so that we could do such a owner change from the revisions page.
Comment #6
ray007 commentednew patch using node_safe() instead of direct db-manipulation.
if somebody want to add revision adding and logging, should be easy now.
Comment #7
christefano commentedI just had a need for this today. If only I'd found this issue sooner...
Comment #8
bomarmonk commentedI am using the patch in #6 and it works wonderfully. Please include this in the port to Drupal 6. Thank you ray007!
Comment #9
bomarmonk commentedOne issue I ran into: is there any way to keep the node status from becoming "updated" when you assign a new user to the node? My lists of most recent content get distorted by the reassignment... I'll look for a solution (it might be outside the scope of this module).
Comment #11
jpcwebb commentedDoes anyone know if this patch will work natively with the v6 module?
Comment #12
bradspry commentedI think fits within the scope of this module. Organizations need robust chown operations for managing the ebb and flow of employees. I landed here in my search for options.
Comment #13
caligan commentedWhile useful, this is something the Views Bulk Operations module already implements, and feels a bit outside the scope of this one. I'm open to argument if there's significant interest, though.