ПРОБЛЕМА: - cn/ou были установлены как primary_key в LdapUser/LdapGroup/LdapOrganizationalUnit - CN/OU не уникальны глобально (могут быть в разных OU) - .objects.get(cn=...) возвращал случайную группу при дубликатах - Нарушался дизайн django-ldapdb, где dn - базовый primary_key РЕШЕНИЕ: - Убран primary_key=True из cn/ou полей - Используется dn (Distinguished Name) как primary_key из базового класса - DN - уникальный идентификатор объекта в LDAP, требуется для всех операций - Удалено избыточное поле distinguished_name ИЗМЕНЕНИЯ: - orm_models.py: cn/ou теперь обычные CharField, dn наследуется из ldapdb.models.Model - group_utils_orm.py: .get(cn=...) → .filter(cn=...).first() с предупреждением - group_service.py: find_dn() и find_dn_wrapped() используют .filter().first() ОБОСНОВАНИЕ ОТКАЗА ОТ objectGUID: - objectGUID неизменяем и уникален, НО: - LDAP протокол требует DN для всех операций (add/modify/delete/rename) - django-ldapdb жёстко завязан на self.dn для save()/delete() - GUID можно использовать только в search filter, результат всё равно возвращает DN - DN - естественный primary key для LDAP объектов
Документация проекта EUSRR
Эта папка содержит всю документацию проекта, организованную по категориям.
📁 Структура
completed/
Завершенные задачи: рефакторинги, исправления, реализованные фичи (22 файла)
guides/
Активные руководства и инструкции для разработчиков (гайды по валидации, миграции, настройке)
architecture/
Архитектурная документация и анализ систем (рендеринг чата, архитектура страниц)
diagnostic/
Диагностические руководства (WebSocket 1006, отладка проблем)
in-progress/
Активные задачи в разработке (закупки, получатели заявок, календарь)
reports/
Отчеты и аудиты проекта (реорганизация документации, план очистки)
📝 Главная документация
- README.md - основная документация проекта
- docs/reports/ - отчеты и планы по проекту
🔍 Поиск информации
- Завершенные фичи →
completed/ - Как настроить X →
guides/ - Как работает Y →
architecture/ - Проблемы с Z →
diagnostic/ - Что в разработке →
in-progress/ - Отчеты и аудиты →
reports/
Description
Разработка — в develop; локальный CI работает через Git hooks и quality gates перед коммитом/пушем. После проверки — слияние в master. Push в master запускает blue-green деплой на CORP через Gitea Actions и Telegram-отчёт. Статус деплоя — «Действия».
https://corp.robotail.pro/
Readme
86 MiB
Languages
Python
47.6%
TypeScript
29.8%
JavaScript
15.7%
HTML
4.1%
SCSS
2.1%
Other
0.7%