Список изменений в системе ТАНДЕМ.Университет

 

Список изменений системы ТАНДЕМ.Университет в версии 2.23.1

Модуль «Абитуриенты (Приемная комиссия)»

1. В настройке ПК добавлена новая опция "Экспериментальный бакалавриат", которая доступна только для типа ПК "Прием на обучение по программам бакалавриата/специалитета". По умолчанию опция выключена.

При открытии конкурсов в рамках набора ОП в рамках ПК с включенной опцией "Экспериментальный бакалавриат" по умолчанию конкурсы добавляются на базе "ОО" (основного общего образования).

При добавлении/редактировании заявления через мастер или через карточку абитуриента доработана логика поля "Документ об образовании" в рамках ПК "бакалавриата/специалитета": учтены документы с уровнем "Основное общее образование" (2013.1.3).

Модуль «Интеграция с Суперсервисом (Сервисом приема)»

1. Дополнена логика системного действия "Удалить данные ЕПГУ", исправлено удаление заявлений, в которых есть заполненная льгота (ранее срабатывала блокировка).

Модуль «Интеграция с ФИС ГИА и приема»

1. Во 2 пакете со структурой приема для конкурсных групп на ГНС по программам аспирантуры дополнена логика заполнения направления/специальности с учетом ограничений ФИС ГИА.

Модуль «Движение контингента»

1. Хранимые файлы в рамках модуля "Движение обучающихся" переведены на механизм хранилищ.

Добавлена новая функция хранения файлов "Документы модуля Движение обучающихся", которая на существующих стендах системы по умолчанию инициализирована с хранением файлов в базе данных (для однократной миграции файлов в файлы хранилища).

На документ в хранилище переведены все сущности модуля с хранимыми пользовательскими файлами:

  • связь приказа и текста приказа (studentOrderTextRelation);
  • связь выписки и текста выписки (studentExtractTextRelation);
  • связь прочего приказа и текста приказа (studentOtherOrderTextRelation);
  • выписка из списочного приказа по обучающемуся (modifyListStuExtract);
  • выписка из сборного приказа по обучающемуся (modifyModularStuExtract);
  • печатная форма произвольного приказа, загруженная пользователем (customOrderPrintForm);
  • печатная форма параграфа произвольного приказа, загруженная пользователем (customParagraphPrintForm).

В рамках проведенной миграции все накопленные файлы в БД инициализированы как файлы хранилища в рамках функции/задачи хранения "Документы модуля Движение обучающихся".

2. Для приказов по обучающимся добавлена возможность добавления вложений (произвольных файлов) на отдельной вкладке.

Работа с файлами разрешена только на стадии формирования документа. Файлы хранятся в хранилище, выбранном в настройках системы для задачи хранения "Документы модуля Движение обучающихся".

3. Доработан механизм визирования/согласования приказов с учетом изменений в базовых механизмах согласования, реализованы новые возможности.

В настройке активации визирования (отдельно для каждого типа приказа/документа) добавлены новые опции:

  • управление очередностью визирования: последовательно (по умолчанию) или параллельно;
  • возможность изменения варианта очередности согласования при отправке документа на согласование: выключена по умолчанию – позволяет пользователям выбирать вариант очередности согласования (при наличии права) для каждого приказа в отдельности;
  • согласование с использованием ЭЦП: выключено по умолчанию  – позволяет производить всем или отдельным пользователям (с учетом настройки возможных виз) согласование документов с использованием ЭЦП.

В настройке возможных виз добавлена опция включения/отключения согласования с использованием ЭЦП. Использование ЭЦП по умолчанию выключено.

Если в настройке активации визирования для типа документа включено согласование с использованием ЭЦП, то при отправке документа (приказа) такого типа на согласование система анализирует настройку возможных виз в части использования ЭЦП:

  • если для визы включено использование ЭЦП, то задача визирования будет добавлена с признаком подписания ЭЦП;
  • иначе – будет добавлена простая задача визирования, т.е. без использования ЭЦП.

Т.о., в согласуемом документе часть задач согласования может быть добавлена с требованием подписания ЭЦП, а другая часть – без требования подписания ЭЦП.

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

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

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

В документах (в частности, в приказах по движению) доработана вкладка "Согласование". В рамках изменений доработана вкладка "Задачи" в личной карточке сотрудника: затронуты списки задач согласования и их колонки.
Новая история согласования реализована непосредственно на базе задач визирования (VisaTask). Добавлены новые поля в задаче визирования: статус задачи, дата согласования, итерация согласования, комментарий, очередность согласования (параллельно или последовательно), согласование с ЭЦП. Прежняя история согласования (VisaHistoryItem) сохранена для архива.

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

Модуль «БРС и журналы преподавателей»

1. Добавлен справочник "Дополнительные данные аттестации" с одним значением по умолчанию: "Пропуски".

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

Модуль «Нагрузка»

1. Оптимизирован алгоритм расчета часов нагрузки. Оценочно расчет должен работать примерно в 5-10 раз быстрее, чем в предыдущей версии.

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

