Almost there

Would you believe it, we’re almost at the end of GSoC! It’s been a long journey and I’ve learned a lot. I’ll be writing a report about everything I did this summer soon but for now, let’s get into the details of what I did these past couple of weeks.

Note: This is my 6^th Bi-Weekly blog. You can find the rest of them here

Summary

Like the last time, I worked mostly on the UI side and since the majority of the time was spent coming up with a good design, there’s not a lot of code to show. I did however end up discovering a bug in the way the dashboard tracked categories while working on the articles modal - more on that later.

The UI area I was working on this time was a feature request I received from at least a couple of users - a way to see and filter the articles being tracked by a particular scoping method. I still haven’t finalized the design yet but currently, it looks something like this

To nil or not to nil

Before I get to the actual UI work I planned on doing, let me talk about the bug I discovered first - not only because I think it is hard to find one, but because it is relevant across languages and codebases.

So here’s the setup - I noticed that for some reason, the dashboard keeps track of subcategories as if they were actual articles. This is a problem - since tracking a category in theory should only track its mainspace articles. Before, this problem wasn’t apparent because a user couldn’t see the articles being tracked by a category. Now that they can, it is a problem. Not to mention it also messes up the numbers on the dashboard.

So that’s the gist of the problem. I spent an hour or so trying to figure out why this was happening when I saw it. Let’s take a look at the code

def category_query(category, namespace=0)
  { list: 'categorymembers',
    cmtitle: category,
    cmlimit: 500,
    cmnamespace: namespace, # mainspace articles by default
    continue: '' }
end

Ok, so for those not familiar with Ruby, let me help you out. This is a function that takes in two arguments - a category and a namespace. It then returns a hash which is used to query the MediaWiki API for the category members of the given category.

Now, when this function was called for an article, the namespace was passed as nil. Unlike in javascript, however, when passing undefined to a function is the same as not passing anything, in ruby, it is not. In ruby, if you pass nil to a function, nothing of that sort happens.

So the namespace=0 part of the function definition essentially did nothing - the namespace was always nil. This meant that the dashboard was always tracking all the articles in a category, not just the mainspace ones.

The fix was simple - I just had to change the function definition to

def category_query(category, namespace)
  { list: 'categorymembers',
    cmtitle: category,
    cmlimit: 500,
    cmnamespace: namespace || 0, # mainspace articles by default
    continue: '' }
end

namespace || 0 evaluates to namespace if it is not nil and 0 otherwise. And Voila! It’s fixed.

The UI

With that bug out of the way, let’s get to the feature I was working on. As I mentioned before, I was working on a way to see and filter the articles being tracked by a particular scoping method. Let’s see why this is a useful feature request first.

Say you have a category called Physics. It’s not that hard to guess which articles would be tracked by this category. Now, let’s introduce the subcategory depth parameter - if this depth is 0, only the mainspace articles in the category are tracked. If it is 1, the mainspace articles in the category and its subcategories are tracked, and so on.

Now, it is a bit more difficult to guess which articles are being tracked by category. But it’s still manageable. Now, say you are tracking articles using PetScan with an ID of 4341. Yes, you can open up the PetScan page and see which articles are being tracked but that’s a bit of a hassle. Not to mention that the dashboard only tracks articles from one wiki - even though your PetScan ID might be tracking articles from multiple wikis. This is something we point out in the dashboard, but it is still easy to miss.

So what’s the solution to all of these problems? Since the Dashboard already keeps track of the articles being tracked by a particular scoping method, why not just show them to the user? And that’s exactly what I did.

There are still some edge cases to consider - like what happens when the Dashboard hasn’t run an update on a category yet - in which case, the articles being tracked by that category are empty. But I’ll figure out something after discussing it with Sage.

Conclusion

And that’s about it for this blog post! Sage has been busy with other things so I haven’t had a chance to get these changes reviewed and merged, but I still have a week left so hopefully I can get all this done before the final evaluations.

This might well be my last blog post for GSoC which is a bit sad. I enjoyed writing these and hope that they helped you in some form or another. I will be writing a final report soon though so keep an eye out for that!

And as always, thanks for reading!