Bug #2960
closedCB 1.7.1 substitution check uses language string value instead of stored field value
Description
As described here:
https://www.joomlapolis.com/forum/253-potential-bug-122/173887-email-message-merge
Verified on my local testing.
[cb:if cb_sex="_MALE"] Mr.[/cb:if][cb:if cb_sex="_FEMALE"] Mrs[/cb:if]
Looks like the comparison is testing cb_sex against the translated value of _MALE instead of the database stored value of _MALE.
Files
Updated by nant almost 13 years ago
- Status changed from New to Assigned
- Assignee set to krileon
Updated by beat almost 13 years ago
- Target version set to CB 1.8
The translation is done in PHP mode in cb.core.php line 737 and 742 of r1650 . Maybe those should be not translated. Affects all uses of the getField, so needs a review.
Updated by krileon almost 13 years ago
The only getField usage where PHP output is used is in the substitutions. Seams safe to remove the translation of values for PHP getField usage.
Updated by krileon almost 13 years ago
- File 2960.patch 2960.patch added
- Status changed from Assigned to Resolved
- Assignee changed from krileon to beat
- % Done changed from 0 to 100
Further review it appears that select fields are the only fields where the values are translated for PHP output, all the others output raw.
Updated by krileon almost 13 years ago
- File 2960_rev1.patch 2960_rev1.patch added
Noticed PHP and CSV had same formatting changes; rev1 added to just use it.
Updated by beat almost 13 years ago
- Status changed from Resolved to Closed
- Estimated time set to 2:00 h
Thanks.
Fixed in r1722 .
Kept code, with check for $reason finishing with ":translated", that way maybe some uses in substitutions will work like e.g. : reason="profile:translated" for those fields.
Ohterwise falling through like suggested to csv method.