GSOC Midterm Update

( Hi, I’m Nishanth Vijayan.I’m an undergraduate student at the Indian Institute of Technology Ropar, India, where I study Computer Science and Engineering.I’m currently in my 4th and final year.You can find me on GitHub @nishanthvijayan and my IRC nick is the same.I’m an avid tech enthusiast and love all things Geek. )

The Midterm Evaluation of my GSOC project is over and I passed. Like I mentioned in my previous post, a major part of my project is to implement a Revision History page in OSEM, which will grant organizers and admins access to the history of changes that were made to a conference, users and their associated resources.

Why have such a page?

A conference has many associated aspects registrations, events, rooms, tickets, commercials, sponsors etc, all of which can be managed using OSEM. A conference usually has many organizers. The idea here is that one organizers may change some details associated with any of the before mentioned objects and the others have no means of knowing this. Similarly, event submitters may change details (like title, abstract, other needs etc) of their events and there is no means for organizers to be know about these changes other than by manually going over each event in case he wants to know something.

This is where the Revision History page comes to play. A revision history typically displays a list of all such changes with details like who orchestrated the change, when the change occurred etc. This is a common feature found in many popular apps (Example: Google Docs ).

Status

The aim of the first half of the project was to implement a Revision History/Changelog page with the following features:

• Track as many models as possible (OSEM has 40+ :O)
• Display timestamp showing when the change was made
• Changes should be described in a straightforward fashion (as close to proper English as possible)
• Changes should be revertible i.e for each change, the user should be able to restore its associated object to its form before that change.

I’ve implemented all of the above and have open a pull request. The PR is still undergoing review and will hopefully be merged soon. This is the current state of the Revision History page I’ve implemented.

• Change tracking has been added to 28 models. Few models have not been tracked as they are expected to be reworked soon

• Organizers can inspect each change to see which attributes of an object have changed and can see the previous value and updated value.
  
  
• Organizers can revert an entire change or even revert change to a single attribute.
  For example:In the above image, an organizer (or admin) can revert all 3 of those in one go or revert change to only title (or subtitle or max-attendees).
  
  

Challenges

Previously, I had implemented a simple version of a Changelog page in a college project using the same gem (paper_trail) that I was planning to use in OSEM. So when I initially started coding, I was confident that I would be able to complete the feature in a fortnight.Boy, was I wrong!

A large part of the difficulty that I had to face was in trying to describe changes. 28 types of objects meant a lot of cases.

Some objects had title attribute, others had name, some others had neither. Eg: Event had title, room has name, registration had neither.

Some objects were associated to another type(s) of object. Eg: A Comment is associated with an event and a user.So is Vote. But a Users_Role object is associated to a user and a role

And then there were objects with polymorphic associations. Eg: A Commercial object can be a venue’s commercial, an event’s commercial or the entire conference’s commercial

The object under consideration could be a deleted object.Or maybe, it’s association could be deleted.


When describing changes, all these had to be taken into consideration.There was no way to solve this other than by listing out a lot of specific conditions and in some cases grouping object with similar properties together. For example: Vote, Event and EventRegistration are all similar in that there is an associated user and an event.So, all 3 could be grouped together in code. TDD is what kept me sane, when adding new models.Every time I start tracking a new model, I would sit and think how I want to describe each type of change to that an object of that class, then write a feature test for it.This finally made me a true believer of TDD.

So far, so good

During the course of the first half of the project, I learned many little quirks of Ruby and Rails (mostly Rails). Many times during the project I had to go through the source code of paper_trail, the gem I used for tracking changes.I had to do this to understand how certain things are implemented under the hood. I remember doing the same when working with paper_trail as part of my college project. But at that time, I was not able to make much sense of it.But this time was different. This was a great experience as it made me realize how my Ruby and Rails skills have improved over the course of this project.

One big mistake that I made was not making opening a PR early on.Doing so would have helped me to identify style issues and other problems early on.

During the initial few weeks I used to write tests after implementing some feature and not before.Of course I was familiar with the concept of TDD but was not a firm believer.The last few weeks have been an eye opener in this regard.

Next Up

In the next half of the project, I have to implement a set of small features. Since there are a few features to implement, the challenge now would be to identify and allocate time properly. It’s a difficult job considering how I initially expected to finish my first task in 2 weeks :( . I’ve completed the first one and have open a pull request. It deals with handling canceled events in a conference’s schedule.I’ll write more about it in my next post.