Closed (fixed)
Project:
Diff
Version:
7.x-3.0-alpha1
Component:
User interface
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
27 Apr 2012 at 13:38 UTC
Updated:
29 Jul 2012 at 10:41 UTC
Hi,
I think it would be much more meaningful to show the change in value, not the key, for a field that is a pick-list.
See attached for an example of the current behavior. For the field "Pick One" I chose a new value, "Option Three" from the list, but when you look at how diff displays the change, you see that it is displaying as a change from 1 to 2. 1 and 2 are the keys (indices) for these values.
Our users find it quite odd that they see the text change for regular text fields, but not for select lists. The attached example image illustrates this contrast.
We encountered this problem for the first time when we upgraded to Drupal 7, and migrated our content from CCK to D7's Fields. When using CCK, the diff module would always display the value for lists, not the keys. Or, perhaps in D6 there was no key, only values? Were "keys" for the various values added by D7's Field system?
-Josh
| Comment | File | Size | Author |
|---|---|---|---|
| 2012-04-27_0931.png | 28.9 KB | jbeall |
Comments
Comment #1
dwwYup. Seeing the same thing for the D7 port of the project_issue.module (used here for the issues queues on Drupal.org). When viewing the diff between 2 revisions of an issue node, instead of seeing:
We're seeing
This is just a generic core list field, not any custom magic in project_issue, so it seems like a bug here in diff, not a result of project_issue not implementing hook_diff()...
Comment #2
Taxoman commentedAs this is at the heart of what this module is meant for, I'd say this is "Major".
Comment #3
alan d. commented@dww
Do you know what module is providing the diff results for the select lists? Last time I checked, only text fields were covered and none of the main modules implemented any field diffs.
So before 50 modules independently handle the field logic required, I'm going to try and push a patch for internal field handling.
Comment #4
dwwIt's just a core field. Seems like diff.module should be responsible for handling diff for core fields, kind of like views has always been responsible for handling core tables/fields/filters/etc.
Comment #5
alan d. commentedYep, I forgot that it fall back to the value column.
Real stab at resolving this here: http://drupal.org/node/1365750#comment-6108002
With some after thought while doing the boring task of setting up one of each of the core field types, maybe the fallback should simply use the default full view mode... At the moment, I'm only looking at the safe_value and value columns.
Comment #6
alan d. commentedMassive patch over in #1365750: Generalize API and Integrate with core field types needs some testers. If accepted, this will make this issue a duplicate.
Comment #7
alan d. commentedIn another task, I'm refactoring the field comparison.
These are two raw outputs based on the minimal default comparison and the full comparison for images, files and lists (will cross post this to #1458814: File (and image) field support if you want to comment on the image or file format). Currently the output is controlled by a system variable that defines the defaults.
If the label is the same as the key or not defined, then the key is used.
Options are:
key only
label only (default)
label and key in the format "label (key)"
Comment #8
alan d. commentedThis should be resolved with the new branch, 7.x-3.0-alpha1 or 7.x-3.0-dev.
This is still alpha, so test carefully before use on a production site and report any issues back to the queues.
Comment #9.0
(not verified) commentedAdded clarification.