I'm not sure if this is a bug report or a support request. I have two content types, which share a bunch of fields. I thought I could do things like change the 'required' setting for the field in one of the types, but not the other. It's not working for me. In fact, if I go to:

  • content type 2 > manage fields > a shared field > configure

it reloads the manage fields page, and doesn't open up the field editing page (though the url changes), but if I go to

  • content type 1 > manage fields > a shared field > configure

it works fine.

I created the first type weeks ago, just upgraded to 6.3, and created type 2 afterwards, if that makes a difference.

Comments

dopry’s picture

Status: Active » Closed (fixed)

No, required is a field setting... and is common across instances of a field when shared. Only widget values are unique per field instance.

sprugman’s picture

Ok, but I can't even get to the page to change the widget values. (Required was just an example.)

sprugman’s picture

Status: Closed (fixed) » Active

I was trying to achieve the field mods I want using hook_form_alter. When I do this:

function mymodule_form_alter(&$form, $form_state, $form_id) {
	if ($form_id == 'mytype_node_form') {
		$form['field_myfield']['#required'] = false;
	}
}

it doesn't do anything to the form. Do I have the syntax wrong, or is CCK immune to hook_form_alter?

----

Meanwhile this:

I can't even get to the page to change the widget values.

must have been a cache issue or something, because now it's working, but I swear it wasn't before. Hmm....

dopry’s picture

Status: Active » Closed (fixed)

Don't use form alter... if you need an unrequired field... create a new field. As for the caching issues... beats me.. but yeah I hit this same cache issue after adding an existing field...

So I'm doing a menu rebuild any time content_field_instance create is called the DRUPAL-6--2

sprugman’s picture

Status: Closed (fixed) » Active

I'm pretty disappointed not to be able to use form_alter. I have a cck type with 40 fields, which have different field requirements, depending on which role is filling out the form. Can I use content permissions for that? I've been afraid to turn it on, lest I'm blinded by a sea of checkboxes. Maybe this is beyond the scope of what cck can do and I have to figure it out using a custom module. Here's the workflow I'm hoping for:

customer creates node - only sees 10 fields in the form, only 2 of which are required, node is unpublished on submit

manager receives email that new node has been created, fills out other 30 fields, 15 of which are required, along with 5 of the customer's fields, publishes the node

once published, customer can't edit, but can see 30 of the 40 fields

editor can update 3 fields. When they click edit, they only see those three fields, but they can view 35 of the 40 in the view state. When they edit, the node remains published.

(Note: this is a slightly separate issue from the second content type one -- all of this workflow is for the first type, but I was hoping to use form alter to achieve some of it.)

Any hints on how to accomplish this with CCK?

christefano’s picture

I'm having the exact same problem. Checkbox Validate is a workaround (for D6 only, it seems).

karens’s picture

Status: Active » Fixed

@sprugman, use Content Permissions, that's exactly what's for. The reason for not using hook_form_alter() is because CCK uses hook_form_alter() to get the fields in there in the first place, so you have to get behind it to have it work at all. But even more importantly, selectively hiding CCK form elements can cause data loss if it's not done right. See #298440: CCK Content Permissions - Mangled field data when users don't have edit permission. for an example of the kind of problems you'll run into. And the CCK Permissions module in D5 has a whole list of problems that can (and have) happened when it didn't work right.

If you use Content Permissions, it's our job to get those things working right and you have the whole community to help debug it. If you do it in some custom way, you'll be on your own.

@christefano, I don't know how Checkbox Validate integrates with CCK, but see my previous comment. Messing with those form elements can be dangerous if you don't know what you're doing.

sprugman’s picture

I wound up using content permissions, despite it's fearsome interface, but I have two use cases for which I think it is inadequate:

1) A field that is optional for node creators, but required for node publishers.

2) A type that can be edited by any manager, and which has some fields that can be edited by any salesman, but other fields that can only be edited by the salesman to whom the node has been assigned (via userreference). Thus, salesmen have to able to edit the fields, but most of 'em can't edit most node's fields.

Messing with those form elements can be dangerous if you don't know what you're doing.

Which is exactly why one posts a support question to a forum like this: to learn how to do it right. I've had some luck with form_alter since posting this (though my results are still a bit mixed), and have discovered that I can set #access to false to make the field disappear. Hopefully, that won't cause me any big problems.

#298440: CCK Content Permissions - Mangled field data when users don't have edit permission.

That does indeed sound like a nasty bug, and I'm officially afraid of hacking at cck forms for this sort of thing using form_alter, but I don't see how to accomplish my requirements without it. If I'm wrong, please correct me.

karens’s picture

The patch committed at #298440: CCK Content Permissions - Mangled field data when users don't have edit permission. includes a hook_field_access that your module could try using. See how the Content Permissions module uses it and create your own implementation. The idea is that you could provide a second, higher, level of security for selected nodes with your custom hook.

Having said that, I don't know if the hook has all the info needed for this to work right, but try it out and file a feature request if you see a way to improve on it.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.