Configuration: Customer's google drive is linked. All records will be stored there.
Configuration: Jira admin can connect either a Google drive or an AWS bucket
Starting signing a Speed-eRecord
Start signing on a Speed-eRecord
All Speed-eRecords can be viewed from the Issue view
Signing on a Speed-eRecord
Completed signing a Speed-eRecord
Speed-eRecords are beautifully designed and embed all issue attachments as part of the PDF
For several years, RadBee has helped heavily-regulated life science enterprises handle their sensitive business, product development, and compliance issues through the Atlassian ecosystem.
While Jira has served as an excellent method to develop products and track and resolve issues, it is difficult to capture Jira data at a precise point of time along with any official approvals. Users today are forced to find slow workarounds to solve this gap.
This inability to quickly and easily capture the ‘control event,’ or the precise moment in time when an issue is reviewed, resolved, and approved, has long-ranging implications to the organization’s ability to pass critical audits, and more. For example, enterprise users need to prove that:
- Industry-specific testing processes were followed when a product is ready to be publicly released
- Security and vulnerability management processes were followed by the team or enterprise
- All required documentation was provided, reviewed, and signed during hiring processes
RadBee wanted to help the enterprise capture the data in Jira in that perfect moment in time, the control point, and have it easily signed off and archived without slowing down agile teams. We also aimed to:
- Create an easy installation process that takes just seconds so as not to slow down critical work on the team.
- Make this capability immediately available to all projects in Jira, so that every team and project can start using the app as soon as it's installed.
- Provide the ability to self-select an eRecord archiving destination separate from Jira. As the eRecords are sensitive and auditable, their retention should not be dependent on the Jira issue, especially in the event that a Jira issue is deleted.
- Provide a beautifully-formatted, standalone PDF eRecord that can be viewed independently of any external resources. It also had to embed issue attachments that contain critical data. In our experience, we know that these eRecords are often seen by customers and audit teams, and wanted to ensure a professional, well-formatted, and audit-ready record which helps build trust.
- Not retain any customer information on our side. The only time we have customer data is when the App generates the PDF file.
What it does
Speedy PDF Sign-Offs for Jira helps fast-moving teams capture official sign-offs and document issue resolution and approvals without slowing down their flow.
Able to handle any Jira issue, the enterprise app creates a beautifully formatted Speed-eRecord of the particular moment in time, which can be electronically signed and archived safely in a matter of seconds.
SpeedyPDF SignOff takes seconds to install, and is immediately available to support your entire Jira instance, projects, and issue types.
How I built it
Speedy is an Atlassian Connect app.
It runs on a Google Cloud infrastructure:
- The UI Components and the functions who interface between Jira and the PDF generator are running on Google Firebase. These parts are built on TypeScript, NodeJS and React.
- The PDF generator uses Google Cloud Run. This part is built in Java.
Challenges I ran into
What's the best technology to use when transferring Jira data into a PDF? This was a key question with system-wide implications about the end product. We did not have specific background in PDF, or in PDF generation engines and technologies, but we still wanted to create a beautiful PDF which will be archive ready. We spent a long time in this technological exploration and eventually landed on a solution, which is in line with the state of the art in this area. We retrieve Jira data in json format (based on Connect rest calls) and pass it into our PDF generator. The PDF uses velocity templates to generate HTML data which is then processed by the iText PDF library (commercial library) to generate the PDF.
Embedding attachments in the PDF was a big issue The ambition to include the embedding of attachments as part of the Hackathon proved to be our most expensive decision in terms of resources. It required close collaboration and synch accross our interfaces and required us to implement a much more complicated hand-over mechanism (from Jira to the PDF generator).
No memory principal We did not want to hold onto customer information for the long term, but still had to have a 'long term' process. The first time we process a Speed-eRecord is upon its creation, and the second time is when the last signature is received and signature tables are added. Keeping in mind our design principal of not storing 'historic' Speed-eRecords, the processes required some very careful design that impacted the PDF itself, customer storage management, and the properties we keep in Jira.
Client storage connectivity We wanted to demonstrate the principal of storing the Speed-eRecord in a location assigned by the customer. To show that the app is "storage agnostic," we wanted to have at least two types of storage locations. We initially wanted to have Confluence be one of these location, but this seemed to be more then we could fit in the time we had. Eventually, we chose these two types:
Google Cloud - because this is very easy to set up and is tremendously popular.
AWS Bucket - could make sense as a storage location to organisations who have AWS as their chosen platform. It requires some AWS know-how, so we worked hard on making the setup as self-explanatory as possible.
Need to access the Connect eMail API meant we needed to wait for approval from Atlassian As it is, the processing of the specific approval process to access the email API by Atlassian is long. It took us three weeks from the time we raised the request until we had access. That was nerve-wracking and meant that the complete email channel could be closed only on the last Friday before the Hackathon deadline.
Accomplishments that I'm proud of
From concept to app in few weeks: The work on the app was triggered by the Codegeist competition. Everything that we're submitting today is the result of intense work happening over the last six weeks; juggling between the Hackathon and all the other projects and life chores we are busy with.
Finally using Connect: RadBee usually works on Server. This was our first development experience with Atlassian Connect. Our team was joined by people who had good knowledge in the area, but this was still a big learning curve for many.
Collaboration: Our app was built in collaboration by two teams who had no collaboration history. We still managed to work effectively and deliver the app, working remotely across four different time zones.
Result: While the Codegeist submission is not "feature complete," it is consistent with the product vision we had and is built on design principals which will allow us to complete the features on the same foundations. Specifically:
The infrastructure to embed attachments in the PDF is there.
The principals of managing a "long process" (the creation of PDF and then adding the signatures) have been understood and implemented.
What I learned
Hackathons are great fun and a good way to skill-up and alleviate any blues caused by the Covid-19 pandemic.
Lots of technical stuff, key areas already mentioned above.
What's next for Speedy PDF Sign-Offs for Jira
Speedy PDF is now in Beta, and we invite anybody to try it out. It's currently pending approval on the Atlassian marketplace, but anybody who wants access can send us an email to: email@example.com
We have a long list of stories in our backlog, so for us, our journey has just begun.