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

Моя первая фиксация была 15 февраля 2018. Это было только для обновления версии Django, используемой Mayan EDMS, с 1.10.7 до 1.10.8. Вот и все.

Основываясь на моем опыте использования СЭД Mayan для работы, я начал изучать код, чтобы узнать, могу ли я исправить некоторые другие вещи. Я обнаружил, что исправляю API, пишу тесты и смотрю на незавершенные функции, над которыми работал главный разработчик. Меня зацепило.

Вскоре ко мне присоединился Эрик Риггс. Эрик использует СЭД Mayan как часть своей работы с 8 до 5, поэтому он тоже хорошо разбирался в коде. С помощью Эрика и через двенадцать дней с момента моего первого коммита мы выпускаем версию 2.8 нашей вилки Mayan EDMS. Мы назвали его Mayan EDMS NG (NG для следующего поколения).

Мы все больше и больше восхищались возможностями для улучшений. Мы сделали решительный шаг и теперь ежедневно работаем над СЭД Mayan.

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

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

Превращение СЭД Mayan в одностраничное приложение

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

Экосистема Javascript - это дикие джунгли конкурирующих «стандартов». Между JQuery, Angular, React, Ember, CoffeeScript, ES2015, ES2017, Babel, Grunt, Gulp, Bower, Webpack, Vue, Webpack, Rollup, Parcel и многими другими легко понять, почему этот подход был правильным на этапе разработки. время. К счастью, ситуация улучшилась благодаря HTML5 и CCS3. Теперь браузер может делать много вещей, для которых часто требовался запутанный код Javascript.

Одна из наиболее частых жалоб на пользовательский интерфейс - он медленный, тяжелый, требует от пользователей слишком много перемещаться. Что для достижения цели требуется «слишком много щелчков мышью».

Одностраничные приложения (SPA) динамически перезаписывают текущую страницу, а не загружают всю страницу при каждом щелчке мыши. Это заставляет веб-приложение чувствовать себя и вести себя как настольное приложение. Поскольку большая часть кода стилей и Javascript загружается только один раз, есть также дополнительное преимущество в виде меньшего количества передаваемых данных. Таким образом приложение становится легче и быстрее реагирует на пользовательские события. Поскольку стиль загружается и интерпретируется в начале, браузер также может быстрее применить его к новому контенту.

Чтобы найти баланс с тяжелой философией Роберто, мы использовали только HTML5 и jQuery. Помимо двух дополнительных библиотек jQuery, дополнительных зависимостей фреймворка нет. С преобразованием в SPA теперь возможно множество других ходатайств об улучшении пользовательского интерфейса. Мы будем работать над ними, как только сообщество подтвердит, что все изменения пользовательского интерфейса, внесенные для создания SPA, работают должным образом.

Обновление до Django 1.11

Переход на Django 1.11 оказался настоящим испытанием. Несмотря на то, что Django 1.11 является второстепенным выпуском, он нарушает совместимость и интерфейсы в нескольких ключевых областях. Среди них были шаблоны и виджеты форм.

СЭД Mayan использует сложную систему шаблонов, форм и виджетов. Система имитирует объектно-ориентированные концепции, такие как наследование на этапе визуализации. Это позволяет обслуживать более 300 представлений с помощью всего лишь нескольких классов форм и базовых шаблонов. После обновления требовалось много времени на тестирование и аудит всех представлений и форм. Если кто-либо из участников проекта Django читает это, пожалуйста, примите более строгие правила нумерации версий, например, Семантическое управление версиями.

Наряду с обновлением до Django 1.11 мы исправили множество предупреждений об устаревании в рамках подготовки к возможному обновлению до Django 2.0.

Улучшения уведомлений

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

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

API базы ресурсов и услуг

API ранее был организован с использованием той же базовой философии, что и СЭД майя. Философия разделения интересов и разделения. Это означало, что URL-адреса API сначала делятся по приложениям, а затем по типам объектов.

Например:

URL-адрес для получения списка документов:

/ документы / документы

URL-адрес для получения списка тегов для документа был:

/ tags / document / ‹ID› / tags

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

