Open TrueType opened 4 years ago
@TrueType
Did you try doing a recursive search on Github before making this post? We have a fix here:
Cheers.
@JediKev I really don't think so. Please have a look at getKeys() function. https://github.com/osTicket/osTicket/blob/develop/include/class.forms.php#L1847 This functions works on a "choice" record, which is an assoziative array in the current code. It was an ordinary array in older versions (>2years ~1.10.1) and where the "0" values came from. Now with the lastest code you may get the correct key of the option selected. But you still dont get anything worth to be glued together.
@TrueType
We will have to look further into this to confirm.
Cheers.
@TrueType
Re-tested with latest develop-next
(14:06 PM CST March 9, 2020) and the cdata table saves the key(s) for the choice(s) like key1
if one choice is selected or key1, key2
if multiple choices are selected. We then explode the keys via ,
(with this fix: #5399) and lookup the value for each key. In the Ticket Header, if multiple choices are selected, will appear as value1, value2
(as it should). In the Queue Column, if multiple choices are selected, will appear as value1, value2
(as it should). Lastly in the Ticket Exports, if multiple choices are selected, will appear as value1, value2
(as it should).
Obviously, if one choice is selected it will behave the same way as above only with one value.
TLDR; We do return something worth gluing together 😁
Cheers.
Story: Customer complains about the CSV export of ticket data and the missing selection field values. The data was there before but got lost for the recent weeks. No clue, why the data got messy somehow along the way. The columns had 0 values instead of "key,value" glued strings.
Took me a longer time got to get into the matter. The ticket_cdata table gets deleted as soon as one changes the form records / form definition. It then gets recreated and filled as whatever place you may touch of the osTicket application. The values then get filled in correctly(copies of form_entry_values table). So the messy data just started the last time the form got updated. The ticket::create does not fill the cdata columns correctly for selection but enters the "0" values only.
PR
5375
This may relate with #4071 - but I doubt it is fixed there.
Comments: