website/migrations/0243_add_bacon_rewards_to_challenges.py (1)

26-28: Use Django's migration logger instead of print statements.

Print statements in migrations can clutter output and aren't captured in logs. Consider using Django's migration framework logging.

-            print(f"Updated challenge '{challenge_title}' with {bacon_reward} bacon reward")
+            # Silent update - migrations should run quietly
         except Challenge.DoesNotExist:
-            print(f"Challenge '{challenge_title}' not found, skipping...")
+            # Challenge not found - expected for new installations
+            pass

website/challenge_signals.py (1)

166-167: Hardcoded challenge titles are fragile.

Using hardcoded challenge titles makes the code brittle. If challenge titles change in the database, this code will silently fail.

Consider using challenge slugs or IDs instead of titles, or define these as constants that can be referenced both here and in data migrations.

website/templates/staking/create_pool.html (2)

131-144: Add client-side validation for stake amount.

The form allows entering values beyond the user's balance until server-side validation catches it.

           <input
             type="number"
             id="stake_amount"
             name="stake_amount"
             min="1"
             max="{{ user_bacon_balance }}"
             required
             class="w-full px-3 py-2 border border-gray-300 rounded-lg focus:ring-2 focus:ring-orange-500 focus:border-orange-500"
             placeholder="50"
+            oninput="this.setCustomValidity(this.value > {{ user_bacon_balance }} ? 'Stake amount cannot exceed your BACON balance' : '')"
           />

---

219-219: Validate numeric input in JavaScript.

Using parseFloat without validation could lead to NaN values.

-      const stakeAmount = parseFloat(stakeAmountInput.value) || 0;
+      const stakeAmount = Math.max(0, parseFloat(stakeAmountInput.value) || 0);

website/templates/staking/leaderboard.html (2)

147-223: Inconsistent variable naming between top_users and leaderboard_users.

The template uses top_users for the podium section but leaderboard_users for the full table, which suggests potential data duplication or inconsistent naming patterns.

Consider using a single users variable with template slicing for better consistency:

-    {% for user in top_users|slice:":3" %}
+    {% for user in users|slice:":3" %}
     <!-- podium content -->
     {% endfor %}

-    {% for user in leaderboard_users %}
+    {% for user in users %}
     <!-- table content -->
     {% endfor %}

This would eliminate potential confusion and reduce memory usage from duplicate data.

---

192-208: Use default filter consistently across all user data fields.

Some fields use the default filter while others don't, creating inconsistent behavior when data is missing.

Apply the default filter consistently:

-                  {{ user.total_winnings|default:0 }} BACON
+                  {{ user.total_winnings|default:0 }} BACON
                 <!-- This one is already correct -->

-                  {{ user.total_wins|default:0 }}
+                  {{ user.pools_won|default:0 }}
                 <!-- Fix variable name inconsistency too -->

-                  {{ user.total_competitions|default:0 }}
+                  {{ user.total_competitions|default:0 }}
                 <!-- This one is already correct -->

website/templates/staking/staking_home.html (1)

12-12: Use proper numeric formatting for BACON balance display.

The balance uses floatformat:0 which removes decimal places but doesn't handle large numbers gracefully. Consider using floatformat:0|floatformat or a custom filter for better number formatting.

-          {{ user_bacon_balance|floatformat:0 }} BACON
+          {{ user_bacon_balance|floatformat:0|floatformat }} BACON

Or create a custom template filter for currency-like formatting that includes thousand separators.

website/templates/staking/stake_form.html (2)

91-107: Quick select buttons could be more dynamic.

The quick select buttons are hardcoded to specific amounts (100, 500) which may not be appropriate for all pool types or user balances.

Make the quick select amounts more dynamic:

-              {% if user_balance >= 100 %}
               <button
                 type="button"
                 class="quick-amount bg-gray-100 hover:bg-gray-200 px-4 py-2 rounded-lg text-sm font-medium transition-colors"
-                data-amount="100"
+                data-amount="{{ user_balance|floatformat:0|mul:0.25|floatformat:0 }}"
               >
-                100 BACON
+                25% Balance
               </button>
-              {% endif %} {% if user_balance >= 500 %}
               <button
                 type="button"
                 class="quick-amount bg-gray-100 hover:bg-gray-200 px-4 py-2 rounded-lg text-sm font-medium transition-colors"
-                data-amount="500"
+                data-amount="{{ user_balance|floatformat:0|mul:0.5|floatformat:0 }}"
               >
-                500 BACON
+                50% Balance
               </button>
-              {% endif %}

Note: This requires implementing a mul template filter or calculating these values in the view.

---

222-236: JavaScript validation uses unsafe string concatenation in alerts.

The alert messages concatenate user input without sanitization, which could lead to unexpected behavior with special characters.

