View Issue Details

IDProjectCategoryView StatusLast Update
0020605mantisbtcustom fieldspublic2016-09-02 09:28
Reportermantisiator Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status newResolutionopen 
Summary0020605: Secondary Key Issue counter automatically filled per "stable" project
Description

Hi,

Please let me come back to the Issue 10920 stating :
"
Is there any way to have an automatic number as custom field ?

The issue number is global to all projects defined in a Mantis instance, but I would like to have a field which is dependent of the project in order to log "the issue order in this project".

Additional Information
Example:

Project 1 - issue 001 - order 001
Project 2 - issue 002 - order 001
Project 3 - issue 003 - order 001
Project 2 - issue 004 - order 002
Project 2 - issue 005 - order 003
Project 1 - issue 006 - order 002
... etc ... "

This issue has raised a comment stating that the secondary key would not be "significant" in case one issue is moved from a Project to another, which I can understand.
Having said that, this field would be of interest in case the Mantis projects include -by design- issues that can "semantically" not be moved cross projects.

What do you think ?

Thank you very much in advance !

TagsNo tags attached.

Relationships

related to 0010920 closedatrol automatic number custom field 
related to 0005715 closedthraxisp Issue ID for each project 

Activities

cproensa

cproensa

2016-02-15 06:47

developer   ~0052518

This is a very specific request.
I don't think its useful to implement natively the suggestions

Currently a feasible way to achieve that is create a custom plugin that maintains that numbering, making use of events:

  • your seq_id can be stored in a custom field, or a customized table managed by the plugin
  • EVENT_REPORT_BUG on bug creation, fill the seq_id.

Moving between projects is still an issue, but could be solved by:

  • EVENT_BUG_ACTION captured after the move is done, then plugin updates the bug with new valid values
  • (after solving 0020577) with EVENT_UPDATE_BUG_DATA, block the move action with an error
mantisiator

mantisiator

2016-02-15 07:41

reporter   ~0052519

Thanks a lot for your comment.

For additional information, this feature can also be used when moving from an Issue Tracking system to another system. In fact , in that case, the secondary key could be used to keep track of the former system numbering (in my case, the former system allows a numbering per project. Thereofore, having that feature could allow an easy migration)

mantisiator

mantisiator

2016-09-02 03:50

reporter   ~0053927

Hi @cproensa,
Please let me come back to that item.
Further to review, the issue has already been raised in

0005715: Issue ID for each project

Indeed, the counter feature could be a generic -native- feature "per project" in case we use (which is also my case, reducing herewith the maintenance/intallation effort) a single Mantis installation in order to manage several projects.
What's more, as a simplification concerning the "Move" point you have raised (used rarely in case of indenpendant projects), we could imagine resetting the counter via an SQL request (as for the AUTOINCREMENT for the present unique key).

What do you think ?