DBC22-7096: Create basic workflow for CCP on Ride FE and BE

[bcgov-brwang]

This PR integrates the CCP features into RIDE and includes the following implemented functionality.
For reference, I have also included links to the relevant wireframes and UI designs.

Create workflow of CCP:
https://moti-imb.atlassian.net/browse/DBC22-7096

Cameras overview:
https://moti-imb.atlassian.net/browse/DBC22-7099
https://moti-imb.atlassian.net/browse/DBC22-7100
https://moti-imb.atlassian.net/browse/DBC22-7104
https://moti-imb.atlassian.net/browse/DBC22-7106
https://moti-imb.atlassian.net/browse/DBC22-7232
https://moti-imb.atlassian.net/browse/DBC22-7105
https://moti-imb.atlassian.net/browse/DBC22-7101
https://moti-imb.atlassian.net/browse/DBC22-7396

Camera details:
https://moti-imb.atlassian.net/browse/DBC22-7148
https://moti-imb.atlassian.net/browse/DBC22-7152
https://moti-imb.atlassian.net/browse/DBC22-7153
https://moti-imb.atlassian.net/browse/DBC22-7155

Camera manage settings:
https://moti-imb.atlassian.net/browse/DBC22-7219
https://moti-imb.atlassian.net/browse/DBC22-7218

Wireframes:
https://www.figma.com/design/3jGqiZv1mNwArO0TUzDNvV/RIDE-Wireframes?node-id=4708-24157&t=JWTiXIGmiXzo1OFL-0

UI design:
https://www.figma.com/design/T60vAzhOfq0rmUGnmR2zXz/RIDE-UI-Design?node-id=1-20781&t=97yhj217SEr6R4YL-0

Test steps:

1. Deploy the latest version to the RIDE Dev environment.

2. Verify the implemented features against the wireframes and UI design.
   Review the implementation list and confirm that each feature has been implemented as expected. There are some inconsistencies between the wireframes and the UI design. Where differences exist, the implementation should follow the UI design.

3. Verify CCP camera overview, details and database settings modules:

   For testing purposes, follow the basic CCP workflow, including:

   • Creating a new camera
   • Updating an existing camera
   • Deleting a camera
   • Setting up database data through Manage Settings → Database Setup
   • Configuring Default Messaging
   • Verifying other available settings and related workflows

   The goal is to verify that the main workflows function correctly from the UI through to the backend and database.

[ray-oxd]

Here are the suggested blockers and should-fix items suggested by a coding agent. I've reviewed these and most of these seem valid. Please address:

1. Many camera endpoints are open to anonymous users. The repo sets no default permission in config/settings/third_party.py, so any viewset without its own permission class lets anyone in. Django REST Framework also skips its CSRF check for anonymous requests, so these accept writes from anyone. Affected, in apps/cameras/views.py:

• BulkUpdateViewSet and all its subclasses (about line 52). Anyone can call PUT /api//bulk-update/ with an empty list, which deactivates every region, road, contractor and so on.
• CameraLogViewSet (about line 743): full create, update and delete, no authentication.
• CameraHistoryViewSet (about line 645): exposes users' full names.
• CameraReportSettingsViewSet, ServiceRequestCcsViewSet, CameraDefaultMessagingViewSet and CamerasOrderViewSet (about lines 753–870).
• CameraNoteViewSet only requires login, not the camera role. Also, only edits check the author, so any logged-in user can delete anyone's note.

Suggested fix: reads need IsCameraRole, writes need IsCameraAdmin, the same pattern CameraViewSet already uses.

2. The config/adapter.py change likely breaks account linking. pre_social_login now reads sociallogin.account.extra_data directly instead of calling get_oidc_claims(). On main, the claims are nested under userinfo, so identity_provider comes back None and the function quietly returns early. Imported users would stop being linked to their SSO accounts. populate_user and the rest of the code still use get_oidc_claims, so this looks like a merge or rebase leftover. It's unrelated to CCP and should be reverted.

3. Camera device passwords are stored in plain text and sent to every camera-role user. Camera.password (models.py about line 281) is serialized because CameraSerializer uses fields='all'. The detail page then loads it into form state. It should at least be write-only in the API, and ideally stored encrypted.

4. frontend/app/layout.jsx has a broken comparison. About line 106:
   if (ret.is_camera_role != prior.is_camera_role || prior.is_camera_admin) { return ret; }
   This always returns a new object for camera admins, causing extra re-renders. The PR also deleted the request_organization comparison, so changes to that field no longer update the auth context. That's a regression in existing behaviour.

5. The detail page's one-minute refresh overwrites unsaved edits. In CameraDetails.jsx (about line 443), loadCamera() calls setBasicsData and setSetupData unconditionally every minute. A user who is mid-edit loses their changes. The same block also has console.log of a Promise.

6. Camera logs are written by the browser. "Image received / No image received" entries are created by CameraDetails only when someone has the page open. Each open tab writes its own copy, so you get duplicates with several viewers and nothing when nobody is looking. This belongs in a backend task. The client also sends a view field, which CameraLogSerializer drops.

7. The timelapse-image endpoint passes user input into the upstream URL. The timestamp query parameter goes into the URL unvalidated, and that request carries the API key (about line 546). The webcam_id in image-proxy has the same problem. Both should be checked to be digits only.

8. CSV export has wrong field mappings. In EXPORT_FIELD_MAP, these keys always come out blank because the field names don't match the model:
   Export key
   Actual model field
   elevation
   locations_elevation
   installed_date
   camera_installed
   last_inspected
   camera_last_inspected
   camera_url, camera_views, view_descriptions, weather_stations and geotechnical_sensors don't exist on the model at all. notes is worse: it writes the related-manager object's text representation into the CSV instead of the notes.

9. New required settings will break existing environments. DRIVEBC_TIMELAPSE_API_KEY and DRIVEBC_TIMELAPSE_API_ROOT are read with env() and no default, so Django won't start until every deployment config adds them. CI was updated; dev, test and prod config need the same. A default like the other API settings in third_party.py would avoid this.

10. The Dockerfile change adds weight and may break Apple Silicon builds. It installs the Microsoft SQL Server ODBC driver (msodbcsql18) and pyodbc into the main webapp image only for the one-time import_legacy_cameras command. The apt source is hard-coded to arch=amd64, which will probably fail on M-series Macs. A separate image or job for the import would avoid both problems.

11. Migrations should be squashed. The new app ships 13 migrations (0001–0013), including renames and alters made during development. Collapse them into a single 0001_initial before the first merge. The organizations/0009 migration (ServiceArea ordering) is unrelated to this work.

12. The nginx /drivebc-api/ block is an open proxy. It forwards any path to www.drivebc.ca with no authentication. The frontend could go through the backend instead, which already proxies images.

[sonarqubecloud]

Quality Gate passed

Issues
17 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.6% Duplication on New Code

See analysis details on SonarQube Cloud