We need each of the following endpoints for ads, listings, and roommate posts:
An endpoint for viewing the list of contacted users (people who have reached out to the owner of the product in an ad, listing, or roommate post)
An endpoint for viewing the list of confirmed users (people who have bought the product in an ad, listing, or roommate post)
An endpoint for adding the current user to the list of contacted users
An endpoint for adding the current user to the list of confirmed users
An endpoint for viewing the list of items that you are a contacted user for
An endpoint for viewing the list of items that you are a confirmed user for
The logic for endpoints 3 - 6 has already been abstracted into the AbstractAddRemoveUser API view. You can follow what's being done in the LikedEvents API view in the events/api_views.py.
The logic for endpoints 1 - 2 is very similar to the AbstractLikedUsers API view. The AbstractLikedUsers API view currently uses the 'liked_users' attribute on a database object .
We can make the AbstractLikedUsers API view more generic by allowing a sub-class of the AbstractLikedUsers to specify which attribute on the database object to get. We already do something similar in the AbstractAddRemoveUser
We need each of the following endpoints for ads, listings, and roommate posts:
The logic for endpoints 3 - 6 has already been abstracted into the AbstractAddRemoveUser API view. You can follow what's being done in the LikedEvents API view in the events/api_views.py.
The logic for endpoints 1 - 2 is very similar to the AbstractLikedUsers API view. The AbstractLikedUsers API view currently uses the 'liked_users' attribute on a database object . We can make the AbstractLikedUsers API view more generic by allowing a sub-class of the AbstractLikedUsers to specify which attribute on the database object to get. We already do something similar in the AbstractAddRemoveUser