Table of Contents
- Planning and Analysis
- Cron tasks
- Command Line Alternative
- Cron Basics
- Automatic creation and update of issue via email.
- Custom Fields
- Progress History
- Issue Reports
- Multi-Lingual support
- Import/Export Facility
- Alternative Alias identifiers
- Ability to associate types with projects.
- New Create Issue Button on List Views.
- SMS Integration
- Front End Download of Attachments
This section describes the design criteria used for the component. It provides the rationale behind the design and helps to understand how the component works.
One of the criteria in the design is to make use of as much of the supplied Joomla functionality and provide familiarity of use with the standard Joomla components.
Effective project and program management is the key to completing on time and within budget. Within every project or program there are always multiple issues that need to be tracked, prioritised, and managed. Additionally there are often additions and improvements made as the project goes through its life cycle.
A company, whatever its size, may have many projects that must be completed on time for the company to be successful and profitable. Missed project deadlines can result in lost revenue. The company's project leads use various methods to track issues, including manually recording statuses in notebooks, organising issues in text documents, and categorising issues by using spreadsheets.
By using a Joomla component it is possible to easily record and track issues in one central location. This approach offers each project/program lead access to just the data they need and makes it easier for management to determine if critical issues are being addressed.
The first action is to define the application requirements. These are then used to design a database and an outline that describes how the user interface accepts and presents data.
The project leads establish requirements that define the information that must be tracked, security requirements, data management functions, and how to present data to users. The wish list is enclosed below for completeness; note however that the current implementation upon Joomla does not provide all of these facilities at present.
Each project lead may track information slightly differently. It is agreed that the application should include the following information:
-
Summary of the issue
-
Detailed description of the issue
-
Who identified the issue
-
The date on which the issue was identified
-
Which project/program/product the issue is related to
-
Who the issue is assigned to
-
Visibility of issue (General or Restricted)
-
A current status of the issue
-
Priority of the issue
-
Target resolution date
-
Actual resolution date
-
Progress report
-
Resolution summary
![[Note]](/media/com_docimport/admonition/note.png) | Note |
|---|---|
|
Not all of these requirements are met with the current release. As demand and circumstances permit, the missing requirements will be added with later releases. |
The project leads are concerned about everyone having access to all the information, they agree upon the following access rules:
-
Each team member and project lead is only assigned to one project at a time.
-
Each team member and project lead must be assigned to a project.
-
Managers are never assigned to a specific project.
-
Only managers can define and maintain projects and people.
-
Everyone can eater new issues.
-
Once assigned, only the person assigned or a project lead can change data about the issue.
-
Management needs views that summarise the data without access to specific issue details.
Joomla ACL permissions can be configured to achieve a number of these requirements. Others will be implemented as time permits.
The project leads also determine how information will be entered into the system. For this project, users must be able to:
-
Create issues
-
Assign issues
-
Edit issues
-
Create projects
-
Maintain projects
-
Maintain people information
-
Maintain project assignments
Certain of these aspects need to be under control. For example only certain people should be permitted to create projects and assignments, whilst creating issues is much more liberal.
Once the data is entered, users need to view the data. The team decides that users must be able to view the following:
-
All issues by project
-
Open issues by project
-
Overdue issues, by project and for all
-
Recently opened issues
-
Unassigned issues
-
Summary of issues by project, for managers
-
Resolved issues by month identified
-
Issue resolution dates displayed on a calendar
-
Days to Resolve Issues by person
Reports will be developed and added based upon requirements once the product has been released and upon a priority basis.
Records often contain date/time fields which are used to record the date/time when an event has occurred. These include items such as when an issue is opened or updated. When it is closed and also various auditing performed upon the record. Prior to release1.6.2 dates (and times) entered into the various forms were set up such that they were converted into user time when the form was saved. The details of the specific timezone were not saved thus when redisplayed the time might appear to be incorrect. This was most noticeable with the resolution date field, which when the user was present in an area with a large timezone difference from UTC/GMT could be confusing. Especially since the default audit dates as set up by database triggers were using server local time'. A user would enter the date in the required field which would be as for example '2014-06-05', but because the value was picked up (by a EUROPE/LONDON timezone user) it would be handles internally as if it were '2014-06-05 23:00:00'. For a Latvian user with a timezone of 'EUROPE/RIGA which has an additional time difference of 2 hours (3 if one includes daylight saving time [DST]), the time would appear to be '2014-06-05 21:00:00'.
Even our own system where daylight saving time (DST) was in effect could cause a 1 hour difference in the local time and the actual time. For some areas it would be an even greater apparent time discrepancy. Release 1.6.2 addresses this problem and all date/time values are now stored in UTC time. Then when the values are displayed to the user they are presented in the time in the users own time zone. For guest users the server time zone is used. To aid this conversion a helper routine has been implemented and is described in more detail later in this document.