By andyf on

Hi all,

This is my first post here. I'm a noobie to web development and Drupal (couple of weeks), and come from a software engineering background. I'm helping out a local company (called JIPL) by seeing if their desired web presence could be made entirely using Drupal. Basically the site should allow categorised articles, comments, job adverts and a database of users with their academic qualifications, work experience etc. Things are looking good so far!

I want to make sensible use of roles, and I've now come up against a problem. When creating a new job advert, you have to select the name of the recruiting company from a dropdown list (this is implemented using CCK). Obviously I need someone at JIPL to be able to add new companies to the list of allowed values, but by no means do I want to grant all JIPL staff full administer content type permissions. I've looked at CCK Field Permissions, but this is about viewing/editing individual fields/fieldgroups, not about altering the content type itself. Currently I'm using Workflow and Workflow access to implement a simple draft -> published -> withdrawn workflow and that is working great, so I don't want anything that would interfere with that.

Any suggestions?

Here's what currently comes to mind:

  • Use some PHP code (means learning PHP!) to read in the allowed lists from a node, and then specify which role is allowed to edit that node. Seems a bit icky to me! Especially multiplied by a large number of dropdown lists...
  • Give administer content type access to a role, try to hide the Content types navigation menu item (is that possible) and then make a menu item that points directly to the particular field configuation page you're interested in, eg. admin/content/types/job-posting/fields/field_company. I don't know how to hide the normal menu item, but otherwise this would work well for the end users (ie staff). The problem is, however, that they still have more permissions than they should, so they could still manually enter admin/content/types and play about with all and sunder! The staff are all 'trusted' however, so the roles are more there to protect people from accidentally screwing things up, so maybe this is the route to go?

Would love to hear what people think.

Ta,

Andy

⋅ Categories: Drupal 5.x

Comments

mooffie’s picture

mooffie commented

CCK Taxonomy may suit you. It takes its list from a vocabulary. However, if you're looking for some adventure and fun, keep reading.

Here's what currently comes to mind:
- Use some PHP code (means learning PHP!) [...]
- Give administer content type access to a role, try to [...] and then make [...] hide the [...]

It's ironic that if your take the second solution, the "PHP free" one, you'll end up writing much more PHP code than in your first solution.

- Use some PHP code (means learning PHP!) [...]

Let's pick this solution. The plan is simple: create some node and type your list in its body. You should give trusted users 'edit' rights to this node. Whenever they want to update this list, they edit this node's body. let's say the NID of this node is 189561. All that's left is to write some code, for the 'PHP code' box under the 'Allowed values list', that pulls this list:

// Load the node containing our list in its body.
$node = node_load(189561);
if (!$node) {
  return array('error' => 'Hey! 189561 is just an example. Reaplce it with some other, valid NID!');
}

// Split the text into lines
$list = explode("\n", $node->body);

// Sanitize it a bit
$list = array_map('trim', $list);
$list = array_filter($list, 'strlen');

// Convert it to a format expected by cck
$list = drupal_map_assoc($list);

// All's done. Return it.
return $list;

Important: You should not remove items from the list (that is, from node 189561's body) once you use them. That's because when CCK prints items it first looks them up in this list (that's because this list is a double list: besides the item itself it contains also its printed representation). If it doesn't find the item in the list, it doesn't print it. That's true even for plain lists, where no PHP coding is involded.

--
Help save BLOCKQUOTE

andyf’s picture

andyf commented

thanks mooffie,

1. CCK Taxonomy works very well. I think I'll use that at least for the time being. The only problem with it (please confirm) is that I can't edit the page where you enter values (ie the add term page) to have instructions specific to adding the name of a company. So perhaps I can start with taxonomy, and maybe later move onto your node approach.

2. Thanks so much for the php code to create the allowed values: I got the distinct impression it took you two minutes, and it would've taken me forever to find the appropriate function calls;)

if your take the second solution, the "PHP free" one, you'll end up writing much more PHP code than in your first solution

3. Why is that? I ask because I'd still like, if possible, to hide the Categories menu item for my staff, and create menu links to the add terms page. That is, the link might read Add new recruiting company and the actual URL could be admin/content/taxonomy/2/add/term. Do you see any problems with that?

Thanks again for your help,

Andy

PS Is there a reason to prefer using a CCK field linked to a vocabulary using CCK Taxonomy than just vanilla Taxonomy to classify my node? Perhaps the way they're stored in the db is different? I'll probably stick with CCK fields anyway for consistency (can't use taxonomy for numerical fields such as years' experience), but was just a wondering...

mooffie’s picture

mooffie commented

if your take the second solution, the "PHP free" one, you'll end up writing much more PHP code than in your first solution

3. Why is that?

I don't have an estimation of the amount of code needed. I'll have to virtually write the code in order to answer that question sufficiently....

I ask because I'd still like, if possible, to hide the Categories menu item for my staff,

So we're back at square one ;-)
Right now I can't think of a way to let unpriviledged users add terms nicely.

[...] if possible, to hide the Categories menu [...]
URL could be admin/content/taxonomy/2/add/term.

You might be able to use path_access to restrict access to paths. (E.g.: 1. grant some users (that is, a role) the 'administer taxonomy' right; 2. using this module, ban them from 'admin/content/taxonomy*'; 3. then enable them 'admin/content/taxonomy/2/add/term'; but I haven't tried this, don't know if this will actually work.)

Do you see any problems with that?

It sounds somewhat inelegant.

I've suggested --see bellow-- to use nodereferences. Consider this.

PS Is there a reason to prefer using a CCK field linked to a vocabulary using CCK Taxonomy than just vanilla Taxonomy to classify my node? Perhaps the way they're stored in the db is different? I'll probably stick with CCK fields anyway for consistency (can't use taxonomy for numerical fields such as years' experience), but was just a wondering...

That's a good question. A bigger question is "what should I use taxomomy for?" and an even bigger one is "what shouldn't I use taxonomy for?" I don't have good answers, though.

--
Help save BLOCKQUOTE

mooffie’s picture

mooffie commented

When creating a new job advert, you have to select the name of the recruiting company from a dropdown list

BTW, it's also possible to do this with a nodereference field. The companies would all be nodes, say of type 'company'. To your 'advert' node-type you'd add a nodereference field that can point to a 'company' node.