Здравствуйте.
В версии 7.2 отсутствует понятие версионности пакетов. Есть только понятие версия воркспейса. Это и есть поле Version в таблице SysPackage.
В версии 7.4 появилась версионность пакетов. За версию конкретного пакета отвечает поле RepositoryRevisionNumber. Если нужно работать с разными версиями разных пакетов, то необходимо выполнить обновление.

Спасибо за ответ, конечно печально, что такого функционала нет в версии 7.2.
А насколько проблемно обновиться до новой версии? Потребуется ли для этого что-то делать, или вся кастомизация будет работать? Т.е. обратная совместимость присутствует?

И сразу вопрос, а как эта версионность работает? Т.е. если была версия 1.0 на двух серверах, потом на них поменяли схему и выгрузили, то у пакетов версии поменяется на 1.1? И как потом их сравнить?

Здравствуйте.
Процедуру обновления сложно назвать простой. Структура конфигурации текущей версии радикальным образом отличается от версии 7.2 и, скорее всего, данные нужно будет переносить из базы в базу, а потом добавлять нужный функционал.
Что касается версионности, то ситуация выглядит так - версионность завязана на хранилище.
Если сервера настроены на одно приложение, то, при изменении схемы на одном из них и заливке измененного пакета в хранилище, при попытке изменения пакета на втором сервере, приложение попросит обновиться из хранилища.

Спасибо, значит переход на новую версию не светит.
Но вопрос, на будущее, получается при наличии хранилища, в случае попытки изменения пакета, сперва происходит проверка изменений в хранилище, этого пакета? Или происходит потом какой-то мерж?

Здравствуйте.
Сначала происходит проверка наличия изменений в хранилище. Если таковые есть, тогда Вам будет предложено синхронизироваться с хранилищем. До этого возможность внесения изменений будет заблокирована.

Ясно, спасибо

Ясно, спасибо

Нашли причину, оказывается в пакете были привязаны данные по этой таблице. Вопрос снимается.

Николай, к данному комментарию прикрепил файл с актуальной информацией по созданию справочника.

dvuhurovnevyyspravochnik.doc

Страшная и трудозатратная методика создания, и результат в старом интерфейсе у клиентов интерес вызывает всегда :)

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

Здравствуйте!

Ну можно создать раздел с деталью и скрыть его из всех рабочих мест. Чем Вам не двухуровневый справочник?:smile:

Всегда можно найти альтернативное решение.

"Демьяник Алексей Олегович" написал:Чем Вам не двухуровневый справочник?

"Александр Кудряшов" написал:
Демьяник Алексей Олегович пишет:

Чем Вам не двухуровневый справочник?

Вполне себе справочник, только объем работы все равно немаленький

Создание справочника будет более трудоемким.

"Александр Кудряшов" написал:Тому, кто осилит нормальный справочник двухуровневый в новом интерфейсе тут надо памятник в комьюнити прижизненный организовать или на доску почета на главную страницу разместить.

У меня программист делал, сам видел, что работало. Но нигде не зафиксировал, как....

Евгений, добрый день!

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

Присоединяю к данному сообщению исходный код этого решения и инструкцию по использованию.

Если я переношу страницу из версии 7.2 в 7.6 и среди её зависимостей есть JQueryInputMask, то его замена в 7.6 на ваше решение даст 100% гарантию, что страница будет работать правильно?

P.S. Кстати, вся кириллица, когда я открываю ваши вложения для просмотра переворачивается в каракули.

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

Хорошо, спасибо.

Евгений, пересохранил файлы в формате docx.

Спасибо.

Евгений, посмотрите пример в BaseDetailV2 пакета NUI. Там как раз используется коллекция в атрибутах, которая содержит строки реестра:

/**
 * Коллекция данных
 * @type {Terrasoft.BaseViewModelCollection}
 */
Collection: {dataValueType: Terrasoft.DataValueType.COLLECTION},

В моём случае, коллекция содержит (к качестве своих элементов), в частности, определения функций. Это - коллекция $.inputmask в модуле JQueryInputMask, который я пытаюсь перенести из BPMonline 7.2 в BPMonline 7.6.

Евгений, как я уже отвечал здесь, Вам скорее всего не подойдёт структура объекта, который используется в базовых схемах. Лучше оставить данный модуль без изменений, по возможности приведя его к общепринятым стилям.

Хорошо, спасибо.

Евгений, добрый день!

В схеме используется определенный порядок секций diff: {}, attributes: {}, methods: {}, rules: {}... . Повторное использование одного из блоков приведет к некорректной работе приложения.

