Форум

[QUOTE] написал:
А с чего вы решили что сохранение в куки ip адреса является персональными данными? Сейчас ото всюду это прет, но толком никто не может сказать четкой какой-то позиции - "Потому что я слышал..." И начинается паника.[/QUOTE]
Когда в законе четко не прописано, что считать персональными данными, решающими факторами являются:
а) прецеденты
б) распоряжения/разъяснения регулятора
в) тараканы в голове конкретного человека, занимающего конкретную должность в данный конкретный момент времени
г) убежденность судьи в том, что государство всегда право, даже в тех случаях, когда закон ясно и однозначно говорит об обратном.
Ссылки, к сожалению, не сохранил, извините, времени на их повторный поиск нет, потому что да, слишком много в сети мнений Васей Пупкиных, их перебирать заново, чтобы найти среди них нужное долго.
По последнему пункту же - ради интереса попробовал судиться с государством, специально для того, чтобы поиметь опыт. Не напрасно - все понял.
Поэтому, резюмируя - моя позиция - если можно пройти под радарами, исключить шанс попадания в рандомную выборку пьяного пулеметчика, то в первую очередь надо делать это. Есть возможность не попадать в поле зрения Роскомнадзора, не быть в его списках - надо ей в первую очередь пользоваться.
Есть сайты, где можно обойтись вообще без кук - ну и не надо их там использовать, а лучше еще и прописать явно, что сайт НЕ использует куки. Если на слуху куки, но не на слуху, например, LocalStorage, который можно использовать абсолютно для тех же целей - попробовать использовать его.

Есть ли какой-то более-менее простой способ отключить все куки у сайта на Битриксе?
Файлы куки могут толковаться как персональные данные, соответственно, владелец сайта в РФ кроме размещения плашки согласия должен еще и зарегистрироваться на сайте Роскомнадзора. То, что за это пока не штрафуют - временная недоработка, руки не дошли. Хотелось бы отключить их везде, где они не нужны.
Смотрел на маркетплейсе, есть одно якобы решение, но на их демке выбираю не использовать куки на плашке, потом набираю в консоли document.cookie - вуаля, все куки на месте. Перезагружаю страницу, никуда не делись, только добавились новые от модуля.
Лирическое отступление.
Вообще, конечно, согласно этому закону все протоколы http, tcp/ip и т.п. получаются вне закона в РФ, не должны использоваться. Ведь каждый раз, например, открывая страницу сайта, в общем случае на сервер отправляется IP адрес клиента (куда отправить ответ), а он тоже является персональными данными. Пусть даже потом пользователь согласился на сбор и обработку персональных данных, но ведь серверное ПО получило, сохранило и обработало IP адрес ДО его согласия, т.е. БЕЗ его согласия, что является нарушением закона.

/bitrix/templates/main/assets/js/script.js
в function calcRepair(select) задается цена за кв метр для каждого варианта набора радиобатонов, в ней function getCalc() считает сумму простым умножением цены за метр на кол-во кв метров.

