Save default value when user has no permission to edit the field
Amitaibu - November 16, 2008 - 10:39
| Project: | Content Construction Kit (CCK) |
| Version: | 6.x-3.x-dev |
| Component: | content.module |
| Category: | feature request |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Description
Scenario:
1. Create text field called state with Pending, Complete, Error.
2. Set field to be required.
3. Set field's default value to pending.
4. Allow user to view field_state but not edit.
5. Create node - field_state isn't set.
This might be by design, but I think it's a bug.
#1
And here's the patch.
#2
Doesn't work like that. Default values only come into play on node *creation*. The default value shouldn't override the existing value on node *edit*
Plus your patch doesn't get the actual default values correctly.
If we want this behavior (which I'm not sure we do, might need some consideration), the
if (!$access) {code branch needs to be moved down the// Prepare the values to be filled in the widgetpart.#3
Plus I don't think 'required' status is actually related.
#4
Moved
!$accessdown.My use case is that, using the rules module, I'm preforming an action upon node save according to a certain field value, that the user can view but can't edit.
#5
I'm interested in this as well. Use case: user submits subscription and required payment field is set to not okay by default. Only staff can update this to default. The current situation creates an empty required field.
So I very much support fixing this, if possible.
#6
+1 It is a pain having to add another check on every query for NULL when the field should only be set to the default.
Eg: WHERE xxx_field IN (1,2,3) becomes WHERE (xxx_field IN (1,2,3) OR xxx_field IS NULL)
#7
See #260439: Field premissions blocking default value. also.
#8
Right, I marked that 'old' one as duplicate.
#9
Is there any update on this problem? What would be a good way to patch around this?
#10
I took a two step approach to this in a project where it was vital to ensure that the defaults were set.
Firstly, define up a custom action for Rules. Since the logic was complex, I defined a new action to set the default for each content type.
Then I added a backup hook_cron to blanket set all required fields that were NULL, just in case...
#11
subscribing
it's much more reasonable to make the unprivileged field gets its default value
which's much better for many applications
looking forward the issue can be fixed in upcoming release
#12
subscribing
#13
subscribing... i posted same issue against cck_field_perms back in Dr5 days about a year ago. Seems like issue still persists with Dr6 field perms built into CCK.
Not sure the use case where user wouldn't want field defaults to take precedence over field access privileges. Every case i have come across, if i define a field to have a default - i REALLY do want that to be the default.
In case if there is a valid case where you DON'T want defaults to be your defaults based on access rights; then maybe some sort of checkbox with default to override perms?
#14
I have made a little bit of a change to the patch in #4 that I find makes it work a bit better (the patch in #4 skipped access control when editing an existing node).
This patch is against the current 6.x-2.x-dev version (2009-Apr-16).
#15
subscribing
#16
I think #14 is a worthy patch. Still needs some review before commit. I am upping priority so it does not get missed when a D7 port is made.
#17
Note that 'save default value on object create' is already in D7 with a different approach, which also accounts for programmatic node creation (node_save).
Backporting this would require some refactoring, so I personally won't go there.
Patch #14 looks fine, but I don't think I see the need for the additional
+ if (empty($node->nid)) {+ $value = $items;
+ }
+ else {
+ $value = $node->$field_name;
+ }
Could someone test the attached patch and see if it works ?
#18
UG. I have had this problem now for about 2 years. I am on drupal 5.. Any chance this can be backported? I have similar situation. Customers submit an order. The order has field_status "Received" or "Shipped". I don't want users mucking with this for obvious reasons so I used cck_field_perms to hide the field on the node creation form. Problem is, the default value of "received" isn't set so I have to go back through all the orders every day and set them to "Received". It takes a lot of time. Would be great if they were set to "received" by default. I can't upgrade to D6 as too many modules I uses just are not supported, namely Paypal Node.
I guess if it's not going to happen, I'll use a workflow..
#19
Tested patch in #17 with current d6 dev code, works as expected. excellent!
#20
Committed to 6.x-2.x branch.
Here's the same patch rolled for the 3.x branch, I don't think it should break anything with multigroups, but I'll let Markus chime in.
(I'm not sure what happens with multigroups if one of the fields is hidden by access permissions, BTW)
#21
Forgot to re tpainton #18: No, this won't happen in D5. CCK D5 is feature-closed. With all the work on Field API in core, adding, debugging and maintaining features in 3 branches for 3 core versions is simply not doable. Unless someone steps up to be the CCK D5 maintainer.
#22
I totally understand. Thanks for what you have already done.
#23
Subscribing so I don't forget this issue.
PS: I just came back from a little break (just a week on holidays) and I'm still landing...
#24
Committed to 6.x-3.x branch.
Indeed, the multigroup was in need of a minor adjustment during the rendering process of the form. The fix was pretty simple.
The multigroup (and also fieldgroup) modules check for the #access property of the form elements, but in the case of multigroups this also needed to ignore the fields of type 'value' during the rendering process. Otherwise, an empty row was rendered for each *hidden* field.
#25
I'd really like to see a full solution to this issue for D6 for either use of CCK (programmatic / interactive node creation).
#26
subscribe
#27
Automatically closed -- issue fixed for 2 weeks with no activity.
#28
I'd like to subscribe here too.
I've searched many, many other modules to get that functionality - bit there is no other way.
Please, could you fix that?
(I would help - but I don't know PHP at all, and Drupal coding even less)
#29
huh? This issue is closed-- if you had bothered to read it you would know the fix has been committed to both the 2.x version (#20) and the 3.x version (#24).
#30
Yes, I bothered to read all the posts. But despite the "fixed" status I STILL have the problem here, with a fully updated drupal 6.14, CCK 2;
I have a date field that has a default value, and only admins can edit/view it due to permissions.
If an admin creates the node, the default date (today) is saved, but if another one creates the node, he doesn't see the field - and the date value afterwords is empty in the view.
So unless I didn't do anything horribly wrong I suppose this bug is not fixed?
(Please correct me if I am wrong)
#31
Forgot to mention - the normal user can view the field, but not edit it.
Despite that it gets NOT filled out.
#32
The fact still remains that this issue has been committed and closed. Besides the fact commenting on a closed issue is useless, and the fact that no one has reopened this issue in the 4 months since the fix was committed (with over 100k cck users, someone would have reopened it if it really wasn't truly fixed), the fact that you have a problem with a date field means you should probably first post to the date issue queue.
#33
You're right - I must admit that the field I have the problem with is a date field.
I will post it there.
Thanks anyway.