apiserver/plane/utils/analytics_plot.py (2)

Line range hint 206-212: Approved: Improved date range calculation for modules

The changes to the date range calculation for modules are well-implemented and align with the module's structure. Using target_date instead of end_date is more appropriate for modules, and the simplified timedelta usage is more efficient.

For consistency, consider updating the date comparison later in the function:

if date > timezone.now().date():

to:

if date > timezone.now():

This change would make the comparison consistent with the new timedelta objects and eliminate the need for the .date() call.

---

Line range hint 206-212: Overall improvement: Enhanced module support in burndown_plot

The changes successfully improve the burndown_plot function's handling of modules by using the appropriate target_date and simplifying the date range calculation. This enhancement doesn't affect the existing cycle-related logic, maintaining the function's versatility.

To further improve code clarity and maintainability, consider extracting the date range calculation into a separate helper function for both cycle and module cases. This would reduce code duplication and make future modifications easier. For example:

def calculate_date_range(start_date, end_date):
    return [
        start_date + timedelta(days=x)
        for x in range((end_date - start_date).days + 1)
    ]

# Usage in the function:
if cycle_id:
    date_range = calculate_date_range(queryset.start_date, queryset.end_date) if queryset.end_date and queryset.start_date else []
elif module_id:
    date_range = calculate_date_range(queryset.start_date, queryset.target_date)

This refactoring would make the code more DRY (Don't Repeat Yourself) and easier to maintain.

Configuration used: CodeRabbit UI
Review profile: CHILL

apiserver/plane/app/views/view/base.py (3)

Line range hint 471-479: Use appropriate HTTP status code and error message

In the retrieve method, when a guest user is not allowed to view the issue view, the response returns a status code of 400 Bad Request. It's more appropriate to return a 403 Forbidden status code to indicate that the server understood the request but refuses to authorize it. Additionally, update the error message to accurately reflect the resource.

Proposed change:

              return Response(
-                 {"error": "You are not allowed to view this issue"},
-                 status=status.HTTP_400_BAD_REQUEST,
+                 {"error": "You are not allowed to view this view"},
+                 status=status.HTTP_403_FORBIDDEN,
              )

---

Line range hint 509-513: Return 403 Forbidden instead of 400 Bad Request for unauthorized access

When a user who is not the owner attempts to update the view, the response returns a 400 Bad Request. It's more appropriate to return a 403 Forbidden status code in this case.

Proposed change:

          if issue_view.owned_by_id != request.user.id:
              return Response(
                  {
                      "error": "Only the owner of the view can update the view"
                  },
-                 status=status.HTTP_400_BAD_REQUEST,
+                 status=status.HTTP_403_FORBIDDEN,
              )

---

Line range hint 542-546: Return 403 Forbidden instead of 400 Bad Request when deletion is unauthorized

If a user who is neither an admin nor the owner attempts to delete a view, a 400 Bad Request is returned. Update the status code to 403 Forbidden to correctly indicate the authorization error.

Proposed change:

          else:
              return Response(
                  {"error": "Only admin or owner can delete the view"},
-                 status=status.HTTP_400_BAD_REQUEST,
+                 status=status.HTTP_403_FORBIDDEN,
              )

Configuration used: CodeRabbit UI
Review profile: CHILL