|
|
Thank you for your message. The problem is that in order to detect whether there is a bug to fix and if so, to fix it, we would need to know how to reproduce it, the exact steps to reproduce it. At this point we only know that your process crashes at application/views/admin/token/attribute_subviews/tokenformAttributesWrapper.php due to not having a type field at
switch ($attrDescription['type']) {
case 'DD':
// Drop down
$this->renderPartial(
'/admin/token/attribute_subviews/tokenformSelect',
[
'attrDescription' => $attrDescription,
'attrName' => $attrName,
'inputValue' => $inputValue,
'batchEdit' => $batchEdit,
]
);
break;
case 'DP':
// Date
$this->renderPartial(
'/admin/token/attribute_subviews/tokenformDateInput',
[
'attrDescription' => $attrDescription,
'attrName' => $attrName,
'inputValue' => $inputValue,
'jsDate' => $jsDate,
'batchEdit' => $batchEdit,
]
);
break;
default:
// Text
$this->renderPartial(
'/admin/token/attribute_subviews/tokenformTextInput',
[
'attrDescription' => $attrDescription,
'attrName' => $attrName,
'inputValue' => $inputValue,
'batchEdit' => $batchEdit,
]
);
break;
}
This value is being stored in your {{participant_attribute_names}} table in a field called attribute_type and we know for a fact that some of your tokens have no values there.
Possible reasons:
- Maybe the field is missing
If so, you'll need to create that field, you can inspire from this table definition (in MariaDB/MySQL):
CREATE TABLE `lime_participant_attribute_names` (
`attribute_id` int(11) NOT NULL AUTO_INCREMENT,
`attribute_type` varchar(4) COLLATE utf8mb4_unicode_ci NOT NULL,
`defaultname` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`visible` varchar(5) COLLATE utf8mb4_unicode_ci NOT NULL,
`encrypted` varchar(5) COLLATE utf8mb4_unicode_ci NOT NULL,
`core_attribute` varchar(5) COLLATE utf8mb4_unicode_ci NOT NULL,
PRIMARY KEY (`attribute_id`,`attribute_type`),
KEY `lime_idx_participant_attribute_names` (`attribute_id`,`attribute_type`)
) ENGINE=MyISAM AUTO_INCREMENT=14 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
and then run
update {{participant_attribute_names}} set attribute_type = 'TB' where attribute_type is null;
- You may have broken data
In this case the field exists for you, but some records have null as a value. If so, you can run the update command shared in the previous point
-
There could be some bug otherwise. If so, we'll need exact steps on how a thusly broken survey is to be created.
A symptomatic treatment of the problem would be to change the switch case I shared to
switch ($attrDescription['type'] ?? '') {
case 'DD':
// Drop down
$this->renderPartial(
'/admin/token/attribute_subviews/tokenformSelect',
[
'attrDescription' => $attrDescription,
'attrName' => $attrName,
'inputValue' => $inputValue,
'batchEdit' => $batchEdit,
]
);
break;
case 'DP':
// Date
$this->renderPartial(
'/admin/token/attribute_subviews/tokenformDateInput',
[
'attrDescription' => $attrDescription,
'attrName' => $attrName,
'inputValue' => $inputValue,
'jsDate' => $jsDate,
'batchEdit' => $batchEdit,
]
);
break;
default:
// Text
$this->renderPartial(
'/admin/token/attribute_subviews/tokenformTextInput',
[
'attrDescription' => $attrDescription,
'attrName' => $attrName,
'inputValue' => $inputValue,
'batchEdit' => $batchEdit,
]
);
break;
}
so it will infer a text type. However, at this point it's unclear why you ended up with an empty type and that needs to be figured out so your future attributes will not have this problem. As about your current attributes, you can just update the attribute_type to the appropriate value. If there are no other missing/broken elements in your attributes, then this update should fix the issue. |