Это означает, что теперь URL-адрес для получения списка документов:

/ документы /

И URL-адрес для получения списка тегов для документа теперь:

/ документы / ‹ID› / теги

Отказ от миграции

Миграция базы данных является обязательной, чтобы ваши данные оставались согласованными после каждого обновления. Их необходимо фиксировать последовательно, чтобы моделировать эволюцию структур базы данных с течением времени. Это верно даже для новых установок без существующих данных. По мере того, как Mayan EDMS развивается и добавляет функции, она также добавляет миграции. Каждая из этих миграций увеличивает количество раз, необходимое для установки Mayan EDMS.

Django недавно добавил поддержку слияния миграций. Поскольку миграции иногда являются взаимозависимостями между собой, это деликатная процедура. Вместо того, чтобы сходить с ума от слияний, мы использовали эту функцию в умеренных количествах. Мы объединили миграции, которые оказались стабильными в течение нескольких месяцев или лет. Кроме того, эти объединенные или «сжатые» миграции используются только для новых установок. Любое обновление существующей установки будет использовать обычные миграции. По прошествии некоторого времени, если не сообщается о проблемах с объединенными миграциями, отдельные миграции будут удалены, а объединенные миграции займут их место.

Это приложения, для которых были объединены миграции:

  • acls (ACL): 1 и 2
  • кассы (кассы): 1 и 2
  • общие (не отображаются в пользовательском интерфейсе): от 1 до 8
  • конвертер (не отображается в пользовательском интерфейсе): от 1 до 12
  • django_gpg (ключи): от 1 до 6
  • document_indexing (Индексирование): от 1 до 5
  • document_parsing (Парсинг, «Контент»): 1 и 2
  • document_signatures (Подписи): от 1 до 6
  • document_states (Рабочие процессы): 1 и 2
  • dynamic_search (Поиск): от 1 до 3
  • события (Ивент): с 1 по 4
  • связывание (умные ссылки): от 1 до 5
  • lock_manager (не отображается в пользовательском интерфейсе): 1 и 2
  • mailer (Рассылка): с 1 по 5
  • метаданные (Metadata): от 1 до 8
  • motd (Сообщение дня): с 1 по 5
  • permissions (Разрешения): от 1 до 3
  • источники (Источники): с 1 по 16

Обновления зависимостей

Большинство требований, зависимостей и библиотек были обновлены до последней версии.

  • Подушка: 5.0.0
  • поток активности django: 0.6.5
  • джанго-компрессор: 2.2
  • заголовки django-cors: 2.2.0
  • django-formtools: 2.1
  • django-qsstats-magic: 1.0.0
  • Джанго-цитадель: 0.3.0
  • джанго-костюм: 0.2.26
  • Furl: 1.0.1
  • graphviz: 0.8.2
  • pyocr: 0,5,1
  • python-dateutil: 2.6.1
  • питон-магия: 0.4.15
  • pytz: 2018.3
  • sh: 1.12.14
  • rest_framework_swagger заменен на drf-yasg: 1.5.0

FancyBox обновлен до версии 3, Font Awesome до версии 5, jQuery до версии 3.3.1. ajaxForm версии 4.2.2, URI.js 1.19.1 и pace 0.7.8 были добавлены как часть преобразования в одностраничное приложение.

Синтаксис поиска

Поиск без использования специализированной поисковой базы затруднен. Большинство программ просто выбирают ленивый путь и вынуждают пользователя установить специальную поисковую систему. Ранее мы заметили, что дизайн Mayan призывает избегать отдельной поисковой системы за счет отсутствия синтаксиса поиска. Поддержка OR и отрицательного термина - это наша первая попытка добавить особый синтаксис в поисковый код Mayan. Если мы получим хорошие отзывы, мы планируем добавить больше.

По умолчанию теперь поисковые запросы направляются по запросу «И». Это означает, что поиск:

Tag1 Tag2

вернет только документы с прикрепленными обоими тегами. Чтобы предложить противоположный выбор, мы добавили синтаксис «ИЛИ». Ищем:

Tag1 OR Tag2

вернет документы с прикрепленными тегами.

Мы также добавили поддержку терминов литералов.

Ищем:

синяя машина

вернет документы со словами «синий» и «автомобиль», даже если они не вместе. Это означает получение документов с фразами «голубое небо» и «медленная машина». Для поиска точных терминов заключите их в кавычки:

«Синяя машина»

Это вернет только документы с точной фразой «синяя машина».

Запуск нескольких экземпляров Mayan EDMS

Если вы когда-либо пробовали запустить два экземпляра Mayan EDMS, вы бы заметили, что они оба пытаются создать файл блокировки с тем же именем в каталоге / tmp. Только первый экземпляр сможет работать.

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

Мы решили эту проблему, используя шестнадцатеричное хеш-представление уникального параметра установки SECRET_KEY. Использование хэша делает изменение значения для получения SECRET_KEY невозможным для всех практических целей.

Настройки разрешения дисплея

Во время работы над шаблоном, необходимой для обновления версии Django, мы заметили, что размеры отображения (отображение, предварительный просмотр, миниатюра) были указаны как строка, включающая горизонтальное и вертикальное разрешение, разделенные символом «x». Использование символа «x» для разделения элементов разрешения нестандартно и не так хорошо спланировано, как остальная часть проекта. Конвертер в СЭД Mayan также позволяет указывать только горизонтальное разрешение. Такой дизайн создавал некоторую двусмысленность в коде. Мы решили разделить настройки задания разрешений на две настройки для каждого размера. Один параметр для разрешения по горизонтали, а другой - для разрешения по вертикали.

Теперь настройки:

DOCUMENTS_DISPLAY_WIDTH, DOCUMENTS_DISPLAY_HEIGHT, DOCUMENTS_PREVIEW_WIDTH, DOCUMENTS_PREVIEW_HEIGHT, DOCUMENTS_PRINT_WIDTH, DOCUMENTS_PRINT_HEIGHT, DOCUMENTS_THUMBNAIL_WIDTHUMTH, DOCUMENTS_THUMBNAIL_WIDTHTH

Другие изменения, о которых стоит упомянуть

  • Исправить фильтрацию разрешений при выполнении поиска по странице документа
  • base.js был разделен на mayan_app.js, mayan_image.js и partial_navigation.js.
  • Исправлено разбиение на страницы детального вида шкафа.
  • Улучшите обработку разрешений в приложении рабочего процесса.
  • Разрешение на просмотр деталей извлеченного документа теперь требуется для просмотра API деталей извлеченного документа.
  • Добавьте недостающие службы для API оформления заказа.
  • Исправьте существующие API оформления заказа.
  • Обновите представления и сериализаторы API для последней версии платформы Django REST.
  • Обновите до последней версии пакеты для сборки, разработки, документации и тестирования.
  • Добавьте скрипт статистики для создания отчета о представлениях, API и тестах для каждого приложения.
  • Слияние с именем файла base64 патч от Корнелиуса Людмана.
  • Интерфейс возврата SearchModel изменен. Класс больше не возвращает значение result_set. Вместо этого используйте возвращенный набор запросов.
  • Удалите неиспользуемую внутреннюю функцию scrollable_content.
  • Удалите неиспользуемый пакет animate.css.
  • Добавьте MERC, определяющую использование библиотеки javascript.
  • Документы, у которых нет хотя бы версии, не проверяются на дубликаты.
  • Преобразуйте эскизы документов, предварительный просмотр, предварительный просмотр изображений и промежуточные файлы в базовые виджеты шаблона.
  • Унифицируйте все виджеты документов.
  • Печатные страницы теперь имеют полную ширину.
  • Переместите недопустимую разметку документа в отдельный HTML-шаблон.
  • Перенести трансформации в отдельный модуль.
  • Разделите documents.tests.test_views на base.py, test_deleted_document_views.py,
    test_document_page_views.py, test_document_type_views.py, test_document_version_views.py,
    test_document_views.py, test_duplicated_document_views.py
  • Сортировка умных ссылок по меткам.
  • Переименуйте внутреннее имя пространства имен разрешений типа документа. Необходимо обновить существующие разрешения.
  • Убраны лишние проверки разрешений.

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