Thunderstore
Thunderstore copied to clipboard
Comments backend
Codecov Report
Merging #196 (7e5866f) into master (e680345) will increase coverage by
0.14%
. The diff coverage is86.25%
.
@@ Coverage Diff @@
## master #196 +/- ##
==========================================
+ Coverage 83.77% 83.91% +0.14%
==========================================
Files 93 97 +4
Lines 2971 3097 +126
Branches 307 321 +14
==========================================
+ Hits 2489 2599 +110
- Misses 399 409 +10
- Partials 83 89 +6
Impacted Files | Coverage Δ | |
---|---|---|
django/thunderstore/core/utils.py | 82.50% <33.33%> (-6.39%) |
:arrow_down: |
django/thunderstore/social/views.py | 51.92% <50.00%> (+0.94%) |
:arrow_up: |
django/thunderstore/repository/models/comment.py | 81.48% <81.48%> (ø) |
|
django/thunderstore/repository/models/thread.py | 84.21% <84.21%> (ø) |
|
django/thunderstore/account/tasks.py | 91.30% <91.30%> (ø) |
|
django/thunderstore/repository/comment.py | 94.00% <94.00%> (ø) |
|
...go/thunderstore/community/forms/package_listing.py | 100.00% <100.00%> (ø) |
|
...o/thunderstore/community/models/package_listing.py | 91.07% <100.00%> (+0.16%) |
:arrow_up: |
django/thunderstore/repository/models/__init__.py | 100.00% <100.00%> (ø) |
|
... and 3 more |
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 e680345...7e5866f. Read the comment docs.
Missing tests but it should be reviewable. Especially unsure on how to organise the logic, e.g. where to put comment deleting (possibly letting members/owners of the identity delete comments from random people on their packages) and if the structure of the forms make sense. I imagine the edit form being integrated into the main package page but you might need an edit form for every comment so an API endpoint could make more sense
Not sure what's happening with the test fail, I've stepped through and the author is definitely being set, just not actually saved for some reason.
Feedback on Discord:
Change the generic foreign key to a Thread
model, where you have a relationship like PackageListing
-> Thread
-> Comment[]
.
Thread
s could probably be made on demand part of the create comment form (as opposed to when creating a package listing or a signal).
I think with this structure, replies can be part of the same system as regular threads. Original thread about replies.
Any info on the state of this?
This'll be picked up again once the new website frontend is out, since the plan is to never add the feature to the legacy (current) website to avoid duplicate work.