Use template literals for safer string formatting:

           if (amount < minAmount) {
               e.preventDefault();
-              alert('Minimum stake amount is ' + minAmount + ' BACON');
+              alert(`Minimum stake amount is ${minAmount} BACON`);
               return;
           }

           if (amount > userBalance) {
               e.preventDefault();
-              alert('You don\'t have enough BACON. Available: ' + userBalance + ' BACON');
+              alert(`You don't have enough BACON. Available: ${userBalance} BACON`);
               return;
           }

website/templates/staking/my_staking.html (2)

154-169: Unstaking confirmation uses basic JavaScript confirm dialog.

The onclick="return confirm()" approach provides minimal user experience and doesn't allow for custom styling or additional information about the unstaking consequences.

Replace with a custom modal for better UX:

-                    <button
-                      type="submit"
-                      class="text-red-600 hover:text-red-900"
-                      onclick="return confirm('Are you sure you want to unstake?')"
-                    >
+                    <button
+                      type="button"
+                      class="text-red-600 hover:text-red-900"
+                      onclick="showUnstakeModal('{{ entry.id }}', '{{ entry.amount }}', '{{ entry.pool.name }}')"
+                    >
                       Unstake
                     </button>

And add a custom modal with detailed information about unstaking consequences.

---

210-218: Inconsistent emoji usage for transaction types.

The transaction type indicators use emojis (📈, 📉, 🏆) which may not render consistently across different browsers and operating systems.

Replace emojis with consistent icon fonts:

                 {% if transaction.transaction_type == 'stake' %}
-                <span class="text-blue-600">📈</span>
+                <i class="fas fa-arrow-up text-blue-600"></i>
                 {% elif transaction.transaction_type == 'unstake' %}
-                <span class="text-red-600">📉</span>
+                <i class="fas fa-arrow-down text-red-600"></i>
                 {% else %}
-                <span class="text-green-600">🏆</span>
+                <i class="fas fa-trophy text-green-600"></i>
                 {% endif %}

website/views/staking_competitive.py (4)

1-24: Remove unused imports.

Static analysis correctly identified unused imports that should be removed to keep the code clean.

 from django.shortcuts import render, get_object_or_404, redirect
 from django.contrib.auth.decorators import login_required
 from django.contrib import messages
-from django.http import JsonResponse
 from django.utils import timezone
 from django.db import transaction
 from django.db.models import Q, Sum, F, Count, Case, When, IntegerField
 from django.views.decorators.http import require_http_methods
 from decimal import Decimal
 from datetime import timedelta
-import json
 
 from ..models import (
     StakingPool, 
     StakingEntry, 
     StakingTransaction, 
     Challenge, 
     BaconEarning,
     Issue,
     IpReport,
     TimeLog
 )
-from ..feed_signals import giveBacon

---

82-141: Consider optimizing database queries with prefetch_related.

The view makes multiple queries and loops through pools to add user-specific data. This could be optimized.

-    # Get pools by status
-    open_pools = StakingPool.objects.filter(status='open').order_by('-created_at')
-    full_pools = StakingPool.objects.filter(status='full').order_by('-created_at')
-    active_pools = StakingPool.objects.filter(status='active').order_by('-created_at')
-    completed_pools = StakingPool.objects.filter(status='completed').order_by('-completed_at')[:5]
+    # Get all pools with prefetched entries for the current user
+    from django.db.models import Prefetch
+    
+    user_entries = Prefetch(
+        'entries',
+        queryset=StakingEntry.objects.filter(user=request.user),
+        to_attr='user_entries'
+    )
+    
+    all_pools = StakingPool.objects.prefetch_related(user_entries).order_by('-created_at')
+    
+    # Filter pools by status
+    open_pools = [p for p in all_pools if p.status == 'open']
+    full_pools = [p for p in all_pools if p.status == 'full']
+    active_pools = [p for p in all_pools if p.status == 'active']
+    completed_pools = [p for p in all_pools if p.status == 'completed'][:5]

---

144-229: Consider extracting progress circle calculation to a utility function.

The progress circle calculation logic (circumference, stroke-dasharray, stroke-dashoffset) appears to be duplicated from user_challenges. Also, calculating progress for each participant individually could be slow for large pools.

Extract the progress circle calculation to a reusable utility:

# In a utils.py file
def calculate_progress_circle_attrs(progress_percentage):
    """Calculate SVG circle attributes for progress visualization."""
    circumference = 125.6
    return {
        'stroke_dasharray': circumference,
        'stroke_dashoffset': circumference - (circumference * progress_percentage / 100)
    }

For performance, consider bulk-fetching the data needed for progress calculation rather than querying per participant.

---

232-255: Remove unnecessary f-string prefix.

Good use of atomic transactions for the join operation. Just need to fix the f-string without placeholders.

-                    messages.info(request, f"Pool is now full! Challenge will begin soon.")
+                    messages.info(request, "Pool is now full! Challenge will begin soon.")

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Knowledge Base: Disabled due to Reviews > Disable Knowledge Base setting