Project Management Issues Register

Module: cs_project_issue

Version: 19.0.2.1.2

Author: Cyder Solutions

Website: www.cyder.com.au

1. Module Overview

The Project Management Issues Register is a comprehensive solution designed to track, manage, and resolve project issues throughout the project lifecycle. This module extends Odoo's native project management capabilities with sophisticated issue tracking, classification, and workflow management features.

The module provides a structured approach to handling different types of project concerns, from standard technical issues to change requests, while maintaining a clear audit trail and facilitating communication between project stakeholders. It integrates seamlessly with existing project tasks and provides portal access for external stakeholders to participate in the issue resolution process.

Key Capabilities

The module enables project teams to categorise issues into distinct classifications, each with its own workflow and business rules. Standard issues and change requests follow a formal approval process, while parking lot items and lessons learned are immediately closed upon creation to preserve valuable project knowledge without cluttering active work queues.

Integration with project updates allows teams to track issue metrics in real-time during project status meetings, providing immediate visibility into the health of the project. The portal functionality extends this transparency to external stakeholders, enabling clients and partners to report issues and track their resolution progress.

2. Getting Started

Accessing the Issues Register

After installing the module, you will find a new "Issues" menu item in the main Project menu. This provides access to all issue-related functionality, organised by classification type for easy navigation.

The menu structure includes separate views for Standard Issues, Change Requests, Feature Requests, Parking Lot items, and Lessons Learned. This organisation allows team members to focus on specific types of work without being overwhelmed by the full issue list.

Initial Configuration

Before creating your first issue, you should review the predefined issue types available in the Configuration menu under Projects. The module comes with five standard types that cover most project scenarios: Technical, Functional, Process, Resource, and Other. These types help categorise the nature of each issue and can be customised to match your organisation's terminology.

Note: Issue types are different from issue classifications. Types describe the nature of the issue (Technical, Functional, etc.), while classifications define how the issue is managed (Standard, Change Request, etc.).

3. Understanding Issue Classifications

The module implements five distinct issue classifications, each serving a specific purpose in project management.

Standard Issues

Standard issues represent regular project problems that require investigation and resolution. These might include bugs, defects, technical problems, or any other concern that needs to be addressed during normal project execution. Standard issues follow the complete workflow from creation through resolution and verification.

Change Requests

Change requests document proposed modifications to project scope, requirements, or deliverables. They follow the same rigorous workflow as standard issues, requiring formal approval before implementation. This ensures that all scope changes are properly evaluated, documented, and authorised before work begins.

Feature Requests

Feature requests capture enhancement ideas that fall outside the current project scope. These are typically considered for future phases or releases. Feature requests follow the standard workflow, allowing teams to evaluate and prioritise potential enhancements systematically.

Parking Lot Items

Parking lot items represent topics, questions, or concerns that have been noted but deferred for future consideration. When an issue is classified as a parking lot item, it is automatically closed and linked to the project update meeting where the decision was made. This provides a record of what was discussed and why it was deferred, without creating ongoing work items.

Important: Only Project Managers can change an issue's classification. Parking lot items are automatically closed when created and cannot be reopened through normal workflow actions.

Lessons Learned

Lessons learned capture valuable project insights, successful practices, or cautionary experiences that should be preserved for future reference. Like parking lot items, these are automatically closed upon creation and linked to the meeting where they were documented. This builds an organisational knowledge base while keeping the active issue list focused on work that needs to be done.

4. Creating and Managing Issues

Creating a New Issue

Issues can be created from multiple locations within the system. You can create an issue from the Issues menu, from within a project view, or directly from a task. When creating from a task, the relationship between the issue and task is automatically established.

Each issue requires several key pieces of information. The issue title should clearly and concisely describe the problem or concern. The project selection determines which project team will be responsible for addressing the issue. The type categories the nature of the issue (Technical, Functional, etc.), while the priority indicates the urgency of resolution.

The description field supports rich text formatting, allowing you to provide detailed context, steps to reproduce problems, or any other relevant information. Comprehensive descriptions accelerate the resolution process by ensuring the assigned team member has all necessary information from the start.

