Boosting application security, voting and commenting in the user story system in GSOC'20

This time I let the title reveal the much awaited features that are up and running by the time you read this. I am really excited to experience that adrenaline rush when I get a chance to vote in the real elections and choose our leaders of tomorrow. For now I can fulfill my desire by contributing in selecting the best and most wanted user story of the season. Follow me to understand how I solved the mystery of votes and relations.

What did I do this week?

Recall that complex bug where Strapi could not find the schema for our user story model and kept flashing that weird error on my terminal despite repeated attempts. This time I dived deep inside to catch a glimpse of the internals of Strapi and finally solve that.

The fields of the newly established relations in the user story model were overlapping with each other because Strapi does not drop or migrate the database when a model is deleted or updated. They do so because users may start their application with a production database and a model name may not match with one of the tables in the database. Crash! :/ This is a work in progress and Strapi is improving it. I solved it by choosing a different one sided relation type of one-to-many and renamed it to followers.

Now I added client side logic for the voting system so that a user cannot vote more than once. Clicking on the like button for the second time removes the vote of the user and so on. Pushing all this to production gave me a sigh of relief. :)

After a deep breath I moved on to allow users to leave their valuable feedback and suggestions on user stories. Yes, comments. This way we can take into account the views of more users and design our next awesome feature accordingly.

Now it was time to step up the security as a lot of functionality was already in place. I wrote a custom controller in Koa which checks that the localStorage id matches with the id of the authenticated user and if the same user is the author of the story they are viewing. A positive response will allow the user to edit their story. I also modified the controller which creates a new story and now it can automatically assign the authenticated user to be the author of the story.

What is coming up next?

I will work on the notification system. It would be great to have three types of notifications — in app, push and email notifications.

These will notify the user story author and followers that their user story has been launched. Only organization admins can update the status of a story from the Strapi panel.

If time permits I will try to setup Cypress for testing our application.

Did I get stuck anywhere?

The React implementation to allow one time voting for each user was a bit tricky as there are a lot of state variables on our story page. However, I solved this by catching the previous state value by applying functional updates in my useState hooks to overcome the stale state problem which arises due to closures in React.

Writing controllers for my server in Koa was also new but I was able to learn the basics quickly as it is similar to Express.

This ended the week on a sweet note. Stay tuned and get ready to receive another set of notifications on your device. Do not worry. We will not throw those sales ads on you again. This time it will be about the launch of your own story. :P