Я сейчас переношу модуль JQueryInputMask из BPMonline версии 7.2 в BPMonline версии 7.6 и у этого модуля следующая структура: Функции. Потом тернарный условный оператор, в условиях которого вызываются функции. Потом - большая функция, в теле которой определяются другие функции. Потом - коллекция, среди элементов которой присутствуют, в частности, функции. Потом - опять функция. И модуль заканчивается. Как вот в таком модуле расписать секцию methods ? Помогите.

Евгений, добрый день!

При переносе Вам и не нужно придерживаться описанной выше структуры. Такая структура актуальна только для схем, которые наследуются от BaseSchemaViewModel (в частности BaseSection, BasePage, BaseDetail), а другие модули могут иметь произвольную структуру. Упомянутый Вами модуль зависит только от jQuery и не использует другие модули системы, поэтому его структуру можно оставить как есть.

Повторная инициализация свойств объекта (а секции methods, diff, attributes и т.д., которые Вы перечисляете, на самом деле являются свойствами объекта) будет перезатирать их содержимое.

Эх, если бы мне это знать раньше!

Евгений, добрый день!

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

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

//test definition => {
//	fn: RegExp/function,
//	cardinality: int,
//	optionality: bool,
//	newBlockMarker: bool,
//	offset: int,
//	casing: null/upper/lower,
//	def: definitionSymbol
//}

Спасибо, Олег, а вот скажите, пожалуйста, такую вещь - интерпретатор в 7.6 нередко показывает как ошибку то, что строка кода должна находится, не в текущей строке, а, скажем, на строку или на две выше. Это случается, когда, например пишешь открывающую фигурную скобку у блочного оператора, например if(){} не в той же строке, в которой заканчивается описание его условия

if(/* Условие*/) {

а на следующей

if(//Условие)
{

В этом случае интерпретатор трактует как ошибку, то, что какая-либо из строк кода, из числа находящихся ниже, располагается, скажем, не в 49-й строке, а в 50-й, хотя ожидалось, что она будет расположена в 49-й. И вот, в случае разбиения длинной строки комментария на несколько строк, не покажет ли интерпретатор вышеописанную ошибку касательно какой-нибудь из строк исполняемого кода, из числа расположенных ниже комментария?
И второе - скажи, пожалуйста, почему интерпретатор показывает описанную выше ошибку местоположения строки кода ? Ведь у компиляторов C# и C++ такой "странности" нет и в помине.

Заранее благодарен. С уважением

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

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

// некорректное выражение
return
{
	value: myValue
}

Ваша функция вернёт в результате не объект, как ожидается, а неопределённое значение. Поэтому правильно писать в данном случае так:

return {
	value: myValue
}

Соответственно, если писать в блоке if скобки с новой строки, а после return - в той же строке, получаем отсутствие единого стиля и неудобство восприятия.

Что касается длинных строк, да, их можно разбивать на несколько, но с добавлением табов в следующих строках. Например:

if ((<Выражение1>) &&
		(<Выражение2>) &&  // 2 таба относительно первой строки
		(<Выражение3>)) { // 2 таба относительно первой строки
	<Содержимое блока> // 1 таб относительно первой строки
}

Отвечая на Ваш вопрос "почему интерпретатор показывает описанную выше ошибку местоположения строки кода?" - данные проверки не являются характерными для языка JavaScript, они дополнительно встроены в ядро системы bpm'online с целью, как я уже упоминал выше, приведения кода к единому стилю и уменьшения количества ошибок.

Спасибо.

Евгений, добрый день!

Подобная замена на логику повлиять не должна, если логика реализована верно. Дело в том, что при использовании оператора равенства JavaScript выполняет автоматическое преобразование типов, что потенциально может привести к ошибке (например, 0 == "0" или true == "1", но это не одни и те же значения). Для того, чтобы избежать потенциальных ошибок в логике, желательно использовать более строгий оператор идентичности.

Спасибо.

Здравствуйте, Олег!

Рекомендую Вам зарегистрировать обращение, написав на ящик support@terrasoft.ru

Иван, добрый день!

Предоставьте, пожалуйста, примеры Вашей реализации для анализа проблемы.

Ок, прикреплен файл с кодом секции..
В коде (метод loadSelect) увеличен объем выборки данных до 500, как временное решение.

Добрый день!

Для решения задачи следует переопределить два метода - «onLoadData» и «loadGridCollectionItems». Пример кода во вложении.
examplesolution.txt

Спасибо, но такой подход решает проблему порождая другую. В методе "loadSelect" добавлены фильтры по ответственному и статусу лида для определенной роли. При переопределении метода «loadGridCollectionItems» этот фильтр перестает отрабатывать...

Спс, проблема решилась (фильтры убрал, сделал БП права на запись).