А если через правила сделать фото невидимым?

Григорий Чех,

Допустим, и что дальше?

В карточке редактирования реализован определенный механизм отображения картинки, в котором в любом случае нужно указать this.primaryImageColumnName.

В init

this.callParent(arguments);

this.set(this.primaryImageColumnName, null);

Григорий Чех,

Не уверенна, что так заработает, но можно попробовать.

Григорий Чех,

Хотелось бы по данному вопросу услышать комментарий службы поддержки!

Можно попробовать заместить модуль, в котором описана данная логика 

init: function() {

       this.primaryImageColumnName = "ContactPhoto";                                               this.on("change:OrgStructureUnit",this.onChangedOrgStructureUnit, this);

       this.callParent(arguments);

    }

Переписав тот же самый код (без первой строки), а в наследниках уже дополнить метод под каждую карточку отдельно

Колодяжный Владислав Эдуардович,

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

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

Весь вопрос в том, что метод реализован некорректно и, если бы код в 1-й и 2-й строчке метода init был вынесен в другую функцию, то никаких бы сложностей не возникло.

Мне нужно было бы всего-то переопределить эту функцию и все.

но смысл тогда в базовых разделах, особенно, таком, как сотрудники.

Смысл, внезапно, в ведении информации о сотрудниках.

Весь вопрос в том, что метод реализован некорректно

Метод реализован корректно. Фото выводится.

По поводу обнуления после вызова this.callParent(arguments), то в странице SysProcessUserTaskPage есть такое обнуление:

onImageChange: function(image) {
    if (!image) {
        this.set(this.primaryImageColumnName, null);
        return;
    }

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

Зверев Александр пишет:

Смысл, внезапно, в ведении информации о сотрудниках.

Я имела ввиду другой смысл использования базовых разделов: зачем изобретать велосипед, если его уже изобрели до меня.

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

Зверев Александр пишет:

Метод реализован корректно. Фото выводится.

Да, этот метод рабочий - фото выводится. Можно сказать с этой точки зрения, что он реализован корректно, но вот с точки зрения последующей работы с ним, как показала практика, совсем некорректно.

Зверев Александр пишет:

Но доработанную логику нужно тестировать.

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

Я немного в шоке. Вместо пары строк кода вы развели вайн на пару страниц.

init: function(callback, scope) {
	//сначала вызовутся родительские init-методы
	this.callParent([function() {
		debugger;
		//тут можно занулить this.primaryImageColumnName
		callback.call(scope);
	}, this]);
}

Зверев Александр,

Это всё замечательно, но вот ситуация: я захотел заместить в одной схеме ViewModel. Модули (внезапно!) с 7.13 замещать нельзя. Ну ок, делаем свой через extend. Лезем в схему, а там прямо в init зашита сторчка а-ля:

this.viewModelName = '123'; this.callParent(arguments);

Ну клёво теперь. И как в таком случае менять что-либо? (принимая во внимание, что 95% пользователей не знают о коде выше). Делать сначала callParent, а потом простановку своего viewModelName — бред. Привет асинхронность, непонятно какое присвоение выполнится первее. Таймауты/деферы - костыль. Так-то вынести всю кастомную логику из init  в отдельную функцию - правильнее будет. 

PS. Пользуясь случаем - какой гений догадался запретить перегруз модулей?

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

Варфоломеев Данила пишет:

Так-то вынести всю кастомную логику из init  в отдельную функцию - правильнее будет

Так вот об этом же и речь, что нужно не только реализовать "шоб работало", но и так, чтобы потом с этим другие могли работать! 

Тут палка о двух концах. Если вообще всё выносить в отдельные функции, в ожидании, что кто-то захочет их переопределить, то сам код станет более громоздким и хуже читаемым. Хотя и более структурируемым. Видимо, при создании этой функции не предполагалась потребность в смене поля с картинкой.

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