плюс было бы круто видеть при обновлении, что же поменялось в системных формулах нормализации - это сильно сократило бы угадайку на тему того, что из пользовательского контента в этом месте отъехало

Это можно через историю глянуть

чтобы по id в правиле тянулись изменения при обновлении вендорского контента

Но как? вот в примере, с которогов се началось, изменяется прямо шаблон TEXT=.'..' + немного код нормализации
Потом вендор опять же меняет шаблон и код нормализации.
С большой вероятностью все равно получим конфликт и необходимость ручного мержа

PS. Я понимаю, что лучше - можно. Мне интерсно, как это "лучше" выглядит со стороны тех, кто контент пишет.

Ну приведу пример как мы столнулись с офигенным факапом в 19 версии на SecretNet - там забыли что винда может быть внезапно на русском языке. Пофиг, правила переписали, ID изменили установили. Пришла 21 версия - там исправлено. Отключили переписанные правила и сразу получили "у нас события не идут от sns" ибо заказчик нужные собюытия дергал по id

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

так может отучать дергать события по id? Они, в общем случае, и в апстриме могут поменяться.

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

там люди на cs по сиему еле по 30% на тесте набирали. Им "попроще", а не как надо

Конечные эксплуатанты вообще обучение не проходили

Ситуация понятна, да. Но все ж можно палвно наставлять на путь истинный )

"Нам некогда, лучше сами сделайте так чтобы работало как мы хотим, но еще не знаем чего хотим"

Чет уволиться захотелось и к заказчику какому-нибудь пойти... >_<

/me вспомнил интеграторские будни и уронил скупую слезу

О. Солар сиемовца ищет...

ФНС вообще человека чисто под mpsiem ищет

Не кажется. Если есть пользовательские правила обогащения такой подход не сработает (точнее, не факт, что сработает)

В тему с баша:
Виталий > А можно глупый вопрос?
Алёна > Добрый день. Не говорите, что вопрос глупый. Слушаю
Виталий > Почему в программах, написанных российскими разработчиками, ОК, а не Хорошо, или Ладушки, или Добро.....?)
Виталий > Он глупый)))
Алёна > секунду. сейчас проржусь )))
Алёна > потому что в основном ПО, написанное русскими разработчиками, несовместимо со словами "Хорошо или Добро". "Ладушки" вызовут ненужную ассоциацию со словом Оладушки, и с большой вероятностью пользователь пойдет пожрать, а не поработать. Так что не катит.
Сейчас мы подразумеваем "ОК" как "Я не хочу в этом работать, но у меня нет выбора". Если уж мы говорим об импортозамещении, то логичнее было бы использовать вместо ОК кнопку "Ну наконец-то". Однако текст длинный, в кнопку может не влезть, поэтому просто ОК.