Issue Fields and Their Purpose

Linking Issues to Tasks

Issues can be linked to one or more project tasks, creating a clear relationship between problems and the work required to address them. You can establish these links when creating the issue or add them later from the Related Tasks tab.

When an issue reaches the Resolved status, project users can create a new task directly from the issue. This task inherits the issue's description and resolution, providing the assigned team member with complete context about why the task exists and what needs to be accomplished.

5. Issue Workflows

Standard Issue and Change Request Workflow

Standard issues and change requests follow a five-stage workflow designed to ensure proper investigation, resolution, and verification.

New

When an issue is created, it enters the New status. At this stage, the issue has been reported but no work has begun. Project users can review new issues to understand the problem, gather additional information if needed, and determine the appropriate resource to assign.

Available Action: Start Resolution (moves to In Progress)

In Progress

The In Progress status indicates that active work is underway to resolve the issue. The assigned user investigates the problem, implements a solution, and documents their findings in the Resolution field. Progress tracking is automatically updated to 25% when this status is set.

Available Action: Set Pending (moves to Pending, requires resolution documentation)

Pending

Issues move to Pending status when the assigned user believes they have resolved the issue and submits it for management review. The system requires resolution documentation before allowing this transition, ensuring that the reviewer has sufficient information to make an approval decision. Progress is updated to 75%.

Available Actions: Approve (moves to Resolved) or Back to Progress (returns to In Progress)

Resolved

The Resolved status indicates that a Project Manager has reviewed and approved the proposed resolution. The issue is considered solved from a technical perspective but has not yet been verified in production or by the end user. At this stage, tasks can be created from the issue if implementation work is required. Progress is set to 90%.

Available Actions: Verify & Close (moves to Closed), Create Task, or Reopen for Review (returns to Pending)

Closed

Closed issues have been verified as successfully resolved. This verification step, performed by a Project Manager, confirms that the resolution was effective and the issue no longer impacts the project. Progress is set to 100%. Closed issues can be reopened if necessary, though this should be rare in a well-managed process.

Available Action: Reopen for Verification (returns to Resolved)

Parking Lot and Lessons Learned Workflow

Parking lot items and lessons learned bypass the standard workflow entirely. When an issue is created with either of these classifications, or when an existing issue is reclassified to one of these types, the system immediately sets the status to Closed and records the Project Manager who made the decision along with the timestamp.

If the reclassification occurs during a project update meeting (when a project update record is active), the system automatically links the issue to that update. This creates a permanent record of when and why the decision was made, providing valuable context for future project reviews.

6. Working with Project Updates

Integration with Project Status Meetings

The module extends Odoo's project update functionality with real-time issue metrics and classification tracking. When you open a project update, you will see two groups of statistics: one showing the current status distribution of all project issues, and another showing the breakdown by classification type.

These metrics are computed in real-time based on the current state of the project's issues, providing an accurate snapshot of project health at the moment the update is viewed. This allows project managers to discuss current concerns during status meetings without worrying about stale data.

Issue Count Statistics

The status overview shows how many issues are in each stage of the workflow: New issues requiring assignment, In Progress issues being actively worked, Pending issues awaiting approval, and Resolved issues awaiting verification. Clicking any of these statistics opens a filtered view showing only the relevant issues.

The classification overview provides similar functionality, showing counts of Standard Issues, Change Requests, Feature Requests, Parking Lot items, and Lessons Learned. This helps teams understand not just the volume of work, but the nature and mix of concerns affecting the project.

Creating Parking Lot and Lessons Learned During Updates

When you create a parking lot item or lesson learned while a project update is active (status is "posted"), the system automatically associates that issue with the update meeting. This creates an audit trail showing which meeting discussed and decided to defer or document each item.

This linkage is valuable for project retrospectives and audits, as it provides context about when decisions were made and what information was available at the time.

7. Portal Access for External Users

Overview of Portal Functionality

The module provides comprehensive portal access, allowing external users such as clients, vendors, or partners to participate in the issue management process. Portal users can view issues related to their projects, create new issues, and track resolution progress without requiring full system access.

What Portal Users Can Do

