Closed (fixed)
Project:
Content Construction Kit (CCK)
Version:
6.x-2.0-rc4
Component:
General
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
23 Jul 2008 at 21:26 UTC
Updated:
9 Sep 2008 at 01:52 UTC
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:
it reloads the manage fields page, and doesn't open up the field editing page (though the url changes), but if I go to
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
Comment #1
dopry commentedNo, required is a field setting... and is common across instances of a field when shared. Only widget values are unique per field instance.
Comment #2
sprugman commentedOk, but I can't even get to the page to change the widget values. (Required was just an example.)
Comment #3
sprugman commentedI was trying to achieve the field mods I want using hook_form_alter. When I do this:
it doesn't do anything to the form. Do I have the syntax wrong, or is CCK immune to hook_form_alter?
----
Meanwhile this:
must have been a cache issue or something, because now it's working, but I swear it wasn't before. Hmm....
Comment #4
dopry commentedDon'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
Comment #5
sprugman commentedI'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?
Comment #6
christefano commentedI'm having the exact same problem. Checkbox Validate is a workaround (for D6 only, it seems).
Comment #7
karens commented@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.
Comment #8
sprugman commentedI 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.
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.
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.
Comment #9
karens commentedThe 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.
Comment #10
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.