Argument votes

[seporterfield]

Write and add tests for the following routes. If they exist already, modify them so they fit our schema.

• [x] arguments/{id}/upvote
• [x] arguments/{id}/upvote/undo
• [x] arguments/{id}/downvote
• [x] arguments/{id}/downvote/undo
• [x] tests

blocked by #293

[seporterfield]

@ndharmateja all yours

[ndharmateja]

@Monstarrrr what should be the response body for these routes?

[ndharmateja]

@Monstarrrr also I am unable to move this issue to "In Progress" is it because of permissions? 🤔

[ndharmateja]

@seporterfield @Monstarrrr @purple-void should the following edge cases be considered?

1. upvote argument
   • when the argument is already upvoted, should an error be raised?
2. upvote argument undo
   • if the existing vote is "downvote", what should be done?
   • if no vote between the user and argument exists, what should be done?

[Monstarrrr]

@Monstarrrr what should be the response body for these routes?

I am in the process of building the Mock API which will contain the response format i'm looking for.
I will let you know asap.
If an issue is blocked by an other it may be a good idea to add ''blocked by #[issue_number]" in the issue body to help with keeping track of dependencies.

[Monstarrrr]

@seporterfield @Monstarrrr @purple-void should the following edge cases be considered?

1. upvote argument
   • when the argument is already upvoted, should an error be raised?
2. upvote argument undo
   • if the existing vote is "downvote", what should be done?
   • if no vote between the user and argument exists, what should be done?

1. In theory i'll make sure an upvote cast can't happen if the item is already upvoted, because clicking this upvote will trigger a /undo, in practice if it were to happen for whatever reason then we'd expect an error

2. If existing vote is a downvote then there is no upvote to undo, so likewise such a call would return an error

3. If no vote exists then there can't be votes to undo, so this is an error too

Let me know if I that makes sense to you too

[ndharmateja]

@Monstarrrr what should be the response body for these routes?

I am in the process of building the Mock API which will contain the response format i'm looking for. I will let you know asap. If an issue is blocked by an other it may be a good idea to add ''blocked by #[issue_number]" in the issue body to help with keeping track of dependencies.

okay great I will code everything else except for the response bodies.

I also added the blocked by.

[ndharmateja]

@seporterfield @Monstarrrr @purple-void should the following edge cases be considered?

1. upvote argument

   • when the argument is already upvoted, should an error be raised?

2. upvote argument undo

   • if the existing vote is "downvote", what should be done?
   • if no vote between the user and argument exists, what should be done?

1. In theory i'll make sure an upvote cast can't happen if the item is already upvoted, because clicking this upvote will trigger a /undo, in practice if it were to happen for whatever reason then we'd expect an error
2. If existing vote is a downvote then there is no upvote to undo, so likewise such a call would return an error
3. If no vote exists then there can't be votes to undo, so this is an error too

Let me know if I that makes sense to you too

yes definitely makes sense 👍🏼

[Monstarrrr]

In general you can assume that anything not explicitly planned is an error, kind of like the API equivalent of the https://csrc.nist.rip/glossary/term/deny_by_default approach