website/tests/test_user_activity_model.py (1)

7-39: Consider expanding test coverage for completeness.

The existing tests validate core functionality well. Consider adding tests for:

• Timestamp auto-generation behavior
• Default values for optional fields (ip_address, user_agent, metadata)
• Organization-scoped string representation
• Edge cases like activities without organization

website/tests/test_analytics_view.py (1)

10-42: Consider adding edge case and integration tests.

The current test validates the happy path well. Consider adding:

• Test for organizations with no activities (verify empty states)
• Test for activities older than 30 days (verify they're excluded)
• Integration test that verifies context injection in the full view
• Assertions on specific calculated values (e.g., engagement_rate formula)

website/management/commands/aggregate_user_analytics.py (1)

16-17: Consider making retention period configurable.

The 90-day retention period is hardcoded. Consider making it configurable via settings (e.g., settings.USER_ACTIVITY_RETENTION_DAYS) or a command argument to allow flexibility without code changes.

🔎 Example implementation:

from django.conf import settings

def handle(self, *args, **options):
    """Clean up old UserActivity records."""
    try:
        # Use settings value with 90 as default
        retention_days = getattr(settings, 'USER_ACTIVITY_RETENTION_DAYS', 90)
        cutoff_date = timezone.now() - timedelta(days=retention_days)

website/tests/test_management_commands.py (1)

29-29: Rename command to reflect cleanup-only functionality.

The command aggregate_user_analytics only performs cleanup (deleting records older than 90 days), not aggregation. The name is misleading about its actual purpose. Consider renaming to cleanup_user_activities or similar to improve clarity.

website/views/company.py (1)

40-41: User behavior analytics helper is solid; consider minor query reuse/index tuning.

The get_user_behavior_analytics logic is correct and aligns with the dashboard requirements (30‑day aggregates, 7‑day trend, top users, breakdown, peak hours, and engagement rate with a zero guard).

Two optional improvements you might consider, especially if UserActivity grows large:

• Reuse the 30‑day activities queryset for weekly data, e.g. weekly_activities = activities.filter(timestamp__gte=seven_days_ago), to avoid re-hitting the base table.
• If analytics queries begin to dominate, a composite index on (organization, timestamp) (in addition to the existing ones) would better support the common organization=..., timestamp__gte=... filters.

Also applies to: 791-793, 795-862

website/middleware.py (1)

4-13: Clarify logger usage and remove misleading org_ref fallback; tracking logic itself looks good.

• You assign logger twice: first with __name__, then with "slack_bolt" and set it to WARNING. As a result, ActivityTrackingMiddleware’s logger.debug(...) messages are effectively lost and share the Slack logger. If you want separate logging, consider a dedicated logger (e.g., activity_logger = logging.getLogger(__name__)) instead of reusing the Slack one.
• _get_organization_from_request falls back to request.session["org_ref"], but elsewhere org_ref is a referral code string, not an organization id. That fallback is at best a no‑op and at worst confusing for future readers; you can safely drop it unless you plan to store an explicit organization id in the session.

The rest of the middleware (URL pattern detection, IP extraction, organization resolution from path, and safe best‑effort UserActivity creation) looks correct and appropriately guarded with try/except.

Possible cleanups

-import logging
-import re
+import logging
+import re
@@
-from website.models import Organization, UserActivity
-
-logger = logging.getLogger(__name__)
+from website.models import Organization, UserActivity
+
+activity_logger = logging.getLogger(__name__)
@@
-logger = logging.getLogger("slack_bolt")
-logger.setLevel(logging.WARNING)
+logger = logging.getLogger("slack_bolt")
+logger.setLevel(logging.WARNING)
@@
-            except Exception as e:
+            except Exception as e:
                 # Silent failure - don't break the request
-                logger.debug("Failed to track dashboard visit: %s", type(e).__name__)
+                activity_logger.debug("Failed to track dashboard visit: %s", type(e).__name__)
@@
-            # Try to get from session
-            org_ref = request.session.get("org_ref")
-            if org_ref:
-                return Organization.objects.filter(id=org_ref).first()
+            # (Optional) If you later store an explicit organization id in session,
+            # handle it here with a clearly named key (e.g., "organization_id").

Also applies to: 45-46, 59-130

website/models.py (1)

3650-3684: UserActivity model is well-structured; consider index tuning for org/time queries.

The UserActivity definition (fields, choices, indexes, __str__) is coherent and matches its usage in middleware, signals, and analytics.

Two small follow‑ups to keep in mind:

• Because user is non‑nullable, all writers (signals, middleware, future utilities) should guard against None before creating records — you’ve already got one such case in Issue.user (see log_bug_report).
• If you find yourself frequently querying by organization and timestamp (as in get_user_behavior_analytics), a composite index on (organization, timestamp) could be more directly supportive than (organization, activity_type) for time‑bounded org analytics.

website/tests/test_activity_middleware.py (1)

32-43: Consider adding test coverage for unauthenticated users.

The test correctly validates that non-dashboard pages aren't tracked. To further strengthen coverage, consider adding a test case for unauthenticated users visiting the dashboard (e.g., request.user = AnonymousUser()) to ensure they're handled appropriately.

🔎 Optional test addition:

def test_unauthenticated_dashboard_not_tracked(self):
    """Test that unauthenticated dashboard visits are not tracked"""
    from django.contrib.auth.models import AnonymousUser
    
    initial_count = UserActivity.objects.count()
    
    request = self.factory.get(f"/organization/{self.org.id}/dashboard/")
    request.user = AnonymousUser()
    request.session = {}
    
    self.middleware(request)
    
    # No activity should be created for unauthenticated users
    self.assertEqual(UserActivity.objects.count(), initial_count)

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

website/middleware.py:89

• Unnecessary 'pass' statement.

                pass

website/activity_signals.py (1)

36-37: Fix the log message: says "bug comment" but should say "bug report".

This is in the log_bug_report handler, but the error message incorrectly references "bug comment activity".

Proposed fix

     except Exception as e:
-        logger.error("Failed to log bug comment activity: %s", str(e), exc_info=True)
+        logger.error("Failed to log bug report activity: %s", str(e), exc_info=True)

website/admin.py (1)

1277-1292: Consider adding has_delete_permission override for full immutability.

The admin correctly prevents adding and changing records, but deletion is still allowed. For complete audit log immutability, consider adding:

Proposed fix

     def has_change_permission(self, request, obj=None):
         # Activity records should be immutable
         return False
+
+    def has_delete_permission(self, request, obj=None):
+        # Activity records should not be deleted via admin
+        return False

website/management/commands/aggregate_user_analytics.py (1)

11-43: Implementation looks good; consider making retention period configurable.

The command properly handles the zero-records case, uses specific DatabaseError handling, and extends LoggedBaseCommand for tracking. The 90-day retention is hardcoded; consider accepting it as a command argument for flexibility.

Optional: Configurable retention period

 class Command(LoggedBaseCommand):
     help = "Clean up (delete) UserActivity records older than 90 days to enforce data retention"

+    def add_arguments(self, parser):
+        parser.add_argument(
+            '--days',
+            type=int,
+            default=90,
+            help='Number of days to retain (default: 90)',
+        )
+
     def handle(self, *args, **options):
         """Clean up old UserActivity records."""
         try:
-            # Calculate cutoff date (90 days ago)
-            cutoff_date = timezone.now() - timedelta(days=90)
+            # Calculate cutoff date
+            retention_days = options.get('days', 90)
+            cutoff_date = timezone.now() - timedelta(days=retention_days)

website/views/company.py (1)

795-861: Well-optimized analytics method with good queryset reuse.

The implementation efficiently:

• Reuses the base 30-day queryset for all aggregations
• Combines total_activities and active_users_count into a single aggregate call
• Properly guards against division by zero for engagement rate

One consideration: weekly_trend_list will only contain entries for days with activity. Days with zero activities won't appear in the list. If the frontend expects all 7 days, you may need to fill in missing dates:

Optional: Fill missing dates in weekly trend

# After building weekly_trend_list, fill gaps:
from datetime import date, timedelta

date_counts = {d["date"]: d["count"] for d in weekly_trend_list}
filled_trend = []
for i in range(7):
    day = (now - timedelta(days=6-i)).date().isoformat()
    filled_trend.append({"date": day, "count": date_counts.get(day, 0)})
weekly_trend_list = filled_trend

website/models.py (1)

3650-3686: UserActivity schema and indexing look good; consider a standalone timestamp index later

Model fields and composite indexes align well with the analytics and middleware queries (user/org/type + recent window), and the 512‑char user_agent plus JSON metadata are appropriate for this use case. As a future optimization, if the retention cleanup command ever becomes slow on large tables, you might add a standalone index on timestamp (or db_index=True) rather than relying only on composite indexes; similarly, bumping activity_type.max_length slightly (e.g., 32–50) would give more headroom for new activity types without another migration, but that’s optional.

website/templates/organization/dashboard/organization_analytics.html (1)

324-450: User Behavior Analytics section is well-integrated; optional layout tweak

The UBA block is correctly guarded by {% if user_behavior %} and matches the rest of the dashboard styling. If you want a denser layout on wider screens, you could change the breakdown/top‑users container from grid-cols-1 to md:grid-cols-2 so those panels sit side‑by‑side on desktop, but that’s purely cosmetic.

website/middleware.py (1)

91-196: ActivityTrackingMiddleware meets the analytics + privacy objectives; only minor hardening possible

The middleware cleanly implements the intended behavior: it tracks only authenticated non‑superusers on org/company dashboard URLs, uses a cache+DB hybrid dedupe window, stores org/user/metadata path, and anonymizes IPs while truncating user agents to fit the 512‑char field. That’s a good balance of accuracy, performance, and privacy for analytics.

Two small, non‑blocking tweaks you might consider:

• In _get_organization_from_request, guard request.session with hasattr(request, "session") so the helper is safe even if used in contexts without SessionMiddleware.
• Adjust the debug log in the except of _get_organization_from_request to something like "Failed to extract organization from request" to distinguish org‑resolution issues from actual tracking failures.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting