-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Feedback system #31
base: main
Are you sure you want to change the base?
Conversation
Just to clarify - this is feedback for PENDING mods, to be given by verified devs/admins. This isn't for public use. |
@qimiko I've updated the comment with the new changes using the osu-like system you requested. |
I'll take a look at this today when I'm back from work, looks good at first glance |
alright thanks. @qimiko had already given me some improvements which i implemeted this morning. appreciate it! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, just some small nitpicks I personally had. We should also think about implementing something clientside for this
Alright, I applied the first 3 changes. I'm still not sure why "latest" bugs, but I'll look into it now. |
Latest is now fixed. Let me know if you need anything else! |
I've just added a delete endpoint. |
ok so i made like a million reviews i'm sorry 😭 but i left my thoughts on the current prq. you're free to question anything i say |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very close 🙂 these specifically are my thoughts on what was added
feedback TEXT COLLATE pg_catalog."default" NOT NULL, | ||
decision BOOLEAN NOT NULL DEFAULT false, | ||
type feedback_type NOT NULL, | ||
dev bool NOT NULL DEFAULT false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could get a little confusing, considering that "this person is a developer of this mod" is not constant. i'd rather this check be done during the sql query (like the admin field) instead of stored in the table
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah alr
} | ||
|
||
#[delete("/v1/mods/{id}/versions/{version}/feedback")] | ||
pub async fn delete_mod_feedback( | ||
data: web::Data<AppData>, | ||
path: web::Path<GetModFeedbackPath>, | ||
payload: web::Json<DeleteModFeedbackPayload>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of payload, put the id as part of the path:
/v1/mods/{id}/versions/{version}/feedback/{feedback_id}
this is more consistent with the rest of the api and also consistent with what a delete request is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah ok
@@ -112,34 +109,31 @@ pub async fn post_mod_feedback( | |||
.await | |||
.or(Err(ApiError::TransactionError))?; | |||
|
|||
Ok(HttpResponse::NoContent()) | |||
Ok(web::Json(ApiResponse { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this behavior is somewhat inconsistent considering the rest of the post endpoints don't do this, but i can see why you did it. i'll probably think about it further
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, i'll leave it as it is rn then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on second thought, nocontent is probably the generally the best move
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how would you get the id? through the GET endpoint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ye, i think if the get feedback returns the author's feedback as well, then it makes it easy to associate feedback with the id on the client (so they can delete)
i wouldn't assume people are storing the id locally anyways
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
src/types/models/mod_feedback.rs
Outdated
WHERE mf.mod_version_id = "# | ||
); | ||
query_builder.push_bind(version.id); | ||
if dev_only { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i was thinking about this a little more and i think it'd be better to allow returning the current user's feedback as well, like instead of dev_only
you have filter_user: Option<i32>
where None
shows all feedback and having some value returns the feedback by that user id + the dev
so it doesn't just seem like your feedback was thrown into the void
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alr
Feedback system
New Endpoints:
GET
/v1/mods/{id}/versions/{version}/feedback
:Get mod feedback - only accessible to mod dev or admins
Example Response
POST
/v1/mods/{id}/versions/{version}/feedback
:Add/update mod feedback - only accessible to verified devs and admins (mod devs can only leave notes)
Request Body Example
DELETE
/v1/mods/{id}/versions/{version}/feedback
:Delete feedback.
Request Body Example
New Tables:
mod_feedback
Columns:
mod_version_id
: Mod version ID, NOT mod version stringreviewer_id
: Developer ID of reviewerfeedback
: Feedback stringdecision
: Whether this feedback decided the status of the modtype
: Positive, Negative, Suggestion or NoteNotes: