Is there a way to reassign all nodes associated with a user to another user when the first one is deleted instead of it going to anonymous?
To ask another way, I when I go to delete johnsmith, I am looking for the option to reassign all of johnsmith's content to janesmith.
I know this functionality exists within WordPress.
I do not know of any way to do this without coding.
In code I would look at
https://api.drupal.org/api/drupal/modules%21user%21user.api.php/function/hook_user_cancel_methods_alter/7.x
to define and add a new method when cancelling a user. And
https://api.drupal.org/api/drupal/modules%21user%21user.api.php/function/hook_user_cancel/7.x
to act on the new method.
Related
I've created an action programmatically and added a VBO to a view in order to execute the action on one or more users. The action itself simply removes a few roles and adds a new role to the selected users. I call user_save from within the action to save the changes to the roles.
If I look at the user_roles table in the database while the action is running, I can see the role ids for the specific user, changing to the new role in realtime. However, when the VBO is complete, it seems to revert back to the original user object so that none of the old roles have been removed and the new role hasn't been added. It has to be something happening after my action is executed, but I can't imagine what it is.
Oddly enough, if I run the VBO a second time, it seems to work.
My action is defined in hook_action_info as type "user" and triggers is an array with "any" as the only parameter.
If I call the action directly using actions_do, it works perfectly the first time.
Any ideas?
I suggest to use a few users to test the VBO and also implement hook_user_update with dpm (devel module) and debug_backtrace. This could give a hint of what is happening, it's a weird behaviour that you will discover only debugging.
If you have more info please append it to your question so everyone could help.
Hope that helps.
Every time a user visits a specific route, I'd like for a new document to get created that will act as a "draft" that the user will edit until they decide to publish it.
Another way to think about this is that I want to redirect a user to a new page displaying the document after a successful insert of the document.
When I phrase it like that, I think I've basically answered my own question. In this case I would just call a Meteor method that creates and inserts the new document, then in the callback method I would use iron-router's Router.go method to redirect to the url using the new _id as a parameter. Is there a better way?
It's a bad idea to get collection created automatically upon visiting a route. What happen if user visit the route unintentionally?
Nevertheless, you can achieve it by inserting a document on publish function and it will get created upon Meteor.subscribe.
Meteor.publish('test-draft', function(options){
var _id = Test.insert({a: 'b'});
return Test.find({_id: _id})
})
If I understand what you're doing correctly, I think the easiest thing would be to just create an object and put it in a Session variable and not mess with creating a document in a collection until you're done editing it.
You can create the object and stick it into Session in Templates.myTemplate.rendered = function() { ... }. And then when it's been satisfactorily edited and submitted pass the Session variable to a Method that inserts it as a new document.
I have a node type that should only be edited by users under certain circumstances that go beyond the permissions their role has. I am doing this in a custom module.
I would like to remove the ability to even see the edit tab, and not just add a validation function to the form that will alert the user after the form is submitted.
I need to add some sort of access function. Anyone know how to do this?
Thanks in advance.
--Update--
I now have 2 ways that should work.
1) Using hook_nodeapi:
function mymodule_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
switch($op) {
case 'prepare':
if(!mymodule_access_function($node)) {
$_REQUEST['destination'] = 'my_access_denied_page';
// rest of function
2) I can insert a access callback function into the menu item using hook_menu_alter.
For my purposes, 2 makes more sense. I thought I would spell out the code for (1) though since that was the answer given on this page and it works.
For the tabs visibility you can alter the themed output anywhere from a module hook to a theme template or css patch. Depending on the requirements for data visibility and performance issues some solutions are better than others. We need more details on what kind of processing you need.
For access, hook_nodeapi(), $op is 'prepare', run your custom code against $node at this point, and decide what you want to do (like redirect to another form if a requirement is not present, or to an access denied page).
Edit: Redirecting is usually done with $_REQUEST['destination'] = 'destination/alias' (does not break execution), sometimes drupal_goto('destination/alias') (breaks execution) is suitable but often it doesn't work. Please keep redirects tracked on your project, as with multiple logic conditions you may end up with unwanted and hard to debug behavior.
Every content type has default permission settings in admin/user/permissions for creating,editing ,deleting node . You may assign to anonymous or authenticated users. If you want assign to group then create another role and assign permission as mentioned above.
I have the following scenario:
Editor Role should not be allowed to
delete nodes. Therefore the corresponding
permission is de-selected in the
permissions page.
However Editor
should be able to to delete nodes
from Views Bulk operations. Using
Rules an action is created called
"safe delete" that checks things like
if the node is not published etc.
before deleting the node.
The problem is the Views Bulk Operations respects Node permissions. Editor will not be able to delete the node as he has not been given that permission. Is there a way that Editor can become a higher role user (as sort of sudo) while performing that action in VBO? Alternatively is there a way to tell VBO to ignore node access for this action?
I'm sure this is a mainstream requirement but I can't seem to find a solution.
Solutions which do not involve programming will be preferred.
The simple, but not-so-clean way, is the route you already took, but with an additional, small module to help it.
has a function my_module_can_delete($user), that returns TRUE if the user is allowed to delete, FALSE if the user is not.
implements hook_form_alter() to modify and delete the button on the node_edit form, if my_module_can_delete($user)
implements hook_form_alter() to modify the confirm form that is called on /node/%nid/delete, and add a message there, telling the user he or she my_module_can_delete($user). This should be enough, since disabling this form will result in users not being able to get past this form. FORM-API will take care of that.
However, you can make it more sturdy, to catch other deleting modules:
implements hook_nodeapi(), $op == 'delete' to catch delete actions and halt (by invoking drupal_goto(), or calling drupal_access_denied() to enforce a user-error. Only catch delete-actions if the referer was the delete-confirm-form as mentioned above. Or, more secure, whitelist your VBO-action and return false on all other referers. A referer can often be found by reading out the $node passed along to hook_nodeapi().
A, IMHO, much cleaner, but probably more intensive alternative, would be to simply make sure your batches/actions are called on every delete action.
In a module, you could do this by avoiding all the VBO-configuration and leaving all the extra-delete actions out of there.
Then write a module that implements hook_nodeapi() and then calls all the cleaning actions from there. That way you can be sure that your delete-actions are called on every delete-action on any node. Obviously you can add some conditions into your hook_nodeapi() to only invoke your modules in certain cases (node-types, user-roles, permissions and so on).
Well, it seems to me that you've got a setup where you don't want Editor Role users to delete things, really, except in certain extreme situations. Here's my suggestion:
1) Install Flag module. Create a 'To Be Deleted' flag that can only be assigned by Editor Role people.
2) I haven't looked into it, but I"m sure there's probably a rule or trigger/action combo which will unpublish the node when the 'To Be Deleted' flag is assigned to it. This will remove the node from casual view.
3) Then either set up some cron run activity (trigger/action or rule) to delete nodes with 'To Be Deleted' flag set on them, or have another user with higher permissions come in occasionally and delete out the flagged items.
This way you're not actually bypassing the permissions system, and yet things are still being removed from your site.
I got caught out of this for a while until I noticed the "actions_permissions" module, enable this and on the Permissions page you can provide access to specific actions on a role by role basis.
I don't have a good no-coding solution, and I'm not sure I would call this solution "great" - but one way might be to implement a simple module with a form_alter hook that removes the delete button from the node edit forms as they are built.
In general it seems like the role either has permission to delete nodes or not, and monkeying around like this is going to be less robust that you might like.
I'm building a Drupal based site that requires the communication of a node ID to a seperate web service. This web service handles the uploading of files to a seperate server (from the one Drupal is on).
This creates a problem where in if I create a new node, the Node ID is not generated until the form is submitted - meaning I can't attach the files until I save the node and open it back up to edit it. I'd like to remove that step.
Is it possible to create a two step node creation process where the basics of the node are submitted and saved, and then the form re-directs to step two where I can attach the files?
I'd also consider an AJAX enabled node submission form - but that seems to add even more complexity to the situation.
Any advice, examples will be appreciated!
you could do this with a multi-step form. see http://pingv.com/blog/ben-jeavons/2009/multi-step-forms-drupal-6-using-variable-functions for the canonical way to do this (besides the code, also check the comments).
you could also do it by adding a second submit handler to the form. the first, default one (node_form_submit) saves your node (including the attached file) the standard Drupal way. the second handler could upload the file to the separate server, do upload error checking, delete the file from the Drupal DB, etc. you can add an additional submit handler to a Drupal 6 form by adding it to the form's #submit property, either in the form definition or via hook_form_alter / hook_form_FORM_ID_alter.
Depending on what exactly you want to do, you might use hook_nodeapi on its 'insert' operation. It is fired after successful node creation, so the node object will contain the newly assigned nid there already.
NOTE: The wording of the API documentation is a bit ambiguous concerning the 'insert' and 'update' operations:
"insert": The node is being created
(inserted in the database).
This sounds like it is right in the middle of the process, whereas the node has already been created at this point.
I guess the node_save function can help you.
I ran into exactly this same issue and did it the wrong way. I added the hook myself.
http://drupal.org/node/313389