Bug #64362
closed
Sorting records by a related tables label column not possible
0%
Description
Using the list module, it is not possible to sort records by the "label" column of a related (n:1) table.
Although TCA definition ("default_sortby", "label", etc.) is correct for both related tables, the records are sorted by the foreign records uid instead of its label column.
In my opinion this rather is a bug than a missing features, because the foreign tables "label" column is display correctly - but cannot be sorted.
I don't know if this only affects 4.5, but i could imagine it is the same behaviour with 6+. Core-people should know exactly ;)
Files
Updated by Jan Kornblum almost 10 years ago
I don't know if this only affects 4.5, but i could imagine it is the same behaviour with 6+. Core-people should know exactly ;)
I can confirm the same behaviour in 6.2.3.
Updated by Mathias Schreiber almost 10 years ago
- Status changed from New to Needs Feedback
- Target version set to 7.4 (Backend)
That would mean that we'd need to join each related table whose field is visible to the table that is being listed.
I'd set the complexity to somewhere between "hard" and "nightmare" because it'd need a pretty solid rewrite of RecordList :)
Updated by Jan Kornblum almost 10 years ago
Oh, i didn't know that this would be so difficult. I've assumed that a join is already done for related tables columns and in this case respecting a "table.column" notation for default_sortby could be enough. How are the related labels fetched else? Single lookups?
Updated by Alexander Opitz over 9 years ago
- Status changed from Needs Feedback to New
Updated by Susanne Moog over 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Felix Oertel over 9 years ago
- Priority changed from Must have to Should have
- TYPO3 Version changed from 4.5 to 7
I am pretty sure this worked before.
As a temporary "solution" you can - please don't hurt me - do this:
[columns][category][config][foreign_table_where] => 'ORDER BY category.name'
I know it sounds wrong to put your ORDER-BY-string-SQL inside an option that is named something with "_where", but it is even in the official docs. ;-)
Updated by Benni Mack about 9 years ago
- Target version changed from 7.5 to 7 LTS
Updated by Jan Helke about 9 years ago
- Status changed from New to In Progress
- Assignee set to Jan Helke
Updated by Jan Helke about 9 years ago
- File testext_0.0.1.zip testext_0.0.1.zip added
Attached you'll find a test extension to easily reproduce the issue. After installing there is a sql file containing a couple of data rows. Just replace the PID in the file with a value suitable for your system.
Updated by Gerrit Code Review about 9 years ago
- Status changed from In Progress to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/44421
Updated by Gerrit Code Review about 9 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/44421
Updated by Gerrit Code Review about 9 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/44421
Updated by Gerrit Code Review about 9 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/44421
Updated by Gerrit Code Review about 9 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/44421
Updated by Jan Helke about 9 years ago
- Status changed from Under Review to Rejected
- Complexity set to nightmare
I will abbanden my patch, because it came up, that this is not entirely fixable. I was able to fix it as long as we only deal with internal tables. But at the point somebody infused some addWhere stuff thru TCA (compare Felix coment about "order" in the where clause) without proper namespacing that (tablename.fieldname) it will break. And I see no reasonable way to write a parser that ensures sanitization in all cases.