- Updated equipment_detail view to load data from DB (SSR)
- Added select_related and prefetch_related for optimization
- Implemented can_manage permission check in view
- Removed loadEquipmentDetail() JavaScript API call
- Added breadcrumb navigation
- Kept action handlers (maintenance, transfer, write-off)
- Added department loading for transfer modal
- Now consistent with request_detail SSR approach
- Added comprehensive permission checks in perform_create()
- Created _check_item_edit_permission() helper method
- Updated perform_update() and perform_destroy() to use helper
- Permission logic now matches CanManageProcurementRequest:
* Admins/Staff can edit items in DRAFT requests
* Users with change_procurementrequest permission
* Request author can edit their own requests
* Department head can edit requests from their department
- Fixes 403 Forbidden error when creating/editing/deleting items
- API departments возвращает объект с пагинацией {results: [...]}, а не массив
- Добавлена универсальная обработка как массива, так и объекта с results
- Добавлены проверки существования DOM элементов перед обращением
- Исправлена ошибка при редактировании заявки
- Добавлены модальные окна для всех действий на странице деталей
* Добавление позиции (#addItemModal)
* Одобрение заявки (#approveModal)
* Отклонение заявки (#rejectModal)
- Реализованы JavaScript обработчики для всех кнопок
* deleteItem() - удаление позиции
* saveItemBtn - сохранение новой позиции
* confirmApproveBtn - одобрение с комментарием
* confirmRejectBtn - отклонение с обязательным комментарием
- Исправлены API endpoints (items вместо request-items)
- Доработана форма создания/редактирования заявки
* Удалены несуществующие поля (desired_date, estimated_cost)
* Добавлен выбор отдела из API
* Реализована AJAX отправка формы
* Поддержка создания черновика и отправки на согласование
* Поддержка редактирования существующих заявок (PATCH)
- Добавлен URL и view для редактирования заявок
- Кнопка "Редактировать" теперь ведёт на страницу редактирования
- Обновлены иконки статусов в dashboard.html и request_list.html
- Все статусы теперь используют одинаковые иконки и стили
- Добавлены функции getStatusBadgeHTML() для динамического рендеринга
- Исправлена синтаксическая ошибка в loadRequests()
- Статусы: draft, pending, approved, rejected, in_progress, completed, cancelled
Добавлены возможности:
1. Django Admin Actions:
- 'Создать бюджеты на следующий квартал для всех отделов'
- 'Скопировать выбранные бюджеты в следующий квартал'
2. Management Command:
python manage.py create_next_quarter_budgets
Опции:
--year YEAR --quarter Q - конкретный период
--dry-run - показать без создания
--default-amount 100000 - сумма по умолчанию
Логика:
- Копирует allocated_amount из текущего квартала
- Если нет текущего бюджета - использует значение по умолчанию (0)
- Пропускает уже существующие бюджеты
- Сбрасывает spent_amount в 0
- Убрать remaining_amount и utilization_percentage из list_display (это @property)
- Добавить методы get_remaining_amount и get_utilization_percentage
- Защитить от None в allocated_amount
- Исправить prefetch_related в views_frontend
Добавлены endpoints:
- start_work: APPROVED → IN_PROGRESS
- complete: IN_PROGRESS → COMPLETED
- cancel: отмена заявки с любого статуса кроме завершённых
- create_equipment: создание оборудования из позиции завершённой заявки
Frontend:
- Модальные окна approve/reject/cancel
- POST handler для создания заявок
- Django формы для заявок
Тесты: 19 новых тестов lifecycle, всего 136 тестов procurement passed
- Add DeptPerm.MANAGE_EQUIPMENT scoped permission constant
- Create migration 0035 for new DepartmentPermission
- Refactor CanManageEquipment permission class with:
* Admin/staff/superuser → full access
* Model permissions → full access (add/change/delete_equipment)
* Department head → own department, can choose responsible
* Scoped permission → own department, responsible forced to head
* Regular members → no access
- Update EquipmentListSerializer with:
* Permission level detection (full/dept_head/scoped/None)
* Auto-fill department and responsible based on permission level
* Validation that responsible is in same department
- Add create_options endpoint returning:
* allowed_departments, can_choose_department, can_choose_responsible
* default_responsible, permission_level
- Add bulk equipment creation support with auto-generated inventory numbers
- Implement 45 comprehensive permission tests (all passing)
- Fix is_active=True in test make_user() fixture
Tests: 45/45 passing ✅
- Исправлена обработка ответа API (поддержка как массива, так и объекта с results)
- API возвращает объект с пагинацией, а не просто массив
- Теперь корректно извлекается массив категорий из data.results
- Исправлена ошибка 'categories.forEach is not a function'
- Добавлена кнопка 'Управление категориями' на странице оборудования
- Создан модал с двумя секциями: добавление и список категорий
- Форма создания категории: название, иконка Bootstrap Icons, описание
- Список существующих категорий с возможностью удаления
- JavaScript функции для работы с API категорий
- Автоматическое обновление списка после создания/удаления
- Защита от удаления категорий с привязанным оборудованием
- Доступно только для staff пользователей (can_manage)
- Добавлен список departments в контекст request_list view
- Реализовано динамическое добавление позиций (items) прямо в модале создания заявки
- Кнопка 'Добавить позицию' для добавления товаров/услуг
- Каждая позиция содержит: название, описание, количество, ед.изм., цену
- Позиции можно удалять кнопкой X
- JavaScript собирает все позиции и отправляет в API вместе с заявкой
- Поддержка как создания с позициями, так и без них
- Реализовано на обеих страницах: dashboard и request_list
- Все 72 теста проходят успешно
- Сделано поле 'items' необязательным в ProcurementRequestCreateSerializer
- Добавлено поле 'department' в форму создания заявки (dashboard и request_list)
- Обновлен JavaScript для передачи department в API
- Добавлен список departments в контекст dashboard view
- Теперь можно создать заявку без позиций (items), добавить их потом
- Все 72 теста проходят успешно
- Добавлена кнопка 'Добавить оборудование' на странице списка
- Создан модал для добавления нового оборудования
- Создан модал для редактирования существующего оборудования
- Добавлена кнопка редактирования в dropdown меню каждой карточки
- Реализованы JavaScript обработчики для создания/редактирования через API
- Добавлен импорт User в views_frontend.py для передачи списка пользователей
- Все поля модели Equipment доступны для редактирования (включая статус, отдел)
- Изменен текст кнопки на 'Создать заявку' на всех страницах
- Добавлен параметр create_as_card=True на странице списка заявок
- Перемещен модал внутрь блока content в dashboard.html (исправление ошибки Bootstrap)
- Change dashboard create button to use modal instead of URL redirect
- Add create_as_card and create_modal parameters to page_header
- Replace form POST submission with AJAX API calls
- Add proper form validation and error handling
- Redirect to request detail page after successful creation
- Remove unused create_url from dashboard context
Stage 7 - Integration:
- Create notification types migration for procurement
- Fix signals to use pre_save for status tracking
- Add broadcast_request_update function for WebSocket events
- Add procurement_update handler in UserConsumer
- Add 6 integration tests for signals and notifications
- Update README with integration details
All 72 tests passing (66 base + 6 integration).
Created PROCUREMENT_TEST_COMPLETION_REPORT.md with:
- Complete test statistics (41/41 PASSED)
- Detailed analysis of all 10 fixed issues
- Technical infrastructure setup notes
- Git cleanup documentation
- NotificationService integration rationale
- Lessons learned and best practices
- Next steps roadmap (Stages 4-6)
- Development metrics and timeline
This report serves as:
1. Historical record of testing phase
2. Reference for similar debugging tasks
3. Onboarding documentation for new developers
4. Proof of Stage 1-3 completion
- Added Q(approvals__approver=user) filter to ProcurementRequestViewSet.get_queryset()
- Ensures users can see requests where they are designated approvers
- Added .distinct() to prevent duplicate results from approval JOIN
- Updated test_cannot_approve_without_permission to accept 404 (more secure)
- Cleaned up debug statements from test_workflow.py
This fixes the 404 errors in multi-level approval workflow:
- test_multi_level_approval: PASSED ✅
- test_cannot_approve_without_permission: PASSED ✅
All 41 procurement tests now passing: 20 models + 12 API + 9 workflow
- Add estimated_cost to all test ProcurementRequests
- Fix budget year from 2024 Q1 to 2025 Q4
- Fix finance manager lookup to check user_permissions too
- Remove debug print from test_submit_request_creates_approvals
Result: 39/41 tests PASSED (was 38/41)
Remaining: 2 tests with 404 on /approve/ endpoint
Created detailed documentation covering:
- 8 data models with relationships and fields
- Complete API endpoints specification (30+ endpoints)
- Permission matrix and access control
- Approval workflow state machine
- UI/UX mockups for all pages
- 8-stage implementation roadmap (1-2 months)
- Technology stack decisions
- Risk assessment and mitigation strategies
- Complete checklist for tracking progress
Key Features:
- Procurement request creation and approval workflow
- Multi-level approval based on cost thresholds
- Budget control per department/quarter
- Equipment/inventory management with QR codes
- Maintenance tracking and history
- Supplier management
- Real-time notifications and WebSocket updates
- Export to PDF/Excel reports
Ready to start Stage 1: Basic Structure
Changes:
1. employees_list.html - 'Create Profile' button now only visible to staff/superuser
API requires staff/superuser for POST /employees/ (explicit check in create method)
2. department_list.html - Simplified permission check for 'Create Department' button
Changed from: can_create_departments OR perms.employees.add_department OR is_staff
To: is_staff OR is_superuser OR perms.employees.add_department
API uses AdminOrActionOrModelPerms which checks employees.add_department
3. skill_list.html - 'Add Skill' button now requires authentication
API allows any authenticated user to create skills (IsAuthenticated only)
Before:
- Department creation check was redundant with can_create_departments variable
- Skill creation had no check
After:
- All create buttons properly check permissions matching API requirements
- Consistent with feed and documents modules permission patterns
Root cause identified:
- Template checked non-existent permissions (publish_company_post, publish_department_post)
- Django only creates 4 default permissions: add, change, delete, view
- User actually HAD feed.add_post permission from Position→Group chain
Solution:
- Changed template check to use feed.add_post (real permission)
- Confirmed PositionRoleBackend works correctly (13/13 tests passed)
- User can now see 'Create Post' button
Production diagnostic confirmed user has permissions through position:
Position 'СММ специалист' → Group 'Дизайн СММ Реклама' → Permissions include feed.add_post
Changed from non-existent permissions:
- perms.feed.publish_company_post
- perms.feed.publish_department_post
To actual Django model permission:
- perms.feed.add_post
User diagnosis confirmed:
- User has Position 'СММ специалист'
- Position linked to Group 'Дизайн СММ Реклама'
- Group has permissions: add_post, change_post, delete_post, view_post
- PositionRoleBackend correctly grants these permissions
The 'Create Post' button will now appear for users with feed.add_post permission through their position groups.
Changes:
1. auth_backends.py - Added is_active check in get_all_permissions()
Inactive users should not receive any permissions from their position
2. test_position_permissions.py - Multiple test fixes:
- Moved fixtures to module level (accessible to all test classes)
- Changed Permission creation to filter().first() pattern (no IntegrityError)
- Fixed permission cache issues (use fresh User.objects.get() after changes)
- Changed test_staff_user_keeps_all_permissions → test_superuser_has_all_permissions
(is_staff does NOT grant all perms, only is_superuser does)
Test Results:
✅ 13/13 tests PASSED
✅ All permission inheritance scenarios verified
✅ PositionRoleBackend implementation confirmed working
Key Findings:
- Position → Groups → Permissions inheritance works correctly
- Permission caching requires fresh instance after position changes
- is_active check was missing (now fixed)
- is_staff does NOT grant all permissions (only is_superuser)
Next Steps:
- Check production environment for permission caching issues
- Verify LDAP group sync is working
- Test UI button visibility with real user accounts
Created pytest test suite to verify permission inheritance through positions:
Test Coverage:
1. User without position has no permissions (PASS)
2. User with position gets all group permissions (needs fix)
3. Position change updates permissions dynamically
4. Remove position removes all permissions
5. Multiple users with same position get same permissions
6. Staff users keep all permissions regardless
7. Multiple groups' permissions are additive
8. get_all_permissions() includes position perms
9. Position without groups grants no permissions (PASS)
10. Inactive users have no permissions
11. Direct user permissions + position permissions combine
12. Feed/Documents integration tests
Current Results:
- 3 tests PASSED (basic cases)
- 10 tests need fixing (fixture scope issues)
Purpose:
These tests will validate that PositionRoleBackend correctly
grants permissions from Position.groups to users, which is
needed for features like:
- Show 'Create Post' button for users with publishing rights
- Show 'Create Document' button for users with document rights
- Consistent permission checks across frontend and backend
Next Steps:
1. Fix IntegrityError in permission creation (use filter first)
2. Make fixtures work across test classes
3. Run tests to verify PositionRoleBackend implementation
4. If tests fail, fix the backend implementation
Problem:
- When editing employee profile, got duplicate PATCH requests
- One request returned 502, another 200 OK
- Error appeared in console but operation succeeded
- Classic double-submit race condition
Root Cause:
initEmployeeForm() added new addEventListener('submit') on every call.
If function was called twice (e.g., on tab navigation or re-render),
two event handlers would fire simultaneously, sending parallel requests.
Solution:
1. Check if form already initialized via data-attribute
2. Set form.dataset.employeeFormInitialized = 'true' flag
3. Skip re-initialization if already initialized
4. Return API object for already initialized forms
This ensures only ONE submit handler per form, preventing:
- Duplicate PATCH requests
- 502 errors from race conditions
- Confusing UX with errors that don't break functionality
Now form submits cleanly with single request.
Problem:
- When assigning/changing position, got 502 error
- Error: 'DirectoryService' object has no attribute '_ensure_position_group'
- Method was called on wrong service class
Root Cause:
DirectoryService doesn't have _ensure_position_group method.
This method exists in PositionService (line 190 of position_service.py).
Solution:
- Import and use PositionService for position-specific operations
- Keep DirectoryService for general group operations (add/remove members)
- Use pos_svc._ensure_position_group() to create/get position group DN
- Use dir_svc for add_group_members/remove_group_members
Now position assignment/changes work correctly through LDAP sync.
Problem:
- When clearing employee position (position_id: ''), LDAP sync failed
- Error: LDAP modify failed: 'unwillingToPerform' (code 53)
- System tried to remove user from position group but LDAP refused
Root Causes:
1. Empty string '' not explicitly converted to None
2. unwillingToPerform error not handled (user may not be in group)
Solution:
1. Convert position_id: '' to None (no position) at parsing stage
2. Wrap remove_group_members in try/except
3. Ignore unwillingToPerform errors with warning log
4. Add detailed logging for position group operations
This allows users to clear positions without LDAP sync failures.
Previously: 'Create Document' button visible to everyone
Now: Button visible only for:
- Staff users (is_staff), OR
- Users with documents.add_document permission
This prevents regular users from seeing a button they can't use,
improving UX by showing only available actions.
Previously: Only staff users could see 'Create Post' button
Now: Button visible for:
- Staff users (is_staff), OR
- Users with feed.publish_company_post permission, OR
- Users with feed.publish_department_post permission
This allows department managers and content creators to publish
posts without needing full staff status.
Problem: Regular users couldn't create requests while admins could
Root cause: to_internal_value() used dict(QueryDict) which converts
all values to lists, breaking validation
Solution:
- For QueryDict: use _mutable flag to modify in-place
- For regular dict: use dict() conversion as before
- Avoids ['value'] instead of 'value' conversion
This fixes 400 errors for non-admin users when creating requests
with multipart/form-data.
- Log Content-Type header
- Log POST, FILES, and data keys separately
- Log actual values and types of key fields (type, title, dates, comment)
- This will help identify multipart parsing issues
Backend (API):
- Added logging of user ID and request data keys before validation
- Log validation errors with full details before raising exception
- Helps diagnose 400 Bad Request errors from users
Frontend (JS):
- Added console logging of all FormData entries before submit
- Improved error message display with field-specific validation errors
- Shows structured error messages instead of generic 'HTTP 400'
This will help identify why some users get 400 errors when creating requests.
RecipientPicker (заявления):
- Added pagination support to load ALL users (not just first page)
- Added avatar images from media URLs instead of base64
- Falls back to initials when no avatar available
- Loads users in batches of 100 per page
RecipientPickerHandler (чаты):
- Added pagination support for full user list
- Keeps existing avatar display logic
- Loads 100 users per page when not searching
- Limits to 20 results when searching
CSS improvements:
- Added styles for avatar images (.user-avatar-img)
- Added placeholder styles for initials
- Proper object-fit and border-radius for avatars
