Is there an easy way to change the author of a node to another user? I can't seem to find it. I found a workaround, which was to setup an "action" to change the author of a node to a specific user, and then temporarily setup a "trigger" so that whenever i update a node, it should run that action. It works, but is ugly. I suppose I could also attack the db directly, but these both seem like rather inelegant solutions.
I appreciate this shouldn't be that common an requirement. This is what happened: I setup the site, including place-holder content, which the publisher users then populated with real content. This was clearly not the right way to go about it, but it's the situation I find myself in...
Can't you simply edit the node, expand the Authoring Information section near the bottom of the page, and change the Author name.
You can also change the Authored on date too.
If you need to change the Authoring information of lots of pages, I'd recommend Views Bulk Operations. Changing the Author is one of the options.
Can't you simply edit the node, expand the Authoring Information section near the bottom of the page, and change the Author name.
It should be noted that in order to change these the administer nodes permission must be set for that account. If this is undesired (and in production environments, it is), you can use the Rules module or use the nodeapi hooks to change the desired fields.
Related
I'm pretty new to Drupal and I can't figure out how to do the following:
In Drupal 7, I have a custom content type called 'Opening' and I want users to be able to apply to an opening.
So I created another content type ('Application') and I'd like the Opening content type to have a static field of some sort (ideally a button but could live with a basic link for now) that creates a new Application content (i.e. points to mysite/node/add/application). Besides, the Application should be somehow prepopulated with the Opening it "came from" (hope this makes sense).
I thought this would be straightforward but I've been searching around and I couldn't find a way to implement this.
Any help would be greatly appreciated.
Thanks!
I would check out the workflow module.
That module seems like it has the functionality that your looking for. In that, you can create steps that users/multiple users must take to process information. In your case, you may want to make just one content type (say, Opening), and make the steps via workflow to match the cycle you need.
Additionally, if you looking to just make a form, you could use the Webform module to create the application form. You could specify that users who have filled out the form are granted permissions to use the opening content type.
Good Luck!
I have some nodes I am displaying in a view. They are displayed as nodes, unformatted. I would like the user to be able to choose from some predefined sort criteria ( via drop down list or similar).
So they could pick recently active, most commented, newest, etc., and re-query for new results.
Its easy with tables because you can make the labels clickable, but I do not know how to have similar functionality with a raw node preview display.
Just a thought, from me to me, and for anyone else who may be trying to do this.
An easy, sleezy option would be to just add another page view for each of the required sorts, and provide a link to these other views in the header of each of the pages.
This could also allow for (easier) linking to the individual sorts, so say if you have a sidebar block displaying recently commented nodes, you could adjust the .tpl.php of the block to have the title link to the view displaying the full set of recently commented nodes.
also im pretty sure there should be a way to do this with arguments, but i dont know how
Views 3 supports exposing sort order (just like you can expose filters)
Select the sort order (e.g. add sort by node creation date, then click on the settings for that), you should be able to expose the sort order to the end user. This is just like clicking on the settings for a filter and then choosing to expose it.
Standard views isn't going to support this, so IMO you're best off implementing a custom solution using just a plain old view and this jQuery plugin. You can either do this at the theme layer (the same way as any other JS in a theme) or a custom module (via drupal_add_js() to add the plugin and your bit of custom code). Either way will work, although the custom module has the obvious benefit of being theme independent (and thus more portable).
If you go the custom module route, please consider releasing it as a contrib module on http://drupal.org.
Is there any way to show local tasks to user if they doesn't have necessary permissions? Right now it seems like Drupal just excludes them from page code. I want to show them, but with different CSS class.
Version of Drupal is 5.20
Even though there are some differences concerning the local task building between Drupal 5 and 6, Mac is right that the logic to ignore entries not accessible by the current user is pretty deeply embedded in the menu.inc functions. If you want to look for yourself, start with theme_menu_local_tasks() and follow the function calls from there.
If I had to implement the feature you're looking for, I'd rather avoid Macs suggestion of messing around with the menu access settings directly. Instead, I'd override theme_menu_local_tasks() with a custom version and duplicate the entry retrieval logic in there. The first run would fetch the primary and secondary links as before, and the second would do the same while impersonating another user (probably user 1 in this case). That way, I'd get two versions of the local task markup which I'd then needed to diff somehow in order to find the ones not allowed for the current user, thus needing the extra CSS class.
Note that this would still be somewhat ugly to do, as menu_primary_local_tasks() and menu_secondary_local_tasks() return already themed lists, so the comparison would need to work on the markup, probably parsing out the li tags somehow. So it might be worth spending some time trying to do the same thing (fetching the local tasks as two different users), but using lower level functions to get the entries before theming.
Note: Should you end up using the user impersonation logic, make sure to use the safe, second version that disables session saving during impersonation.
I know the D6 version of hook_menu much better than D5's. AFAIK - however - you can't override that behaviour as it is hardcoded in menu.inc.
If I am right with what above, a workaround (rather inelegant, I must admit) could be:
Remove the access control from the menu item, so that all menu items are visible to all user.
Put access control in the callback directly (you will make the tab non-clickable in a moment, but if the user insert the URL directly, this will prevent access to pages they must not see).
In the page displaying the tabs, load a different js file according to what roles the user has. The js file for users with limited access will select tabs by mean of their text content (at least in D6 tabs do not get any "individual" class: they only get a common "tab" one), it will remove the link to the tabs the user has no permission to visit and it will add a custom class to those tabs that should be displayed differently.
Add CSS theming for your custom class.
As stated before, I do not know D5 much, so it might also turn out that you can actually achieve what you want in a much cleaner way!
I'm trying to find a simple solution to a specific problem, which is a way to allow bloggers on my site to be able to control permissions on individual posts. So they could decide whether to have their post show up for all visitors, or for authenticated users only.
The closest module solution I've found so far is the Node Access module. It comes very close, but it doesn't quite do it for me, in the sense that it creates a new "grant" tab to the content type, then displays checkboxes with too many permissions options (allow a role to view, edit and delete), where I only want to display the view option, and I need it to be located right on the content edit/create page, not in a separate tab.
Unless I can find an alternative simple solution, I'll have to add a hack to the blog module or something. I can't think of any other way to do it.
Any ideas?
If you want to avoid coding and keep things simple, there are a couple solutions that come to mind.
TAC Lite allows you to associate a vocabulary with an access control schema. Each term can be associated with different view/edit access permissions for specific users or roles of users.
In this case, you would want a single term in the configured vocabulary. Set it up so that this term ("Restricted Access") when set, limits access to authenticated users only.
The advantage of TAC_lite is the flexibility of building out your access model as new requirements show up- such as having "premium subscribers" gaining access to even more restricted content.
Content Access allows you to set access control rules by content type, and override by node. I can't speak to the UI, as I've not used this mode.
In case Graysides (good) suggestion does not fit, you could do it yourself without 'hacking' the blog module by implementing hook_nodeapi() and hook_form_alter() in a custom module:
On the hooks 'load' operation, you could add a check for the nodes current access settings concerning anonymous vs. authenticated users. You'd add a property for that to the node object (be aware of potential naming clashes - you should prefix the names of custom properties in the node object with your modules name).
Via hook_form_alter(), you'd add a form element (e.g. radio buttons) to the node edit forms for your blog nodes that allows users to select the visibility, defaulting them to the new node property from above.
On insert and update operations of hook_nodeapi(), you'd then check the new property again and adjust the nodes access settings accordingly.
Note that this approach would possibly interfere with other node access module actions, so it might need some refinement. I do not recommend it - I just wanted to suggest an alternative to 'hacking core'.
Can someone please give me a proper definition for the term?
What I know so far is that it is an input box that allows the user to enter any data to categorize something. Is that it?
Free tagging (at least how I use it) is when you expose a field that lets a user add any tag to the content node. Essentially you are allowing anyone with permission to add a custom tag to describe the content as they relate to it.
This is opposed to creating a rigid hierarchy of categories.
The most common application of free tagging is to let your users describe the content and then create "tag clouds" out of the results.