Search
Write a publication
Pull to refresh
19
0
Олег Матасов @MatasDragonV

Bitrix24/PHP Teamlead

Send message

Решение тоже имеет право на жизнь то тогда нужно как-то давать доступ к этому логу тестировщикам (а это уже отдельный вопрос), плюс в логе трудно понять корректно ли выглядит письмо в клиенте. То есть чтобы такую же схему реализовать через custom_mail нужно еще заморачиваться с GUI для вывода этих сообщений в том виде как они будут отображены реальному пользователю.
А тут по сути получаем "из коробки" эмулятор почтового клиента прямо в браузере без отправки сообщений куда-либо.

Это неплохой, но все таки внешний сервис. Целью статьи было разобрать решение, которое ставится прямо на текущий сервер и не делает запросов наружу.

В ситуации когда и браузер и система выпущены одной компанией, не думаю что ответ на данный вопрос принципиально меняет ситуацию.

Тоже вариант, но работать будет только в Teams. Возможно кому-то подойдет больше в силу сложности реализации для неподготовленного пользователя описанного мной варианта. Мой вариант переключает для всех приложений Office.

В первую очередь тем, что "решает за меня", где я должен открывать ссылки.

Тут скорее дело не в SOLID а в стремлении MS продвинуть свой недобраузер любыми доступными методами, вплоть до конфронтации с пользователями своих продуктов. Аналогия - например если бы, MS выпустила свой мобильный телефон - а при попытке отправить обычную SMS отправляла бы сообщение в Teams например. При этом туда же отправляла бы все USSD запросы, например проверку баланса. Зачем вам SMS - это прошлый век, мы знаем что вам нужно отправлять через Teams, мы большие и богатые, а значит умнее вас и вы должны нас слушать беспрекословно :)
Разработчики у MS то может и "исповедуют" SOLID, но вот приходит дефективный "эффективный" менеджер и стучит по столу - "или даете мне охват установок такой-то, или идете искать новую работу". Исполнителям такой задачи как правило сугубо плевать на SOLID и лояльность пользователей. Им сказали повысить охваты - они сделали.

Да, с поиском по кнопке "Пуск" отдельный квест. Мой способ работает именно на приложениях Office365.

Для почтового клиента все просто - их огромное количество на выбор. А вот с мессенджером сложнее - Teams такой один и альтернатив нет. А если он принят за стандарт на работе и все им пользуются - либо лазить в политиках и делать как удобно, либо мыши плакали, кололись...

Яндекс браузер частно ставится "заодно" с другими программами. Стоит внимательно проверять пункт "Дополнительно" в установщике. Также может называться в духе "Установить дополнительные рекомендуемые возможности". Я от него всегда отказываюсь.

Нет, там было указано "Microsoft Edge". Мне нужно было чтобы открывалось в Я.Браузере где мои настройки и набор нужных мне аддонов (тут можно подставить любой браузер, на вкус, цвет, породу и длину шерсти). На скриншоте результат когда я сменил и заработало.

Честно при поиске решения для статьи крутились в голове подобные мысли. Но скорее в сторону заменить экзешник эджа своим, который запустит нужные браузер и передаст ему ссылку. Грохнуть полностью - не выход - будут окошки с ошибками.

Нет никакого старого api при работе со смарт-процессами, есть низкоуровневое api (использование datamanager). Есть старое API по работе со сделками/контактами/компаниями/лидами и новое api для crm. Не надо путать одно и другое.
Ну так по вашим прошлым выражениям новое апи же экспериментальное и его использовать ой как плохо. Сами себе противоречите.

Вы в вашей статье подаете метод $class::update как единственный способ по обновлению нескольких полей за одну операцию - это ошибка. Нет, если бы вы рассказали про обновление нескольких полей через массив используя compatible-функцию вопросов бы не было, но вы полезли в низкоуровневый update.

Я нигде не указывал что это "единственный способ". Про "единственный правильный способ" писали только вы. Не нужно смешивать ваши домыслы и убеждения с моими.
Вы не написали в статье что рассматриваете все способы (ни одного слова), но вы явно написали что рассматриваете "Базовые операции" - в заголовке статьи. Низкоуровневый update я никак не могут называть "базовым" методом. Отсюда считаю что это - ошибка.

