feat: Serving event invoices through a protected route

[mrsaicharan1]

Fixes #6144

Short description of what this resolves:

This route serves event invoices in the same way the order invoices and tickets are served. It allows event organizers to access their respective event invoices.
Allows staff members to download/view them.

Changes proposed in this pull request:

• Added route to serve event invoices
• Added security checks to enable access-control for these invoices & only allow authenticated event organisers & staff members to access them.

Checklist

• I have read the Contribution & Best practices Guide and my PR follows them.
• My branch is up-to-date with the Upstream development branch.
• The unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

• All the functions created/modified in this PR contain relevant docstrings

[houndci-bot]

expected 2 blank lines, found 5

[houndci-bot]

redefinition of unused 'event_invoices' from line 349

[codecov]

Codecov Report

Merging #6145 into development will decrease coverage by 0.03%.
The diff coverage is 23.8%.

@@               Coverage Diff               @@
##           development    #6145      +/-   ##
===============================================
- Coverage         66.1%   66.07%   -0.04%     
===============================================
  Files              288      288              
  Lines            14484    14503      +19     
===============================================
+ Hits              9575     9583       +8     
- Misses            4909     4920      +11

Impacted Files	Coverage Δ
app/api/auth.py	23.88% <23.8%> (-0.24%)	⬇️
app/api/helpers/scheduled_jobs.py	24.8% <0%> (+3.19%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f352525...f602c4d. Read the comment docs.

[mrsaicharan1]

@iamareebjamal @uds5501 @shreyanshdwivedi Please have a look at this as it is ready now.
Also, @shreyanshdwivedi , I think you can test your basic design layout for the event invoice once this is merged.

[poush]

The title of this PR seems misleading xD. Instead of "secure", it can be simply "protected" or "restricted"

[poush]

There are better design methods that you can consider. For eg:

if not current_user:
    raise Forbidden error

There will be no unnecessary if-else ladder

[mrsaicharan1]

@poush This if-else ladder is required because at each stage, we are validating the user & the corresponding permissions. If there is any violation at any point, we throw the appropriate exception.

The example given by you is more or less the equivalent of my logic. If we use

if not current_user:
    raise Forbidden error

we would then have to proceed with the checks in the else block (similar to what I've implemented)

else if current_user.is_staff and current_user.is_verified:
                ...

[iamareebjamal]

we would then have to proceed with the checks in the else block

No you won't
You can assume from the next line that current_user is present, removing the need of nested conditions

[mrsaicharan1]

we would then have to proceed with the checks in the else block

No you won't
You can assume from the next line that current_user is present, removing the need of nested conditions

Won't the nesting still be present to check for current_user.is_verified & other cases?

[iamareebjamal]

if current_user:
  # 1 level nesting
  if current_user.is_verified:
    # 2 level
  else:
    # 2 level
    throw
else:
  # 1 level
  throw

Max Level 2
Conditions 4

if not current_user:
  throw

if current_user.is_verified:
  throw

# continue

Max level nesting: 0
Conditions 2

[mrsaicharan1]

@iamareebjamal @poush Understood! Will be updating this.

[mrsaicharan1]

@iamareebjamal @poush THis is ready for another review