WebIssues Manual

In the previous chapter the term issue has been repeatedly used. It's the smallest, independent unit of information that is stored in the WebIssues system. It's also a very general term; a single issue may represent a bug in the software, a service request, a task, a thread in the discussion, an asset owned by the company, etc.

Every issue in the system has its own unique and invariant identifier, which makes it possible to unambiguously distinguish it through its entire life time. An issue also has a name and any number of attributes of various types, analogous to a table in a spreadsheet, in which a single row represents an issue and a column corresponds to an attribute. In the WebIssues system, issues of different types can coexist independently, with different sets of attributes, just like a spreadsheet can contain many tables with different sets of columns.

Since version 1.1 of WebIssues, issues can also have a description, which is a longer text explaining the details of the issue. Usually it's entered when creating the issue, but it can also be added or modified later.

Each issue registered in the system has its own history, arranged chronologically from the time of creation. It contains modifications of values of individual attributes, as well as comments and attached files. This allows you to trace the entire life cycle of the issue, reproduce its state at any time and see who and when changed the issue and in what way.

To maximize the productivity and flexibility, the WebIssues system has no complex system of permissions; it's based on the idea of ​​open collaboration. Therefore, it's best suited for internal use in a trusted group of employees or members of an organization. Everyone can freely create and modify all issues to which they have access. Every change, however, is explicit and remains permanently registered by the system. In addition, removal of issues and other potentially dangerous or irreversible operations require special permissions.

To make issue management easier, they are logically divided into folders. You can create any number of folders of different types, but a single folder must contain issues of same type. Continuing our analogy, the folder is therefore equivalent to a table in a worksheet. Using folders makes it easy to search for information; for example, you can divide bugs according to modules to which they are related, or version of the software; discussion forums can be divided by topic, and service requests — by the month in which they were registered.

Folders in turn are grouped into projects. For each project you can specify a set of people who have access to it, and their rights within the project. You can therefore divide the system into areas accessible to different groups of users. Each project can also have its administrator (or several administrators). The administrator of the project has more permissions than an ordinary user; for example, he has the ability to delete issues or move them between folders.

It's not possible to define permissions at a lower level of detail than a single project. All members of the project have equal access to all information contained in this project and the ability to modify them. However the WebIssues system ensures security and prevents unauthorized access to data.

Starting with version 1.1 of WebIssues it is also possible to view all issues of a given type in a single list. This is especially useful if there are many projects in the system and instead of constantly switching between folders, you can see all issues, filter them if necessary and work with them.