В моем понимании базовые операции - операции позволяющие производить базовые действия с элементами Смарт-процессов. А это создание, изменение и удаление. Без учета связей с другими элементами. То что вы закладываете в понятие "базовый" какой-то дополнительный сакральный смысл - ваше личное дело.
Я не могу расценить эту статью за нанесение пользы, ведь после нее будут еще люди которые пойдут в техническую поддержку, на форум, в чаты по битрикс24 с невнятным описанием "битрикс г...но потому что не ищется".

Если вы на подобной операции обожглись и "получили нагоняй" от заказчика или работодателя, это также ваши личные проблемы. И винить статью в них по моему излишне.

Плохо ли, что элемент обновляется, а связи нет? Нет, это не плохо.Но подавать это как "базовый метод", не написав про ограничения и последствия что будет после этого - это плохо.

Посмотрите пожалуйста в толковом словаре смысл слова "базовый". Все встанет на свои места.

Если честно - ваша статья больше похоже на "мне сказали написать, ну вот и написал" или "напишу что бы было". Мне не нужен пиар - кто захочет что-то найти по битриксу и так меня найдет. Здесь я выступаю в качестве noname с одной единственной целью - если вы хотите доносить реальные знания и наносить пользу сообществу разработчиков Битрикс24 - вы должны по крайней мере не наносить вред.

Вред статья не наносит так как грамотный разработчик не копипастит бездумно решения, указанные в первом попавшемся туториале, а как минимум пытается разобраться в их работе запуская на тестовой среде и наблюдая за тем что сработало а что нет. А то что "битрикс г..но" особо "интеллектуально богатые" как писали так и будут писать независимо от наличия или отсутствия статей.

Если вкратце, хотели блеснуть умом, блеснули, вот только с каждым новым сообщением закапываете себя больше. Далее в данных дебатах участвовать смысла не вижу, все равно каждый из нас останется при своем мнении. Не хворать вам!

Спасибо за развернутый ответ. Я никого никакими ядрами не упрекаю. Вы сами упрекнули меня что:

В настоящий момент времени фабрики для старых сущностей (Лид, Сделка, Контакт, Компания) работают в экспериментальном режиме и не смотря на то, что на текущий момент существует возможность работать с ними через фабрики, обратиться в техподдержку с ошибками по такой работе вряд ли получиться.

Потому подобный ответ и получили. И далее:
Но писать статью где показывать плохие подходы, а потом не говорить что они плохие, ссылаться на "разработчик должен ... дойти сам" и тут же говорить про "начинающего разработчика" (в рамках образовательного курса), заявлять заведомо ложную информацию (про бесконечное количество) - это НЕ ок.

Про не бесконечное количество, убедили, подкорректировал статью, спасибо. Но в дальнейших ваших выкладках в рамках темы и назначения статьи никакого смысла не вижу. В статье разбирались возможные способы оперирования смарт-процессами. И опять же если перейти в сухой остаток вашего разбора, он сводится к тому что:

  1. При выполнении обновления не будут пересчитаны права. Если менялся ответственный, то новый ответственный при определенных обстоятельствах не увидит элемента.

  2. Не будут запущены бизнес-процессы и автоматизации, а значит часть бизнес-логики может не отработать

  3. Не будут выполнены действия по операциям, а значит часть клиентской заложенной битриксом логики останется за бортом.

  4. Не будут провалидированы системные поля, а значит ничего не помешает вам записать неконсистентные данные (например направление одно, а статус от другого или поменять birthday sort в обход birthday).

  5. Элемент не будет проиндексирован

  6. Продолжать можно еще долго...

Я уже указывал выше что в статье мы разбираем все способы оперирования элементами без оглядки на внешние действия. Это мини туториал который позволит в качестве быстрого старта работать с элементами, а не подробная статья "Полное API Смарт-процессов". И поэтому показываю все способы, в том числе "неправильные" по вашему мнению. Хотя на мой взгляд в любой разработке нет понятия "неправильно", есть "оптимально" и "не оптимально". А "неправильно" - код в ядре править. Так как применение любых методов имеет как достоинства так и недостатки.

Причем сами же это указываете:

 так почему вместо того чтобы хорошо рассмотреть один единственный способ работы с смарт-процессами (работу через операции) вы показываете несколько способов которые изначально имеют ограничения

потому и указываю несколько потому что они существуют и про них нужно упомянуть.