Portal users access the system through a simplified interface optimised for their needs. They can view a list of all issues they have access to, which includes issues they reported and issues in projects where they are followers. The issue list shows key information such as status, priority, and current progress.

When viewing an issue, portal users see the complete issue history including the description, resolution (if provided), and all communication through the chatter. They can add comments to issues, attach files, and receive notifications when the issue status changes.

Portal users can create new issues directly through the portal interface. The creation form guides them through providing all necessary information, with the project and related task selections filtered to show only items they have access to.

Configuring Portal Access

To grant a portal user access to project issues, ensure they are added as a follower to the relevant project. Projects with portal visibility allow all portal users to see associated issues, while projects with more restricted visibility only show issues to followers.

Access Control: Portal users can always see issues they reported themselves, regardless of project visibility settings. This ensures they can track the resolution of problems they identified even if they are not project followers.

8. User Permissions and Security

Project User Permissions

Users with the Project User role can create issues, update issue details, and move issues through the workflow up to the Pending status. They can assign issues to themselves or other users, document resolutions, and link issues to tasks. Project users cannot approve pending issues, close resolved issues, or change issue classifications.

Project Manager Permissions

Project Managers have full control over the issue management process. In addition to all Project User capabilities, they can approve pending issues, verify and close resolved issues, and change issue classifications. The ability to reclassify issues is restricted to Project Managers because it can trigger automatic workflow actions, such as immediately closing parking lot items or lessons learned.

Security Rules

The module implements security rules to ensure portal users can only access appropriate issues. Portal users see issues from projects with portal visibility, issues where they are mentioned as followers, and issues they reported themselves. Internal users (Project Users and Managers) see all issues in projects they have access to based on standard Odoo project security.

9. Best Practices

Issue Creation Guidelines

Create issues as soon as problems or concerns are identified. Early documentation ensures nothing is forgotten and allows the project team to plan resolution work effectively. Be specific in issue titles, avoiding vague descriptions like "System Problem" in favour of precise statements like "Invoice Template Not Displaying Company Logo."

Provide comprehensive descriptions that include steps to reproduce problems, expected versus actual behaviour, and any relevant screenshots or error messages. The time spent on thorough documentation at creation saves multiple rounds of clarification questions later.

Classification Decisions

Use standard issues for any problem that needs to be fixed within the current project scope. Reserve change requests specifically for proposed modifications to agreed-upon scope or requirements. Feature requests should capture enhancement ideas that are valuable but not essential to current project success.

Be deliberate about parking lot classifications. These should represent items that truly can wait for future consideration, not problems that need to be addressed now but are being deferred due to resource constraints. The latter should remain as standard issues so the project team maintains visibility into the true backlog.

Document lessons learned while they are fresh. The most valuable organisational learning occurs when teams capture what worked well and what didn't immediately after experiencing it, rather than trying to remember during post-project reviews.

Workflow Management

Move issues through the workflow promptly. Issues that sit in New status for extended periods create uncertainty about whether work will happen. If an issue cannot be addressed immediately, assign it and set realistic expectations about when work will begin.

Require meaningful resolution documentation before moving issues to Pending status. The resolution field should explain what was done to address the issue, not simply state that it was fixed. This documentation proves valuable during future troubleshooting and helps verify that the resolution is complete.

Use the verification step (Resolved to Closed transition) as an opportunity to confirm that resolutions are effective in practice, not just theoretically sound. This might involve testing in production, confirming user satisfaction, or verifying that metrics have improved as expected.

Progress Tracking

The module automatically updates progress percentages based on workflow status, but you can manually adjust these if needed. Use the progress field to provide stakeholders with realistic expectations about completion, especially for complex issues that may spend extended time in In Progress status.

Communication

Use the chatter functionality to maintain a complete record of issue-related communication. This keeps all context in one place and ensures that anyone reviewing the issue can understand its complete history. Tag relevant stakeholders in chatter posts to ensure they receive notifications about important developments.

Copyright © 2018-2025 Cyder Solutions - All Rights Reserved

This documentation is the property of Cyder Solutions. Unauthorised reproduction or distribution is prohibited.