[QUOTE] написал:
где находится код обработчика отмены заказа?[/QUOTE]
обработчики событий ищутся так, например, для  OnSaleOrderCanceled[CODE]print_r(\Bitrix\Main\EventManager::getInstance()->findEventHandlers("sale", "OnSaleOrderCanceled"));[/CODE]
и получаем, что вот, например, здесь [URL=https://doc.budagov.ru/product2product_8php_source.html]product2product.php[/URL] строка [URL=https://doc.budagov.ru/product2product_8php_source.html#l00537]537[/URL] есть обработчик этого события.
Но, подозреваю, это не то, что вам нужно, судя по контексту вопроса, т.к. к почтовым событиям эти обработчики не имеют отношения. Если вам нужно ловить отправку почтового сообщения об отмене заказа, то пишите обработчик на OnBeforeEventAdd, и проверяйте тип SALE_ORDER_CANCEL.

Делаете свою службу доставки, прописываете в хэндлере правила расчета стоимости и не надо ничего кастомизировать.

[URL=https://dev.1c-bitrix.ru/api_d7/bitrix/main/userfield/introduction.php]https://dev.1c-bitrix.ru/api_d7/bitrix/main/userfield/introduction.php[/URL]
мутновато написано, но, так понимаю, если хотите использовать шаблоны system.field.edit по-старинке, то перед вызовом присвойте
$arUserField['USER_TYPE']['USE_FIELD_COMPONENT']=false.
Если нет, то копайте шаблоны компонента main.field.boolean исходя из этого [URL=https://dev.1c-bitrix.ru/api_d7/bitrix/main/userfield/uf-fieldcomponent.php]https://dev.1c-bitrix.ru/api_d7/bitrix/main/userfield/uf-fieldcomponent.php[/URL]

[QUOTE] написал:
Надо смотреть на существующий функционал[/QUOTE]
и его реализацию, потому что иногда бывает под капотом такое, что да, это отличный повод убедить клиента переписать все заново с нуля. Вспомнился один кейс - официальный сайт банка (!), там на бэке такое, что испанский стыд - как будто заглянул в грязное и вонючее чужое исподнее. Многоэтажная конструкция из навоза и палок, как она до сих пор не упала - загадка. Просто так убедить клиента переписать заново весь сайт - без шансов, нужен формальный повод.

[QUOTE] написал:
а вы видели хоть один шаблон их авторства?[/QUOTE]
не помню, много через меня прошло шаблонных сайтов, наверняка и акрит был, не последний вроде игрок на этом рынке. У всех в той или иной степени одна и та же проблема - миллион собственных классов и компонентов, недокументированных и часто обфусцированных. Или их шаблоны чем-то принципиально отличаются?
Собственно, ссылка в вашей подписи навеяла - размышлял, какое же тайное знание я упускаю, которое однозначно диктует такую стратегию - начать все с нуля. Потом подумал, что вы, возможно, под Бизнесом имеете в голове еще и готовый шаблон к нему прилагающийся. Надо смотреть на существующий функционал и хотелки клиента, возможно, в каких-то случаях такой подход и оправдан, но по дефолту думаю, что нет, это в большие разы трудоемче.
Возвращаясь к шаблонам и кулибиным - часто часть классов/методов зачем-то дублируют штатный функционал. Легаси, возможно, с  тех времен, когда штатного такого не было. Но как раз за таким кодом и  чудятся кулибины, которые считают, что их решения лучше, чем штатные. Возможно, они и правы иногда, но, если думать вперед, имея в виду дальнейшую эксплуатацию, то уж лучше ущербный штатный, зато документированный и поддерживаемый код. Потому что вот еще, кстати, да, одна из проблем с шаблонными сайтами - обновить бы, ан нет, разработчик сдулся и на маркетплейсе этого шаблона уже просто нет.

[QUOTE] написал:
это вообще ничего не изменит на сайте[/QUOTE]
собственно, этот вопрос ТС в первую очередь и волнует, ему и нужно, чтобы апгрейд ничего не изменил на сайте = ничего не затер. Тут мы сошлись во мнении, ничего не изменится, ок.
Сайт будет работать, прекрасно. А дальше я бы не стал сносить весь тот функционал, который уже на старте сидит, а спокойно надстривал параллельно торговый каталог и интернет-магазин. Если не покупать всякие монструозные готовые шаблоны у аспро, акрита и т.п., у которых надо их движок разобрать и собрать заново, чтобы кастомизировать какую-то мелочь (образно, чтобы заменить лампочку в фаре, нужно снять двигатель), а строить свою "товарную логику" на штатных компонентах и классах, то это нормальная рутинная работа.

Заинтригован. Переход на Бизнес = добавлению новых модулей. Те модули, которые есть, остаются. Как может добавление новых модулей повлиять на работу тех, которые есть. По-моему никак. Апгрейд на Бизнес не должен вообще никак не отразиться на том функционале, который сделан на Старте (подразумевая, что существующие костыли не модифицировали ядро).