Introducing BugZot – a RESTful bug tracker

As we progress through the chapters in this book, we will need some way to implement what we have learned.

Imagine that you work for an organization known as Omega Corporation, which is a market leader for selling software products to companies and individuals. Omega Corporation needs a system through which it can track the bugs in its products. After a lot of brainstorming, they initiate a project codenamed BugZot, which will be their tool to track the bugs in their products.

Let's take a look at what Omega Corporation wants to achieve with project BugZot:

• Ability for users to report bugs in products: The users, be they internal or external, should be able to file bugs against a particular product of the organization, and while filing these bugs, the users should be able to select the release version of the product they are filing bugs against so as to provide increased granularity.

• Ability to control who can see the bug details: Since the application allows both internal and external users to file bugs, it is possible that internal users, such as quality engineers or internal IT teams, may file bugs against a product that has not yet been made available to the customers. This will mean that BugZot should be able to hide the details about the bugs that have a confidential status.

• Providing support for role-based permissions: BugZot should be able to support the concept of roles and permissions so that an unauthorized person cannot change the details of a particular bug. For example, we might not want an external customer to come and change the target release version for a bug, which is a task that should be done by product management.

• Support for file uploads: When a bug is filed, usually an error report or a log file from the product greatly helps to drill down to the root cause. This will mean that BugZot should be able to deal with file uploads and link the uploaded files to their respective bugs.

• Search functionality: A person using BugZot should be able to search for the bugs that are filed into the system based upon certain filter criteria, such as the identity of the user who filed the bugs, the current status of the bug, filing bugs against, and so on.

• Integration with email: When a bug changes state—for example, if a bug is moved from NEW to ASSIGNED—there should be an email notifying the people associated with the bug. This will require BugZot to provide integration with the email service provider of Omega Corporation.

• Ease of integration: Omega Corporation plans to extend the usage of BugZot at a later time by integrating BugZot with the various other internal applications they have. For this, BugZot should provide an easy way to achieve this integration.

Throughout the course of this book, we will be learning various concepts in Python and applying them to build BugZot, the bug-tracking system for Omega Corporation.