Sign in Subscribe
Trello Automation

Project 2: Status Update

Matthew Monroe

• 4 min read

One Giant Step in my Journey


It's been a long few months—balancing classwork, a full time job in the midst of a new role (Thanks, layoffs.), my family, these projects, and other personal interests like video games, rewatching the entire MCU collection, etc. Despite the lack of time, I've finally completed my first semester back to college. In what is possibly the second proudest moment of the last decade (Second only to the recent birth of my child, of course), I've decided to write a status update on my second project, and to speak about my first semester at the College of Western Idaho in another subsequent blog post.

Project Updates

Recap

I've got nothing short of great news on the Trello automation project. I thought for sure that this would be a challenge, especially considering how much I struggled with the first project, which is very similar in structure. To reiterate, this Trello project involves an automated script that sends a POST request to our (my company's) proprietary database. This request pulls data from the database and then automatically creates Trello cards based on the information is finds. From there, anyone with access to the Trello board can claim the card, begin working on the system, and once resolved, they'll be able to click a button to send all updated information on the Trello card back to the database, updating it almost instantaneously.

Current Status

I'm pleased to say that the project itself has been going very well, with only a few hiccups. I was able to setup the proxy server, test locally, test externally, and finally, test from a browser. All tests returned response code 200 - a success. With this, I was able to set up an second api call to Trello, effectively automating part of the final product—card creation.

Needless to say, I can't include proprietary or sensitive information, but what I can show is the general rough structure. Naturally, this is probably going to change to fit the needs of my team, but so far, I have a rough draft of sorts. Cases will be automatically converted to Trello cards in the far right "Dashboard Cases" list, which can then be distributed to or claimed by those with with access. Eventually, I will implement a custom button that takes all information on the card and sends the information back to the original case, updating any fields that differ. The same will also be implemented with the card comments. Any new comments that are intended to be posted to the case will be made possible to send via a single button click. This effectively eliminates our reason to use the dashboard or the source program that hosts our cases, both of which are complicated to navigate and cluttered.

I've just about finished with what I'm calling "phase 1" of the project—that is, making sure the reception of such information is completely automated. The cards that are created contain almost everything that we need, and I've learned that adding more logic is relatively easy in my flask application. Phase 2 begins when I'm certain that the cards are complete and no further information or modifications are needed.

In addition to being nearly finished with phase 1, I've also proactively identified issues that will cripple the functionality and utility of the finished product:

  1. Duplicate cards
  2. External updates

Duplicate Cards

The first major issue was card duplicates. If the script is set to run automatically on a set interval, then surely it will begin pulling cases that already exist in Trello. This is a big problem. We receive up to 40 new cases per day, and any cases that go unclaimed will continue piling up with duplicates. The fix was fortunately simple.

This block works to identify duplicate case numbers by comparing the value assigned to the case number header to the value assigned to the custom field that I've implemented on the cards. If the fields match, then the case is ignored, and the next case is checked.

External Updates

The second major issue which I've yet to correct involves external updates made to cases by members outside of the Trello board. For example - What happens if a Trello card has appears, and someone in the customer service team posts a comment or updates information on the case? This wouldn't be reflected on the Trello card, leading to potentially missed or outdated information that my team would then have to deal with.

While I don't yet have a fix for this issue, I've planned a rough idea for it:

  • Rather than ignoring the duplicate case, it will instead initiate a secondary check upon finding the duplicate case number.
  • The second check will scan all information on the Trello card for any information that differs from what is on the case.
  • If mismatches are found, it will automatically change the information on the Trello card whilst adding a card comment to explain that the change was made, and by whom, if applicable. This enables everyone to be aware of when and what changes are made in near real-time.

Once I finish applying logic for external updates, all that's foreseeably left is to test functionality and to try and break it. I'll probably create a test case and attempt to put unusual information to see if there are any obvious flaws with delivery. I'll address each issue systematically, and update accordingly.

BitBucket and Version History

Finally, I've been experimenting with BitBucket. It's my first time using it, and as such, I've already made a fatal flaw and somehow deleted all of the contents of my personal repository. Fortunately, no data was actually lost, save for the readme.txt that came with it. Lessons learned, I'll be more cautious moving forward, especially now that I've been invited to a repository that some of our engineers actively use.

I've also been getting into the habit of creating more logical and healthier version structures, though I'm sure I could benefit from researching more on this topic. Naturally, I labeled the first instance of my application 1.00. For each update involving bug fixes, I change it to 1.00.01 incrementally. For each major change to layout of the application or for any additional logic or features, I've been up incrementally increasing version history by 0.01, or 1.01, for example. Currently, I'm up to 1.06.07. I had a number of typos and small bugs in the latest change, but it's atleast stable now.