Также про ваши доводы

 на текущий момент ORM для инфоблоков не покрывает всех возможностей которые предоставляют старые методы и об этом пишут в документации

для описанных случаев имеют место быть. Но мне очень интересно как вы будете работать со Смарт-процессами через старое АПИ. Не приведете пример? И как вообще описанные случаи относятся к теме статьи (Смарт-процессы). Честно больше похоже на самопиар чем на аргументацию, но в этом плане Хабр вам судья).

4 Абзаца про экспериментальность и D7 вообще никакого отношения к статье не имеют, показали что матчасть знаете, молодец, вот только с какой целью, непонятно. Как уже указал выше, вы сами меня упрекнули в использовании экспериментальных методов.

В общем из нескольких абзацев вашего текста суть можно ужать:
1) Процессов может быть на текущий момент 64 - я с этим согласен. Но это НА ТЕКУЩИЙ МОМЕНТ. И по НЕОФИЦИАЛЬНОЙ информации. Что будет завтра никто не знает. За замечание благодарю.
2) Про удаление - также благодарю, механическая ошибка.
3) А вот то что элемент обновляется а связи нет и это ой боже как плохо. Это спорно и то что это "плохо" - я не согласен. Не оптимально - да, чтобы все связи обновились нужно дополнительные приседания делать - да. Но это не "неправильно".

Спасибо за вашу обратную связь к статье. С последним доводом про код в операции соглашусь, механическая ошибка.
Но остальные доводы выданные как "ошибки", ошибками можно назвать субъективно и с очень большой натяжкой.

"Неограниченное количество" на момент написания комментария составляет 64 смарт-процесса и не больше.

Просьба предоставить ссылку на официальную документацию либо код ядра системы, устанавливающий данное ограничение.

В настоящий момент времени фабрики для старых сущностей (Лид, Сделка, Контакт, Компания) работают в экспериментальном режиме и не смотря на то, что на текущий момент существует возможность работать с ними через фабрики, обратиться в техподдержку с ошибками по такой работе вряд ли получиться.

В экспериментальном режиме но работает. С тем же успехом некоторое время назад были "окрики" что D7 это экспериментальный режим и писать про него не стоит - используйте CIBlockElement::GetList и будет вам счастье :). Цель статьи - дать начинающему разработчику базовое понимание инструментов. Поэтому намеренно разобраны разные способы. А уже что запускает процессы а что не запускает, разработчик должен либо дойти сам, либо получить эти знания на соответствующих курсах. Если описывать в рамках обзорной статьи все эти нюансы, обработки результатов, каик-то еще "навесы" и взаимосвязи - она превратится в "Войну и Мир". Так что на мой взгляд замечание сильно субъективное.

Нет, не приобретает и так как вы делаете вообще делать не стоит. Ваш код будет выглядеть например так

Я считаю, что когда критикую чей-то подход, должен дать максимально развернутый и аргументированный ответ почему так "вообще не стоит делать". Видимо у вас подход другой. Жаль. К сожалению на необоснованную аргументами критику мне ответить нечем)

Смотря что вы вкладываете в понятие кастомизировать.

Все верно. Это ваше личное мнение а не ошибка. По факту даже изменение пользователя это уже влияние на процесс сохранения. Остальные подходы именно в рамках статьи разбирать не планировалось, опять же чтобы не превращать ее в "Войну и Мир".

Нормально бронировал и поймал блок. Думал из-за паспорта. Написал в техподдержку мол "я не в указанных вами странах нахожусь, это расизм и сегрегация и т.п.". И получил очень интересные ответы.
Оказалось у них работает так - если НА ЛЮБОМ АККАУНТЕ (хоть даже зарегистрированном в Казахстане, Германии, США) отметился вход из Российского или белорусского сегмента Интернета - в сессии ставится блок и чтобы его убрать - нужно дождаться сброса сессии. Для этого нужно выйти из аккаунта НА ВСЕХ УСТРОЙСТВАХ, подождать 24 часа, далее снова зайти НАХОДЯСЬ В ЛЮБОЙ СТРАНЕ кроме РФ и Белоруссии и не используя ВПН (именно напрямую с провайдера другой страны). После этого возможность бронирования вернется. А я как раз использовал российский впн чтобы зайти в интернет банкинг и забыл его выключить. А на паспорт им я так понял фиолетово. Решает именно геолокация.

