I have some use cases where I want fields to display but not be editable. E.g., may be used in an editview that has a limited purpose, such as assigning tags to otherwise completed nodes.

Comments

_paul_meta’s picture

+ 1 to this.

it would be *fantastic* if you could specify which fields should be editable.

for example - i might wish to have title and two cck fields shown in the edit view. but - i only want the two cck fields to be edit-able and the title is fixed.

thanks :)

charliek’s picture

I am also very keen on this idea.

I would like to be able to have and admin or an editor create a node, complete some of its CCK fields, and then hand it over to another user - who can only edit a subset of those fields, while still being able to read the content of the 'read only' ones.

If there's an existing way to do this, I'd love to hear about it, too, clearly!

dooug’s picture

Status: Active » Closed (duplicate)

duplicate of the original poster's item #2:
#154782: EditView individual field items - using the default form rendering

I also would love to see this feature implemented for the EditView module.

aren cambre’s picture

Status: Closed (duplicate) » Active

Per #3 at #154782: EditView individual field items - using the default form rendering, this issue is the one that should remain active.

boran’s picture

+1

vglocus’s picture

+1

Frodo Looijaard’s picture

See also #93177: Various feature requests:
Allowing per field editing. Perhaps with a checkbox on the field setup. This way, I could display a list of nodes to change their taxonomy, but not allow the node titles to be changed.

endiku’s picture

+1

scarvajal’s picture

+1

Is a great module, but for my current needs is useless withouth this feature.

And by the way, could be great if the edit view style use the field settings.
It's kind of weird that after you set a field to "exclude from display" the field is displayed anyway.

jwilson3’s picture

Status: Active » Needs review
StatusFileSize
new1.37 KB
new167.19 KB
new189.75 KB

This straightforward patch adds an 'Editable' checkbox on ALL field config subforms in views. There is no special logic for determining which fields can/cannot have the checkbox. And, if your view is not setup to use Editview module already, then enabling the 'Editable' checkbox will have absolutely no effect.

What this patch does:

1. Only show the form-items for a given field if:

a) The editview plugin is properly configured for the view (either by the row style, or the display type), AND
b) The Editable checkbox is checked for the given field.

2. If Editable is unchecked, hide the other form fields on the page, and show the normal rendered field values instead.

3. Note that this patch is only tested against 6.x-1.x-dev snapshot as of today. And is confirmed to work only when you DO NOT enable node-add ability to the view.

There is possibly some potential here to add in more js click-to-edit (a la flickr)... if someone wanted to take the lead on this that would be awesome.

jwilson3’s picture

Here's an improved patch that fixes a few things left out by the previous version.

* Adds the 'Editable' checkbox onto Views' Field config sub-form only. Previously it was showing on nearly every Views subform, eg Arguments, Filters, Sort, Relationships, etc.

* Improved description text explaining what the 'Editable' checkbox does.

* Only show the save/delete buttons on a given row, if at least one field is editable. This allows you to specify NO fields as editable, and still use the New Node create form (either above or below the regular views form).

* Always render existing node titles as text/link when Auto_NodeTitle module is installed and configured. Show a message that the title is generated automatically on the New Node section of the view.

* Always render required fields as editable on the New Node section.

* More accurately display the regular field value, If the field settings have its 'Editable' checkbox left unchecked. (In the previous patch I was using $field->last_render incorrectly).

tfranz’s picture

Tried your patch, but unfortunately it doesn't work for me ...

1. Removed 6.x-1.0-beta2
2. Patched 6.x-1.x-dev (2010-Nov-12)
3. Activated the module, emptied cache, cron.php
4. Built a view, the "Editable"-Checkbox appears
5. Clicking the checkbox on the fields, press "Update" ... but it didn't save the status of the checkbox!

Result: there is no table rendered at all ... :-((

OliverColeman’s picture

StatusFileSize
new6.83 KB

I applied the patch in #11 manually to 6.x-1.0-beta3 (I didn't actually try automatically) and it worked. I wonder why it didn't work for you, tfranz? How did you apply the patch? And to which version?

I've modified it a bit so that:
- instead of hiding the form elements using CSS it actually completely removes them;
- following on from the first point, it allows modules implementing hook_field_form_render to insert a value/additional data (useful for me for the new node row for non-editable fields);
- it only shows the "editable" checkbox when the editview style plugin is selected for the view display being edited.

To do this required modifying hook_field_form_render (or at least that seemed the best way of going about it) by adding on an argument for the current value of the field, the new argument has a default value of NULL so this shouldn't impact on any existing implementations of the hook.

This patch is against 6.x-1.0-beta3.

OliverColeman’s picture

I just had a problem where I applied my updated patch and the view disappeared (the View UI complained about a missing style plugin). I disabled and enabled the editview module and all was well again (I also tried clearing all caches to no avail). Perhaps this will work for you?

OliverColeman’s picture

A few more thoughts and possible improvements:

Just realised the patch in #13 hook_form_alter function should be modified to check for the form_id before attempting to extract view information (silly mistake...). I won't post another patch until the issue of sliding/replacing the view is decided.

It would be better just to replace the view contents and not the exposed filter elements or pager (I thought about this but decided I didn't have enough time to stuff around with it (still don't!)).

I was thinking about the delete operation: in some instances it might make sense to reload the view, for example when the view is set to display N items per page, or the last item has been deleted and the empty text should then be shown (these cases could be tested for on an ajax call rather than always updating the entire view).

_paul_meta’s picture

Just wanted to say I tried the patch at #13 and this worked fine for me (also patching against 6.x-1.0-beta3

The workaround for autonodetitle is great too.

Thanks a lot!

WesleyTx’s picture

Thanks for the work so far, guys.

I have a couple of comments on the patch at #13. Unfortunately, it doesn't work when the view style is "Unformatted" and the row style is set to "Editview." Also, when an image field is added, and the field is set as not editable, the image no longer displays. With the patch at #11, the image itself still displays; only the text fields are removed.

Also, I noticed with both patches that the "Editable" checkbox does not retain its value.

Thanks again!

murz’s picture

subscribe

dreamer777’s picture

As an issuie of #12 in beta3 - the Editable checkbox is not saved.