3. В таблице "Планируемые ППС" расчета нагрузки исправлено подкрашивание красным цветом доли ставки, доли периода работы и ставки.

Для доли ставки и ставки выполняется проверка на кратность шагу ставки и превышение предельного значения ставки.

Для доли периода работы проверяется превышение значения "1,0".

Модуль «Расписание»

1. На форму добавления аудиторного обеспечения мероприятия реестра добавлены фильтры по зданию, назначению и типу аудитории.

2. В списках с событиями планового расписания добавлена ссылка на карточку план. потока.

3. На карточке ППС по договору подряда добавлен вывод расписания и создание ограничений расписания.

4. При добавлении аудиторий (в аудиторный фонд подразделения) добавлены фильтры: по зданию, блоку, этажу, ответственному подразделению, назначению и типу аудитории.

5. В справочник "Виды печатных форм оперативного расписания" добавлен системный элемент "Расписание занятий преподавателей по неделям".

В этой печатной форме:

  • в печать попадают персоны преподавателей из потоков и событий, отфильтрованные по параметрам печатной формы;
  • данные группируются по событию, персоне ППС и потоку (для исключения дублей в случае, если персона преподавателя назначена на поток и на событие);
  • полученные сгруппированные наборы еще дополнительно группируются по полному ФИО персоны преподавателя, дню недели, номеру и времени пары, чередованию, названию части версии элемента реестра (дисциплины), условному сокращению вида потока, аудитории.

Базовые модули и функции

1. Реализованы поддержка плагина КриптоПро для браузеров, компонент для подписания контента ЭЦП. После подписания контента система позволяет сохранять артефакты: подпись в виде файла p7s, дату подписания ЭЦП и открытые данные о сертификате.

2. Реализован базовый механизм рассылки уведомлений на email. Для типов уведомлений (типов событий) механизм позволяет на уровне простых шаблонов управлять содержимым темы и текста письма.

3. Доработаны механизмы работы с OAuth, устранены частные ошибки.

Обновленный принцип работы проверки онлайн-пользователей, вошедших в систему с использованием OAuth2-сервиса:

  • Система (одна из наших систем, в частности, ТАНДЕМ.Университет) отправляет запрос на получение информации (email) о пользователе от OAuth2-сервера на основе access token'а, полученного при входе пользователя. Если токен неактивен (истек срок действия по таймауту или по другой причине), то запрос вернет ошибку, тогда сессия работы пользователя принудительно завершается.
  • Если запрос выполнился успешно, то определяется, изменился ли email. Если изменился, то сессия работы пользователя принудительно завершается.

Также исправлены ошибки и сделаны следующие доработки:

  • В OAuth2-клиенте исправлена ошибка при генерации и проверке параметра state.
  • В OAuth2-клиенте исправлена ошибка с активацией компонента вместо редиректа при входе.
  • В OAuth2-сервере исправлена ошибка проверки входящих параметров при запросе клиентом refresh token'а.
  • На странице "Пользователи онлайн" исправлена ошибка: если в систему вошли несколько пользователей с одним и тем же principalContext (например, это возможно при входе одного пользователя из разных браузеров или с разных устройств), то при попытке выполнить какое-либо действие с таким пользователем (например, завершить сессию или заблокировать), действие производилось не всегда с нужным пользователем, а с первым в списке, имеющим данный principalContext (данную учетную запись).
  • Увеличено время таймаута сессии неактивного пользователя (тот, у которого не открыта ни одна страница) с 5 минут до времени, заданного в свойстве session-timeout в файле проекта web.xml (по умолчанию 20 минут). Это относится как к обычным пользователям, так и к пользователям, вошедшим с использованием сервиса OAuth2.
  • В OAuth2-сервере изменены сроки жизни токенов. Срок жизни для access token'а установлен равным 5 минутам (ранее был 1 час). Срок жизни для refresh token'а установлен равным таймауту сессии неактивного пользователя (по умолчанию 20 минут). Ранее refresh token мог быть актуальным вечно (до перезапуска приложения), из-за чего пользователи, которые вошли с помощью сервиса OAuth2, также могли работать вечно (до перезапуска приложения). Новый access token можно получить запросом нового refresh token'а на основе имеющегося, при этом срок истечения нового access token'а начнет отсчитываться от времени его получения. Срок истечения нового refresh token'а останется тем же, т.е. срок жизни всех refresh token'ов для одного пользователя одинаков и по умолчанию равен 20 минут со времени входа пользователя.

Особенности настройки времени жизни access и refresh token’ов на сервере Keycloak 20.0.x:

  • Для настройки времени жизни access token’а следует в настройках для realm на вкладке Tokens задать свойство Access Token Lifespan.
  • Поскольку время жизни refresh token’а нельзя задать явно, то оно вычисляется как наименьшее из значений свойств SSO Session Idle, Client Session Idle, SSO Session Max и Client Session Max (учитываются только значения больше нуля), которые задаются для realm на вкладке Sessions.