Инфа про депозит получена в отделении? Кажется мне если на сайте про это ничего нет - менеджер просто хочет дополнительно продать депозитный продукт и получить галочку в KPI, обманывая про обязательность. Турки поступают аналогично абсолютно. Если влом ложить депозит - можно просто поехать не в Минск а в какой нибудь другой город куда ездит мало русских, и попробовать в отделении этого города. Возможно там и депозиты резко перестанут быть нужны. Ну а за инфу спасибо, обновлю статью. Также касательно процента за снятие наличных - он насколько я помню берётся при снятии валюты нерезидентами на территории Беларуси. Так противодействуют массовой покупке наличной валюты гражданами РФ перед поездками за рубеж. В других странах берется стандартная комиссия ПС.

Жестко. Видимо обратно не судьба. Да и прочитал отзывы тех кто ездил с поборами на трассах как то негативно все описано про Азербайджан - в духе:
1) Заплати "взятку" на таможне чтобы тебя быстрее оформили, либо будут специально тянуть время специально от 1 часа до бесконечности, а зависимости от степени отсутствия совести у пограничника
2) Заплати "взятку" при оформлении страховки чтобы тебя быстрее оформили, либо будут также тянуть время а на вопросы "Когда?" отвечать типа "Жди, ты тут не один", при этом попивая чай и выходя покурить каждые 5 минут.
3) Заплати местному ГИБДД просто за то что ты едешь по дороге - "мы видели что ты автобус подрезал", при этом никаких данных фото видео фиксации естесственно не покажут.
Не знаю правда или нет, комрады кто часто ездит через Азербайджан - просьба внести ясность. Но если это так - могу точно сказать что при таких вводных Россия это оплот неукоснительного соблюдения гражданских прав и законов по сравнению с таким бардаком и откровенным вымогательством на всех уровнях, но опять же суждение оценочное, сформировано на основе опубликованных мнений в других блогах. Возможно все сообщения на основе которых я составил такую "картинку", просто провокация и это не имеет общего с действительностью.
Но желание как-то пропало. "Осадочек то остался"

Например Минтруд вообще-то запрещает заключать такие трудовые договоры, вот официальные письма - ответы:
https://www.moedelo.org/Pro/View/Legals/97-425971846882?referer=Search&query=07.08.2015 № 17–3%2FВ-410 &position=0&_companyId=8904805?utm_source=klerk&utm_medium=referral&utm_campaign=article&utm_content=blogs-moedelo-06062022
https://www.moedelo.org/Pro/View/Legals/97-425971992177?referer=Search&query=от 16.01.2017 № 14–2%2FООГ-245&position=0&_companyId=8904805?utm_source=klerk&utm_medium=referral&utm_campaign=article&utm_content=blogs-moedelo-06062022
Позиция Минтруда - работодатель не будет иметь возможность обеспечить безопасные условия труда в этом случае. Минтруд рекомендует в таких случаях заключать договоры ГПХ.
Но при этом в ТК прямого запрета нет. То есть договор заключить вроде как можно, но уже назревает перспектива постоянного "бодания" с Трудовой Инспекцией при каждой проверке. Можно конечно сослаться на судебную практику, например на АС Северо-Кавказского округа https://sudact.ru/arbitral/doc/56lCPfip8zZm/, но факт в том что это уже дополнительный гемор который вызван одним ну или двумя уехавшими сотрудниками.
Далее если другая страна вписана как "место работы", нужно позаботиться о переводе заработной платы за рубеж. И если расчетный счет открыт в банке, попавшем под санкции начинается еще один гемор - открытие счета в неподсанкционном банке, отправка зарплаты через swift (причем комиссии за swift, которые сейчас выросли в "космос", оплачивает работодатель).
А перейти на ГПХ не каждый сотрудник согласится, зная его "подводные" камни.

Да, но ни один работодатель не пропишет у себя в трудовом договоре другую страну как место исполнения обязанностей, так как там у сотрудника все ок а гемор образуется уже у работодателя. А даже если и пропишет, получается за эти доходы нужно платить налоги в Турции, а налоги там выше чем в РФ, как раз указанные 30% насколько я помню. Так что на мой взгляд "овчинка выделки" не стоит.

1

Information

Rating
3,294-th
Location
Клин, Москва и Московская обл., Россия
Date of birth
Registered
Activity