Closed (works as designed)
Project:
Editable Views
Version:
7.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
28 Oct 2013 at 15:38 UTC
Updated:
30 Oct 2013 at 09:36 UTC
Jump to comment: Most recent
Comments
Comment #1
joachim commentedI've not tested it with the File Usage relationship. It works fine for me with entityreference relationships pointing to nodes.
Is your relationship required? If not, might it be resulting in partially empty rows?
Can you do some debugging to see where the problem is?
Comment #2
aseabrook commentedThe view is of type Users. It seems to be happening with the following relationships:
In the frontend, on the rows that the editable field isn't functioning, the follow code parses:
<div class="views-row-edit-edit"></div>On the rows that are functioning properly:
I thought that the issue could be with the Select (or other) module but when I tested it with a standard list field I still encountered the same issue.
I think the culprit may either be the User Revision relationships or user relationships in general.
Comment #3
joachim commentedIs your relationship producing empty rows as part of its normal operation?
Comment #4
aseabrook commentedNegative. That large code chunk that I inserted in my previous post (the editable field) is what normally appears on all rows. The moment I add a user relationship, the editable field disappears on certain rows.
What's strange is that the disappearance pattern is different depending on the type of user relationship (e.g. User: Content authored; User revision: Revision author (User Revision module); User revision: User (revision ID) (User Revision module); User revision: User (uid) (User Revision module)).
Comment #5
joachim commentedCan you reproduce this on a view that uses only core components, and export it please?
Comment #6
joachim commented> User: Content authored
That produces multiple rows per user, doesn't it?
In which case, this behaviour is completely normal: you only get one form element for each entity's field. The editable field does not get repeated, unlike regular fields.
Comment #7
brightbold@aseabrook — Yes you have something in your view relationships that is creating duplicate rows. I was having the same problem and it turned out I had a taxonomy term relationship where I had failed to check the vocabulary I intended. So instead of there being a 1:1 entity:term relationship, there was a 1:many, and I was getting a new views row for each term present. (This was true even though I had set the query settings to Pure Distinct.) When I fixed the taxonomy relationship so only one vocabulary was used, all my phantom rows disappeared.