4. Визирование. Переработан механизм визирования/согласования, реализованы новые возможности:

  • наряду с последовательной очередностью согласования добавлена возможность параллельного согласования документа;
  • расширена настройка активации визирования;
  • добавлена поддержка возможности подписания документов ЭЦП;
  • переработана и расширена история согласования;
  • доработаны списки задач согласования.

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

Интеграционная подсистема

1. Разработан новый модуль сервиса уведомлений (nsinotification). Данный сервис является комплексным решением, способным организовать процесс рассылки сообщений на электронную почту и во внешние подсистемы вместе с формированием текстов сообщений по определенным шаблонам. Для этого реализованы следующие потоки:

  • "Тип уведомлений" (NotifyTypeType) – пополняемый из внешних подсистем справочник, позволяющий различать уведомления по типам;
  • "Уведомление" (NotifyType) – поток, содержащий уведомление (дата, тема, текст уведомления и набор меток со значениями, которые могут быть использованы для формирования текстового уведомления, направляемого на электронную почту);
  • "Получатель уведомления" (NotifyRecipientType) – поток, содержащий ссылку на уведомление и сведения о получателе этого уведомления;
  • "Отправка уведомления для получателя уведомления" (NotificationRecipientSendInfoType) – сведения о статусе отправки сообщения получателю, содержит информацию  о том, было ли отправлено уведомление на электронную почту получателю;
  • "Подписка на получение уведомлений" (NotificationSubscriptionType) – поток, позволяющий управлять подписками, посредством которого подсистемы могут управлять тем, нужно ли отправлять пользователю уведомления на электронную почту и/или в личный кабинет.

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

2. С целью передачи оценок из Личного кабинета преподавателя, доработан справочник "Баллы обучающегося по событию" (TrJournalGroupEventStudentResultType).

Реализована поддержка приема данных потока в сторону ТАНДЕМ.Университет (ранее поток только отправлял данные из ТАНДЕМ.Университет в интеграционную подсистему). Добавлены поля "Дата обработки входящего пакета" (incomingPackageParseDate, дата со временем) и "Ошибки валидации внешнего балла" (scoreValidationError), куда будут записываться итоги обработки входящих пакетов на стороне ТАНДЕМ.Университет.

Если планируется использование этого потока для передачи данных в ТАНДЕМ.Университет, то необходимо добавить подписки на данный справочник в ТАНДЕМ.Университет. Если источник данных – ТАНДЕМ.Университет, то для Личного кабинета необходимо настроить подписки на соответствующие справочники для ТАНДЕМ.Университет. Если же ТАНДЕМ.Университет является источником справочника TrJournalGroupEventStudentResult, то в ТАНДЕМ.Университет необходимо настроить подписку для конкретного справочника на Личный кабинет. Если используется две и более инсталляции ТАНДЕМ.Университет (например, несколько инсталляций колледжей), то в подписке нужно добавить флаг "владелец – данная подсистема". Это значит, что в данную подсистему будут уходить данные только, если dataOwner соответствует текущей подсистеме.

3. Внесены коррективы в сообщение об ошибке, выводимое при попытке импортировать данные из файла в формате, отличающемся от формата, поддерживаемого для подсистемы. Ранее не учитывалась возможность загрузки архива с файлами в формате JSON для адаптера подсистемы, работающей по протоколу HTTP/SOAP.

4. В рамках текущей версии было отложено удаление отдельных полей в потоке данных "Событие в журнале НСИ" (TrJournalGroupEventType).

Вместо них следует использовать данные нового потока "Элемент справочника Событие в журнале НСИ" (TrJournalGroupEventType).

5. Реализован механизм настройки интеграции на основе заранее заданных сценариев интеграции.

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

6. Доработан поток "Подразделение НСИ" (DepartmentType), добавлено поле "Контактные данные" (contactData).

7. Изменен механизм обработки входящих пакетов с данными (в том числе при загрузке из файла): уменьшен размер порции, обрабатываемой в транзакции, что позволило ускорить процесс обработки пакета.

8. Добавлен новый модуль "Общежития и поселение" (nsisettle). В модуле добавлены потоки "Договор на поселение" (SettleContractType)" и "Проживающий по договору" (SettleContractResidentType). В поток "Физическое лицо" (HumanType) добавлен признак "Нуждается в общежитии" (needDormitory).

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

10. В модуле интеграции с Современной цифровой образовательной средой (СЦОС) добавлена блокировка службы отправки данных в СЦОС для исключения ее повторного запуска до завершения отправки данных предыдущего цикла.

11. В потоке "Часы учебной нагрузки" (EplTimeItemEduLoadType) размер полей "Название план. группы" (plannedGroupName) и "Название план. потока" (plannedStreamName) увеличен до 1200 символов.

12. В датаграммы элементов системных справочников добавлен признак "Системный элемент", которым помечаются элементы справочников, являющихся системными (не удаляемыми) в подсистеме-источнике. Признак проставляется в атрибутах элемента и выглядит так: <Course dataOwner="almt" systemElement="true">...</Course>.

13. В потоке "Запись обучающегося в потоке (EppRealEduGroupRowType)" удалено неактуальное поле (confirmDate).