Feature #17234
closed
Evaluate label and label-alt in the title bar of child records.
Added by David Steele about 17 years ago.
Updated about 11 years ago.
Description
I have a user table and a membership history table. There is a normalised 1:n relation from the user table (parent) to the membership history table (child), using 'type => 'inline'.
Each record in the membership history table has two fields (plus the usual TYPO3 ones): the membership type and a date. I want to put the membership type and the date into the title bar of each child record which is visible when I edit the parent record. I've used the membership type field for the 'label' and the date for the 'label-alt' in the 'ctrl' part of the $TCA for the membership history table.
The date appears as a Unix-time number (which is how TYPO3 stores it) in the title bar and isn't evaluated as a date. But if I expand the child record I can see the date field inside has been evalutated.
Similarly, I've stored the membership types in another table, and this is available to the membership history records as a database relation to a custom table, accessed through a selectorbox. This is evaluated to the membership type inside the child record, but when this field is used as the label in the title bar, all that appears is the uid of the relevant record in the custom table.
(issue imported from #M5483)
This problem happens not only in this IRRE situation, but on any call which needs the label for a table that has a datetime/date field specified as the label/label_alt for it (e.g. list-view). Will be fixed
timestamps in the BE
In some versions of TYPO3 (e.g. 4.0.5) the title in the List-view rendered through t3lib_BEfunc::getProcessedValueExtra instead of t3lib_BEfunc::getRecordTitle - the result was correct date/datetime-formats.
Now (TYPO3 4.1) titles and labels rendered through t3lib_BEfunc::getRecordTitle. The following lines check the date/datetime fields via TCA and convert the timestamps to a readable format.
class.t3lib_befunc.php
@ -1849,6 +1849,11
@
$t=implode(', ',$tA);
}
}
+
+ // label based on a Field type: date, datetime
+ if ($TCA[$table]['columns'][$TCA[$table]['ctrl']['label']]['config']['eval']=='date' || $TCA[$table]['columns'][$TCA[$table]['ctrl']['label']]['config']['eval']=='datetime') {
+ $t = t3lib_BEfunc::datetime($t);
+ }
}
// If the current result is empty, set it to '[No title]' (localized) and prepare for output if requested
Hi, how are things going with this bug? It doesn't appear anything has happened for nearly five months.
Thanks, David.
@David,
the processing of labels through t3lib_BEfunc::getProcessedValue also for timestamps has been in core for a while now, but I guess it hasn't been commited to TYPO3 4.1, which is why it is probably buggy there.
See bug #17332.
It has been commited to trunk some months ago (2007-11-15 Ingmar Schlecht), so it is in the latest 4.2beta. Please check out if it works there. If it doesn't, then it is probably something IRRE-related.
is that really solved?
I had this issue today where i used crdate as label. Output was timestamp, so i had to do a trick for display it as date:
'type' => 'input',
'eval' => 'datetime'
There is no type 'timestamp', field is int(11) so we need an additional info that this is a timestamp, or allow eval for more types
@Steffen: "eval" is what decides upon how the stored data is displayed. If "datetime" is what you want, it is ok like you have it.
So was there an issue with that or not?
@Ernesto: the eval is also used for display in t3lib_befunc::getRecordTitle
But i know my solution is dirty. So is there any "official" way to use eg crdate as label showing it as datetime?
(May be display should differ from store, the only way i know is to use userfunc with label)
Why is it "dirty"? I think your solution is the right way to do it. Or have I misunderstood something?
ok, i forgot that saving is ok too as datetime always saved as timestamp.
So it's fine with me, but may be it should documented explicit as i see such question very often in forum.
Hi,
this is now working in TYPO3 4.2.6, so perhaps it should be considered fixed and closed now?
Thanks!
- Status changed from Accepted to Closed
- Target version deleted (
0)
Also available in: Atom
PDF