создание свойства доступных параметров

[rnpoddor]

При попытке изменения значения параметра Цвет уплотнения в аксессуарах и услухах, падает на строчке

filter.ref && mf.choice_params.push({

по причине отсутствия массива choice_params в mf. С данным изменением работает как надо. Массив создаю в данном месте, потому что здесь присутствует проверка на его существование.

[rnpoddor]

Теперь PR решает обе проблемы, описанные в обсуждении 636.

[unpete]

по cat_inserts.js: отсутствие в метаданных параметров выбора - моя халатность. По-хорошему, mf должен быть не плоским объектом, а экземпляром класса МетаданныеПоля. Править такое конкретно для вставок, было бы ошибкой. Нужно обходить или по месту - там, где поймали ошибку или в ядре, чтобы choice_params, choice_links, mandatory и прочие свойства метаданных всегда были на своих местах

[unpete]

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

Правку "проблемы №1" сейчас сделаю по месту. Если по "проблеме №2" я написал бред не разобравшись, опишите подробнее с учетом "У всех вставок одной группы должен быть одинаковый состав параметров". Количеством групп, вроде у вас есть возможность управлять. Никто не запрещает сделать группы "профиль с цветом уплотнения" и "профиль без цвета уплотнения", но лучше - настроить вставки, чтобы лишние параметры не портили спецификацию.

[rnpoddor]

Количеством групп, вроде у вас есть возможность управлять.

Искал, где можно управлять группами, пока не нашел. Из кода видно, добавочные группы additions_groups берутся из типов вставок $p.enm.inserts_types. В 1С типы подгружаются из Перечисление.ТипыВставок. Как из конфигурации этим управлять?

[unpete]

Как из конфигурации этим управлять

Тема обширная и философская. Мы смотрим на метаданные, как на разновидность данных. Значит, их можно модифицировать в runtime. Прошу не воспринимать мои слова, как совет, но вы можете добавить или удалить элементы из $p.enm.inserts_types. Как правкой 1С (так делают ТМК), так и кодом при старте приложения.

Правильным по моей шкале решением было бы выкинуть 80% параметров и сократить состав групп.

[rnpoddor]

По так называемой "проблеме №2", было принято архитектурное решение: "У всех вставок одной группы должен быть одинаковый состав параметров"

Если бы это архитектурное решение полностью соответствовало тому что Вы описали, метод tune класса ItemRow модуля cat_inserts.js, скорее всего не содержал следующий код

// если параметр не используется в текущей вставке, делаем ячейку readonly
const prms = new Set();
inset.used_params.forEach((param) => {
  !param.is_calculated && prms.add(param);
});
inset.specification.forEach(({nom}) => {
  if(nom){
    const {used_params} = nom;
    used_params && used_params.forEach((param) => {
      !param.is_calculated && prms.add(param);
    });
  }
});
mf.read_only = !prms.has(prm);

в котором, параметры не принадлежащие вставке, устанавливаются в режим только чтение. Эту фильтрацию я с чистой совестью скопировал и применил на этапе передачи параметров в характеристику.

Если это не устраивает, надо возвращаться к обсуждению задачи, а не вставлять код в первое понравившееся место.

Если бы это архитектурное решение, не было применено, разве место, в которое был добавлен код, не является правильным? Организую фильтрацию параметров, перед добавлением в характеристику.

[unpete]

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

[rnpoddor]

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

[unpete]

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

Если бы назвали задачу "лишние параметры в характеристике аксессуаров" или "фильтровать параметры при добавлении" или "исключить неиспользуемые параметры", взаимопонимание возникло бы на 3 дня раньше.

Правки учту сегодня.

[unpete]

dev обновил, лишние параметры должны перестать добавляться.

[rnpoddor]

Ошибка с нулевой характеристикой, аналогичная, что и в 424. Заказ в dev 00-579-0060, ошибка проявляется при изменении параметра Цвет уплотнения в Аксессуары и услуги у профилей.