feature/BE-32 : User History

[BElifb]

• Created history as a separate app.
• Created the History model to keep track of different types of user activity.
• Created a signal (+ receiver) to activate creation of History instance when a page is visited (i.e. when related API is called).
• Couldn't create mixins as the related existing APIs were not class based. Instead created decorators, but since there is no way of trivially reaching the object of FBVs not using this right now. Will look more into later.
• Instead I added the signal code to the API views manually. This shouldn't be too much of a problem, since this won't be done in very many places. Currently;
  • users/profile/<id>
  • artitems/<id>
• Connected the history to admin site.
• Created a receiver for the signal and connected.
• Tested the functionality using Postman and the Admin site, and we are getting history instances. 👍
• Right now we are only tracking when a user visits an ArtItem page and another User's profile. We can make additions if need be.
• For additional information refer to BE-32: User History #353

[BElifb]

• Figured out how to reach object (through kwargs). But turns out the main problem was with the Authentication Middleware and DRF. request.user returned AnonymousUser in the decorator while it had the logged in user in the API view function. This had to do with a problem reaching sessions. Only solution I could find was monkey patching the authentication middleware, but even then there could be issues with authenticating twice. Moral of the story is not gonna fix what's not broken, and we're not using the decorator for this.

[KarahanS]

There were a couple of print statements left. I removed them. Tested the history tracking using postman for APIs and admin panel to see the logs in Histories. Everything seems to be working fine.
One quick reminder: After we merge #344, we should also add exhibitions to the history. I suggest you to review that PR and update this one accordingly. I'll be approving this one now, you can either merge this and then add the exhibition in another PR, or add the exhibition and let me know when it is ready for review again.

[KarahanS]

Btw, we are able to keep number of visits to an art item with this PR. Maybe you could add a view field to the artitem that shows the number of views. Something like this:

I don't know, it doesn't have priority at the moment.
Another thing I have in mind: Maybe we should compare the date of last visit with the new visit so that we can avoid "view spamming" by refreshing the page. It'd be a nice idea to store it in the history if there is at least 1~2 minutes between successive views of a user.

[BElifb]

• Added number_of_views field to ArtItem and updated the signals accordingly.
• Frontend is free to use it @kostanya .
• Not going to check for spamming by frequent visits. I think we can do it in the future when we are scaling the app. For now we need as much mock data as we can get.
• Adding exhibition history is easy, we can do it in a hotfix branch. I want to merge this one now so that I can use it for level calculation. @KarahanS

[KarahanS]

Skimmed through the additions, everything seems fine. My approval still holds @BElifb. There is a print statement left in object_viewed_receiver though.