Bug #18413
closedList view fault in backend Element Browser popup
0%
Description
When using the list view of the backend's Element Browser popup the plus icon [+] next to the table name does not do anything at all.
This is not only confusing since it is different from the default list view behaviour of TYPO3's backend, futher more is restricts the display of fields in the Element Browser list to the default fields. So the user has no possibility to display and search other fields like he could do in the default backend list view. This is a very inconvenient restriction.
Currently the only possibilty to manipulate this is XCLASSing of the class localRecordList (for default backend list view) and TBE_browser_recordList (for element browser popup record list). I really would like to avoid XCLASSinf for the well-known reasons...
When using the list view of the backend's Element Browser popup the plus icon [+] next to the table name does not do anything at all.
This is not only confusing since it is different from the default list view behaviour of TYPO3's backend, futhermore is restricts the display of fields in the Element Browser list to the default fields. So the user has no possibility to select other fields to display and search like he could do in the default backend list view. This is a very inconvenient restriction.
Currently the only possibilty to manipulate the Element Browser's display of fields is XCLASSing of the class TBE_browser_recordList and overriding the method setDispFields() of the parent class recordList (of file class.db_list.inc). This was really hard to figure out and I really would like to avoid XCLASSing for the well-known reasons...
Thanks & best regards,
Rainer
(issue imported from #M7809)
Updated by Rainer Kuhn over 16 years ago
Sorry for mixing up texts in "description" and "additional information" fields of bugtracker. The additional information field contains what I wanted to say, I did not find any possibility to edit my initial entry in bugtracker.
Updated by Christian Kuhn almost 16 years ago
Confirmed this behavior for 4.1-branch, but this issue is not reproducible with 4.2-branch (rev. 4806) anymore.
Set issue to resolved, fixed.