19 Feb 2021
This contribution is a new feature.
In order to understand the current behavior you need to be familiar with what a GitHub notification is.
Notifications provide updates about the activities and conversations you're interested in.
In the Octobox context, they can be of three different types:
Pull request or
Users can currently refine their notifications with specific filters.
Here is a list of some filters that can be used:
octobox/octoboxOnly search notifications from the octobox/octobox repository.
microsoftOnly search notifications from repositories in the microsoft organisation.
pull_requestOnly search pull requests. Also accepts: issue, release, commit, repository_invitation and repository_vulnerability_alert.
The goal of this contribution is to add filtering based on the issue number and/or the pull-request number like GitHub does:
In order to contribute to the project, we will need to set up certain elements.
Fork and clone the Octobox repository to our local machine.git clone email@example.com:<OUR_GITHUB_USERNAME>/octobox.git # Using SSH
- brew install rbenv ruby-buildrbenv install 2.7.2rbenv global 2.7.2
Install PostgreSQL which will be used to store our notifications.brew install postgres
Install the "Gems" dependencies from the
Gemfilegem install bundler && rbenv rehashbundle install
Create the databases and tables with "Rake"(it is a task runner in Ruby).bundle exec rake db:create db:migrate
It will allow us to connect our GitHub identity to our local Octobox instance using OAuth and to retrieve our account notifications.
Once this step has been completed, we need to write down the client id and client secret and create an
.envfile with the following content:GITHUB_CLIENT_ID=<OUR_GITHUB_CLIENT_ID>GITHUB_CLIENT_SECRET=<OUR_GITHUB_CLIENT_SECRET>
Make sure that PostgreSQL is running and start the project with:rails s
Now that our project is running locally, we can start implementing the solution.
We will follow the TDD (Test Driven Development) approach by developing test cases to specify and validate what the code will do.
Moreover, it will allow us to do refactoring afterwards by making sure that the functional part is good.
To filter the notifications based on their reference numbers, we need to validate that our Search engine will correctly converts our params to the right query prefix.
The following tests will allow us to test that the notifications are properly filtered based on the number(s) we specified in the search input.
For example, given the following search input, the following URL will be used.
NOTE: When building a URL, we must ensure that it contains only valid characters.
All characters to be URL-encoded are encoded using the
% character and two hexadecimal digits corresponding to their UTF-8 character.
This means that
3A corresponds to the character
+ to a space (the real encoding uses
%20 but form data in URLs uses
Search bar component
In order to make our tests pass, we will need to implement different things:
- Add a new param
numberfor the search model which will be used to query the right filters.
- Add a new
numberscope which will be used to select the notifications from our table with a number which matches to our.
- Add a new
-numberscope which will be used to select the notifications from our table with a number which is different to our.
This step involves adding our two new params
It will allow us to pass the right information to the scopes who will take care of the logic to retrieve the corresponding notifications in our database.
exclude_number works as a negative filter and will therefore filter in the opposite way to
We will update our
Search model to add our new params.
We will also need to add our new filter to the filter list inside the notifications helper.
Now that we have the filters requested by the user, all we have to do is retrieve the corresponding elements.
There is one property of the
notification element that we will use:
subject_url property is in the following format:
/2520 (with the reference number at the end of the url).
Note that if the
number filter is combined with the
type filter, it will only search notifications of this type.
In the inclusive case we need to retrieve the notifications that have a reference number that corresponds to the one we provide.
In the exclusive case we need to retrieve the notifications that have not a reference number that corresponds to the one we provide.
Now that we have developed our new filtering system, all we have to do is add various helpers that will allow the user to use our filters correctly.
In order to help the user visualize the filters that are currently selected, we will add a new element to the
Search filter component
To help the user use the correct filters, a modal-component is available.
It display some information to the user about the different filters he can use.
Here is the final result with a sample workflow:
- Filtering by only one reference number
- Filtering by multiple reference numbers
- Filtering with a negated reference number
I did not have any major problems with this contribution.
The local setup of the project was a bit long (configuration of the GitHub OAuth Application, setting up postgres/redis...) especially for the configuration of the ruby version where I had incompatibilities between the
rbenv version and my local ruby version using
But it gave me a better idea of how the project worked.
This contribution allowed me to learn more about Ruby On-Rails and its usage in a concrete project.
Ruby is not a language I usually use, it allowed me to use a different language from the ones I usually use.