Community
Participate
Working Groups
The sprint drop down is too wide. For some tasks, it spans both attribute columns, whereas for other tasks, it is in the right column and causes that column to be too wide. Which column it goes in seems to depend on whether the task has any subtasks.
That is related to third party extension. We are not able to address that on the Mylyn end.
Actually, this is just a custom dropdown field in a bugzilla editor and not specific to a third party extension. Sam, can you post a small screenshot of what this dropdown looks like, especially since it will lay out properly sometimes as well?
Created attachment 191867 [details] screenshot One task shown above the red line, another below. Notice that the Sprint field is wide and the Effort field is in a different order.
I actually don't think this is related to the blocks or depends fields (contrary to what I said in the description).
Interesting. Looks like the spring field has weird version constraints.
Umm, you have been doing releng too long :D I assume that you mean that the sprint field has some weird sizing constraints :D
Can you post the definitions and values of your cf fields?
I have committed the attached fix to head. Can you verify Sam if that fixes the problem for you?
Created attachment 192406 [details] mylyn/context/zip
Created attachment 192407 [details] fix
That has fixed the width problem. Note that the fields still appear in different orders on different tasks.
Frank, is the order in which custom fields are added to task data fixed?
(In reply to comment #12) > Frank, is the order in which custom fields are added to task data fixed? The order is set by LayoutHint.getPriority() and we overwrite it in BugzillaTaskEditorPage.createAttributeEditorFactory for custom fields we multiply the value with 10. Should we add sort for id when priorities are equal? Thoughts?
Attributes that have an equal priority should still end up in the same order on each task following the order in which they were added to the task data.
Applied patch to e_3_7_m_3_5_x branch.
I have opened bug 342367 to track the problem that causes differences in the ordering of custom attributes which is unrelated to the original problem tracked on this bug.
