Enable automatic numbering for engagements using a customizable format (e.g., ENG-0001).

[Fatte1254]

⚠️ Note on feature completeness ⚠️

We are narrowing the scope of acceptable enhancements to DefectDojo. Learn more here:
https://github.com/DefectDojo/django-DefectDojo/blob/master/readme-docs/CONTRIBUTING.md

Is your feature request related to a problem? Please describe
A clear and concise description of what the problem is.
Problem:
Each new engagement currently displays no unique Engagement ID in the UI

Describe the solution you'd like
Solution:
Implement the ability to assign a customized engagement identifier (e.g., ENG-0001) that is automatically generated each time a new engagement is created.
This ensures consistent and traceable engagement numbering for easier reference, reporting, and integration with other systems.

[valentijnscholten]

Thank you for submitting your enhancement request, this is something we would welcome a community PR for!

[PoojasPatel013]

Can I pick this up if nobody's working on this?

[valentijnscholten]

Yes thank you

[PoojasPatel013]

Update on Implementation

I have successfully implemented the backend logic for auto-generating IDs (ENG-XXXX)

Pending Edge Case:
It appears that when an engagement is deleted, it may still exist in the database (soft delete) or affect the calculation of the last() ID, causing the increment logic to behave unexpectedly. Still figuring out why it's happening, it will take time ig.
I am adjusting the save() query to ensure it handles deleted objects properly. If you have any suggestions, let me know, thanks!!

[valentijnscholten]

Can you create a draft PR?

[PoojasPatel013]

hi @valentijnscholten
opened #13862

[valentijnscholten]

@PoojasPatel013 Can you open a PR? Please include only your changes and no whitespace changes etc.

It appears that when an engagement is deleted, it may still exist in the database (soft delete) or affect the calculation of the last() ID, causing the increment logic to behave unexpectedly. Still figuring out why it's happening, it will take time ig.
I am adjusting the save() query to ensure it handles deleted objects properly. If you have any suggestions, let me know, thanks!!

I think you're using the id field of the engagement table. This is an ever only increasing counter and am not sure if it's the best choice to use as the counter as it will be unique across the whole instance.

[PoojasPatel013]

Thanks for the feedback. @valentijnscholten
To clarify my design choice: I actually attempted to implement a strictly sequential counter initially (Method 1), where the system would respect a user-defined format and increment the count based on the last entry. And that resulted in Pending Edge Case: It appears that when an engagement is deleted, it may still exist in the database (soft delete) or affect the calculation of the last() ID, causing the increment logic to behave unexpectedly this particular case, so I switched to using the database Primary Key (id) because it is the only native mechanism that guarantees uniqueness and concurrency safety without requiring a separate "Sequence Table" or complex locking logic to handle soft deletes. While I agree id is global (not instance-specific) and leaves gaps on deletion, I've decided to stick to this approach since it feels like soft delete issue is where i am getting stuck on !

[valentijnscholten]

Thank you for your contribution. But I don't see how this can be implemented without adding a new field to the Product table to keep track of the latest sequence number. That numbers will not be reused after a delete is not a problem.
The currently proposed solution without that new field will generate non useful numbers. For example in my instance I would for a new product get a new engagement with ENG-1234. And then tomorrow on a new engagement I would get for example ENG-1337. I don't think comes close enough to the feature request.

[PoojasPatel013]

However, implementing that schema change and ensuring it handles the edge cases (concurrency and soft-deletes) robustly is a little bit outside the scope of the time I can commit right now, though my previous attempts confirmed that without that dedicated field, the uncertainties are too high.. Since I can't deliver the feature with the level of quality/utility you described, I will step aside so I don't block the issue.
Someone else can pick up the schema-based approach. Thank you for your mentorship and the quick reviews! 🙂