Вылезала такая проблема:
При попытке сохранить название статуса заказа
получаем статус без названия:
И кстати такой вопрос , что будет с заказами у которых стоял статус, а статус допустим взяли и удалили?
И кстати такой вопрос , что будет с заказами у которых стоял статус, а статус допустим взяли и удалили?
Будет пустота:
1 лайк
Скорее всего отсутствует запись для этого статуса в таблице
cscart_ult_status_descriptions
или
cscart_status_descriptions
Эм… но это как то несколько не правильно же?
Так, а почему редактирование названия то при этом не помогает?
если статус есть - то записи не создаются, а обновляются. А так как записи нет - то и обновлять нечего
Вскрылась еще проблема, даже если удалить статусы, при попытке создать новые выдает :
Couldn’t create a new statusYou have reached the maximum number of statuses
В смысле нет? в списке статусов заказов - видно что нижняя строчка есть , но без названия
есть таблицы statuses и status_descriptions. Если есть запись для литеры Z в таблице statuses - статус будет выводиться. Но если нет записи в таблице status_descriptions (то есть там где хранятся названия для различных языков) для данной буквы - то соответственно в качестве названия нечего и выводить. Или например, если язык по умолчанию - английский, для литеры статуса есть запись на немецком. И нет записи на языке по умолчанию (английском), а вы выводите на русском - те нет ни русского для литеры ни языка по умолчанию - в этом случае кажется тоже ничего не выведется.
а вот это уже интересно ))
такое вылазит когда заканчиваются буквы для статуса , возможно остались хвосты в таблицах и система думает что статусы есть
Это я понял, но фишка в том, что часть статусов я удалил, а новые создавать не дает
Надо посмотреть в базе, есть ли записи. Потому что при попытке сохранить статус выполняется этот код:
if ($mode == 'update') {
$status_code = fn_update_status($_REQUEST['status'], $_REQUEST['status_data'], $_REQUEST['type']);
if (!$status_code) {
fn_set_notification('E', __('unable_to_create_status'), __('maximum_number_of_statuses_reached'));
}
}
в котором вызывается fn_update_status с выполнением
if (empty($status_data['status'])) {
// Generate new status code
$existing_codes = db_get_fields('SELECT status FROM ?:statuses WHERE type = ?s GROUP BY status', $type);
$existing_codes[] = 'N'; // STATUS_INCOMPLETED_ORDER
$existing_codes[] = 'T'; // STATUS_PARENT_ORDER
$codes = array_diff(range('A', 'Z'), $existing_codes);
$status_data['status'] = reset($codes);
} ...
$can_continue = !empty($status_data['status']);
// Create status to have its identifier
if ($can_continue
итд
то есть берется массив от A до Z, из него вырезаются все “status FROM ?:statuses” + N + T
после чего выдается первый оставшийся элемент массива.
В вашем случае массив $codes получается пустой.
Либо второй вариант, и тут чтобы найти причину, придется попотеть. Какой-то модуль может цепляться к хукам update_status_pre или update_status_post и обнулять возвращаемый из функции элемент $status_data[‘status’]
1 лайк
@skay Опишите пожалуйста кейс, когда все буквы использованы. И в какой версии воспроизводится проблема?
В будущем следуйте пожалуйста правилам данного раздела форума
Элементарно - бизнес-процессы, различные для разных типов покупателей, оплат и доставок + промежуточные статусы - в ряде случаев производственные этапы “Производится замер”, “Производится”, логистические - “Комплектуется”, “Доставляется”, несколько видов статусов в зависимости от типа доставки т.к. письма уведомлений завязаны на статусы(как и оплаты). Плюс статусы связанные с оплатой - помимо коробочных, связанные опять же как с бизнес-прцессами, так и являющихся необходимыми для обеспечивающих бизнес-логику модулей из маркетплейса - “Ожидает оплату”, “Предоплата поступила”. Плюс статусы отказных заказов “Нет в наличии”, “Отказ клиента”, “Не дозвонились”, “Отменен” - каждый не дублирует друг-друга, а имеет конкретные причины. В случае с мультивендором, есть разные типы вендоров, где так же требуются различные наборы статусов для вендоров(ограничение видимости не нужных для отдельно взятого вендора ограничивается доработками).
Так или иначе - коробочного числа стутусов не хватает ни в каком случае и приходится использовать модуль, расширяющих число возможных статусов. И не понятно - зачем, если можно сразу не создавать такую проблему.
Третья причина - посмотрите, банально, сколько в той же RetailCRM статусов в демо-магазине. И они не лишние - там показана ПРОСТАЯ логика для демо. Реальность часто заметно сложнее.
У меня два совершенно разных магазина на CS-Cart совершенно разных редакций. В обоих стандартного числа статусов не хватило(и не хватает их группировки по типам).
3 лайка