Last week we released BAT - our Bookings and Availability Management toolkit as well as a Drupal module for BAT.
We are using BAT to build the new version of our Rooms module as well as other products. However, BAT is much more than an engine for nightly bookings. It also allows us to build any sort of booking / resource management tool. So we asked: "What would it take to build a resource management tool to manage ourselves?". We have previously used a tool called , and while it is a wonderful tool, we wanted to build something that integrated tightly with our project planning and issue tracking tool, Jira.
The result actually impressed us. We thought it would be a useful exercise, but we didn't anticipate getting a tool that we could use daily this early in the game. Here is what we did:
Getting issue data from Jira
The first step is to pull in data from Jira, which happens to have a great set of APIs for doing that. We pull our Projects and their Issues into Drupal and save them as nodes. This is just a quick way to cache our data in Drupal and avoid having to constantly be querying Jira.
The wonderful module allows us to simply build an approriate query in JQL and returns the data for us to save as nodes.
Representing our team in BAT
The next step was to represent the resources we want to manage in BAT. BAT associates Units (things that can have different states in different time periods) with Events (time periods with a specific state value). So in our case our Units are Developers and the specific events book developers availability to a specific project(s) and associated issue(s) from Jira.
Here is how we structure our events:
The unit maps to a single developer and the state reference indicates what they will be doing during a time period. Projects and Issues link to Jira and the Nota Bene field holds additional notes that might be required.
Events may have different states. Currently we have:
The states themselves are self-explanatory. What we should explain further is that Blocking states indicate states that cannot be overwritten without first specifically changing them. Therefore, on the calendar you may not select dates which include a blocking event and simply change the state of a unit. You must first deal with blocking events (either move them or delete them) and you may then change the state. If no state is defined, the default state is "Available".
Finally, we have the actual developers. These are BAT units that our app creates automatically based on the users within our Jira installation:
Managing Time
With the above in place we can now actually manage resources for our team!
In order to make it simpler to create events, we represent our active projects as blocks that we can drag onto our calendar. This creates a standard event whose time we can then adjust:
If we want to see a higher level of granularity, we can change the timeline view from days to hours:
Finally, clicking on an event brings it up in a modal where we can add issues and notes:
Next steps
We now have our MVP and it is actually making it easier to manage our team. The beauty of it all is that, this being Drupal, we can adjust it to just what we need without any particular effort by simply adding fields and managing our different event types.
We hope you found this a useful example of what can be done with BAT. Get in touch if you have a great idea you would like to partner with us on!