Proposal for Structured Task IDs in Kanboard (e.g., MYPROJECT-12)

[e-labInnovations]

Introduction

I’d like to propose a new feature for Kanboard that involves changing the current task ID format from a simple row integer to a more structured format that includes the project identifier. This format would resemble the style used in tools like Jira, where task IDs are displayed as {{project identifier}}-{{task id}} (e.g., MYPROJECT-12).

Proposal:

The idea is to introduce a task ID format that combines the project identifier (which is already available in Kanboard) with the task’s unique ID. For example, if the project identifier is MYPROJECT and the task ID is 12, the new task ID would be MYPROJECT-12.

Benefits:

1. Improved Readability: This structured format would make task IDs more descriptive and easier to associate with specific projects.
2. Enhanced Organization: Particularly in environments with multiple projects, this format would help users quickly identify which project a task belongs to.
3. Consistency with Other Tools: Aligning Kanboard with other project management tools like Jira could ease the transition for teams switching to or from Kanboard.

Challenges:

1. Backward Compatibility: It’s crucial to consider how this change would affect existing tasks. A migration path might be necessary to update the IDs of existing tasks.
2. Database Impact: We would need to explore how this change would impact the database schema. Specifically, whether additional indexing or changes to primary keys would be required.
3. User Adoption: Should this be an optional feature that admins can enable per project, or should it be the default behavior? We need to consider how users would adapt to this change.

Implementation Details:

1. Configurable Option: The feature could be implemented as an optional setting that project administrators can enable or disable. This would allow users to adopt the new format gradually.
2. ID Generation Logic: The system should handle scenarios where the project identifier is modified after task creation, or where tasks are moved between projects. It’s important to ensure that IDs remain unique and consistent.
3. Potential Issues: We need to discuss how to handle duplicate project identifiers or tasks with no associated project identifier.

Request for Feedback:

I’d love to hear the community’s thoughts on this proposal. Specifically, I’m interested in:

• Use cases where this feature would be particularly beneficial.
• Potential challenges or downsides that I may not have considered.
• Any suggestions for the implementation approach.

Looking forward to your feedback and insights!

[fguillot]

Thank you for proposing this change. That sounds like a good idea.

From a user point of view, this feature could be enabled implicitly when the project identifier is defined (assuming the implementation is backward compatible).

To implement this, a new field called number could be added to the tasks table. This field would store the task number specific to each project. For instance, if a user has defined a project identifier MYPROJECT, a task could be referenced as MYPROJECT-123. This way, the exiting task ID is unchanged to maintain backward compatibility, and users can easily change the project identifier without affecting the task numbering.

Another possibility is to add a new field called identifier to the tasks table. This field would store a combined string of the project identifier and the task number, such as MYPROJECT-123. This approach offers some advantages: faster database lookups and uniqueness across all projects. However, it also has a notable drawback: changing the project identifier would be impractical, as it would require updating this field for all tasks within the project.