Hi,
I've a case where Protected Node is configured and working great - however at periodic intervals I need to add hundreds of new (protected) nodes programatically using Feeds, from a spreadsheet where data for each field exists in a column. However as Protected Node doesn't present as a typical field there's no default way to map a 'password' column to it (each node being imported already has a password associated with it generated outside of Drupal) so I can't mass import any password data.
I'd like to request a patch to implement a basic feed mapper to allow Protected Node passwords to be imported (documentation here). If you think this is too much of an edge case, I'll try get through a patch myself.
Comments
Comment #1
khalor commentedComment #2
izus commentedactually the protected node has its own database table where the passwords are stored after beeing encrypted.
so the node protection information is separate from node itself.
i'm afraid the initial structure of protected node doesn't allow to have this easily, but i didn't digg into it. Please feel free to do it custom or suggest a patch if you found a clean way for this.
another suggestion would be to do this after nodes creation by having a UI with checkboxes that process bulk node protection for checked nodes and using batch API for it...
Comment #3
khalor commentedI'm now thinking a Rules approach paired with a regular text field might work - after content is saved it could grab the value from the text field and use that value to populate the 'Password protect node' action. Then after the import the (unencrypted) text field could be deleted from the content type for security. Will keep this issue updated as to whether this works as a solution...
Comment #4
khalor commentedSeems to work using the 'Before saving content' event/trigger! Feeds supplies a 'Before saving content imported via ...' trigger so I'd say this should scale up nicely to batch imports.
If you never wanted to store the password in the clear you could use Password field to at least encrypt the ingested password before it's applied to Protected node, but if you remove the field directly after import it shouldn't pose much of a risk anyway.