website/views/user.py (1)

1719-1794: start_thread flow looks correct; consider tightening a couple of edges

The locked/unlocked split, single-email behaviour via email_sent, and thread creation all look consistent with the new ChatRequest model and the front-end expectations.

Two non-blocking tweaks you may want to consider:

• Add a cheap guard against self-chat to avoid weird UX like emailing a user to unlock their own chat with themselves:

@login_required
def start_thread(request, user_id):
    if request.method != "POST":
        return JsonResponse({"success": False, "error": "Invalid request"}, status=400)

    current_user = request.user
    other_user = get_object_or_404(User, id=user_id)
+
+    if other_user == current_user:
+        return JsonResponse({"success": False, "error": "Cannot start a thread with yourself"}, status=400)

• If there’s any chance other_user.userprofile might be missing, you could defensively handle UserProfile.DoesNotExist instead of relying on the getattr shortcut; this is in line with other assumptions in this file though, so treat it as optional.

website/views/core.py (1)

49-77: User search + pending-request wiring is sound; small UX gaps you may want to close

The changes to search() correctly:

• Load users with their UserProfile and scores.
• Compute sent_requests via ChatRequest for the current user.
• Attach has_pending_request and badges to each user object for the type='users' view, matching the template’s expectations.

Two minor UX details to consider (not blockers):

1. type='all' search doesn’t reflect pending requests

   For the "all" search path, users is a plain queryset of User without the has_pending_request flag or badges attached. The template’s “Users” section still renders for that case and will therefore always show “Request Chat” instead of “Request Sent” even when a ChatRequest already exists.

   If you want consistent behaviour between "all" and "users" searches, you could reuse the same sent_requests/users_list construction for the "all" case (or refactor into a helper used by both paths).

2. Distinguishing “request exists but no email was sent” (optional)

   has_pending_request is currently keyed purely on the presence of a ChatRequest. In the rare case where a request was created while receiver.email was empty, the UI will still show “Request Sent” later even though no email was ever delivered. If that distinction matters, you might drive the “Request Sent” label from email_sent (and potentially allow re-request if email_sent is still false).

Overall the logic is correct; these are UX-level refinements you can choose to defer.

Also applies to: 603-669

website/templates/search.html (1)

322-340: Unified Message / Request Chat UI matches backend; only nit is some dead class handling

The template + JS wiring lines up nicely with the new start_thread JSON API:

• Correctly shows:
  • “Message” when user.userprofile.public_key exists.
  • Disabled “Request Sent” when user.has_pending_request is true.
  • “Request Chat” otherwise, using the same POST endpoint and relying on data.locked vs data.success to decide between “Request Sent” and redirect.
• CSRF handling via getCookie("csrftoken") and POST is appropriate for this view.

One tiny clean-up you may want to make:

• In the locked branch you call:

  this.classList.remove("bg-[#e74c3c]", "hover:bg-[#c0392b]");
  this.classList.add("bg-red-500", "cursor-not-allowed");

  but none of the current buttons use bg-[#e74c3c] or hover:bg-[#c0392b] anymore, so those removes are no-ops. You could either update the removals to match the current grey/indigo classes (if you want to normalise the visual state) or just drop the classList.remove call entirely to reduce noise.

Behaviour-wise everything is solid.

Also applies to: 785-848

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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

website/models.py (1)

909-969: UserProfile.slug should be slugified and collision-safe (issue already raised previously)

UserProfile.slug is a SlugField(unique=True, …), but save() assigns self.user.username directly:

if not self.slug:
    self.slug = self.user.username

Django usernames can contain characters (@, ., +, etc.) that are invalid for SlugField validators and URL slug converters, and this also doesn’t handle collisions if you later derive slugs differently. This matches the concern in the earlier review comment that suggested using slugify() instead of raw username.

A safer implementation would mirror the slug logic used on Organization/Repo:

class UserProfile(models.Model):
@@
-    slug = models.SlugField(unique=True, blank=True, null=True)
+    slug = models.SlugField(unique=True, blank=True, null=True)
@@
-    def save(self, *args, **kwargs):
-        if not self.slug:
-            self.slug = self.user.username
-        super().save(*args, **kwargs)
+    def save(self, *args, **kwargs):
+        if not self.slug and self.user_id:
+            # Start from a slugified username
+            base_slug = slugify(self.user.username)
+            if not base_slug:
+                base_slug = f"user-{self.user_id}"
+
+            self.slug = base_slug
+            counter = 1
+            while UserProfile.objects.filter(slug=self.slug).exclude(pk=self.pk).exists():
+                self.slug = f"{base_slug}-{counter}"
+                counter += 1
+
+        super().save(*args, **kwargs)

This preserves existing custom slugs, ensures the value is a valid slug, and avoids collisions.

Check Django’s `SlugField` and `slugify` documentation to confirm valid characters for slugs and common patterns for generating unique slugs from usernames.

website/models.py (2)

3092-3106: ChatRequest model is solid; optional CheckConstraint to prevent self-requests

The ChatRequest model structure (ForeignKeys to AUTH_USER_MODEL, unique_together = ("sender", "receiver"), and clear __str__) is well-designed.

If your domain requires preventing users from requesting a chat with themselves, you can add a DB-level check constraint:

class ChatRequest(models.Model):
     created_at = models.DateTimeField(auto_now_add=True)

     class Meta:
         unique_together = ("sender", "receiver")
+        constraints = [
+            models.CheckConstraint(
+                check=~models.Q(sender=models.F("receiver")),
+                name="chatrequest_sender_not_receiver",
+            ),
+        ]

Django 5.2.x fully supports this constraint pattern with F() expressions. Alternatively, add validation in the view/service layer if preferred.

---

909-909: Consider consolidating timezone handling between UserProfile and ReminderSettings

Both models define identical timezone = models.CharField(max_length=50, default="UTC") fields. However, ReminderSettings has proper validation via its save() method (which uses pytz.timezone()) and provides get_timezone_choices() returning pytz.common_timezones. UserProfile.timezone lacks this validation and integration. To avoid divergence, either reuse ReminderSettings' timezone approach in UserProfile or consolidate to a single timezone management pattern across both models.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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