You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that issue #15 is completed, I would love to help out with this Bugzilla migration feature if you are open to assigning it to me.
Could you please let me know if you have a specific Bugzilla CSV export sample, version, or default column format in mind for the field mapping?
Once I have a sample to test against, I can dive into the new framework and start mapping the data.
Thanks for the details. I will go ahead and set up a local Bugzilla installation to generate a default CSV export and use that as the baseline for the initial mapping.
Hi @jesperpedersen, I've opened a docs PR for #132 with a proposed Bugzilla mapping, based on exports from local Bugzilla 5.0 and 5.2 installs. Could you confirm or adjust these choices?
Company and entitlement: Bugzilla has neither. I'd propose selecting them on the import page and applying them to every row. Would you prefer another approach?
Base URL: The CSV has no bug URL. I'd propose entering the Bugzilla base URL on the import page to build the link to the source bug.
Timestamps: opendate has no time zone (it follows the exporting user's setting). I'd propose a time zone field on the import page, defaulting to UTC.
Status: the CSV doesn't say whether a status is open or closed. I'd propose RESOLVED, VERIFIED, and CLOSED -> "Closed"; everything else -> "Open".
Product, component, assignee, and resolution would go into the initial message text. Descriptions and comments would need the Bugzilla REST API, so I'd leave them out for now. The import would expect the raw field names in the header (the CSV button in Bugzilla adds human=1, which gives labels instead).
Bugzilla 5.0 and 5.2 installs. Could you confirm or adjust these choices?
Yeah, that is good
Company and entitlement: Bugzilla has neither. I'd propose selecting them on the import page and applying them to every row. Would you prefer another approach?
No, that sounds good
Base URL: The CSV has no bug URL. I'd propose entering the Bugzilla base URL on the import page to build the link to the source bug.
What do you mean ? TheBugZilla system will be shut down
Timestamps: opendate has no time zone (it follows the exporting user's setting). I'd propose a time zone field on the import page, defaulting to UTC.
Sounds good
Status: the CSV doesn't say whether a status is open or closed. I'd propose RESOLVED, VERIFIED, and CLOSED -> "Closed"; everything else -> "Open".
Agreed
Product, component, assignee, and resolution would go into the initial message text. Descriptions and comments would need the Bugzilla REST API, so I'd leave them out for now. The import would expect the raw field names in the header (the CSV button in Bugzilla adds human=1, which gives labels instead).
I think the important part is to document which fields we support in the import, and how they map.
On the base URL: the Bugzilla CSV only contains the bug_id, not a link to the bug. The import can use the base URL to build external_issue_link (base URL + show_bug.cgi?id= + bug_id), so each ticket links back to the original bug.
But since Bugzilla will be shut down, that link would eventually point nowhere, so I’d make the base URL optional:
If it’s filled in (for example, while Bugzilla is still online or archived read-only), external_issue_link is set as described.
If it’s left empty, external_issue_link stays empty. The original bug is still traceable through source_key (the bug_id) and the “Imported from Bugzilla bug # 101” line in the initial message.
On documenting the supported fields and mapping: that’s already in the PR: #204, in doc/manual/en/60-import.md:
Field mapping lists every supported field and where it comes from in the Bugzilla CSV
Status explains how Bugzilla statuses map to Open/Closed
Initial message shows which Bugzilla fields go into the message text, with an example
Limitations lists what is not imported
Activity
Abdelrhman1326 commentedon Oct 22, 2026
Hi @jesperpedersen ,
Now that issue #15 is completed, I would love to help out with this Bugzilla migration feature if you are open to assigning it to me.
Could you please let me know if you have a specific Bugzilla CSV export sample, version, or default column format in mind for the field mapping?
Once I have a sample to test against, I can dive into the new framework and start mapping the data.
Thanks!
jesperpedersen commentedon Oct 22, 2026
@Abdelrhman1326 No, I havn't. I believe that all Bugzilla installation start out with a default "schema" and then customize it.
You will have to do an installation and see how it is exported to CSV...
Long term we probably need a CSV "editor" that can translate from one format to ours
Abdelrhman1326 commentedon Oct 23, 2026
Thanks for the details. I will go ahead and set up a local Bugzilla installation to generate a default CSV export and use that as the baseline for the initial mapping.
jesperpedersen commentedon Oct 23, 2026
@Abdelrhman1326 Excellent !
Maybe the "editor" can "detect" which columns we need in order to fill out our model.
If you find any tables/columns we maybe should have - then we should have a discussion about.
For now, go ahead with your current plan - and start the pull request with the overall documentation for this area
Abdelrhman1326 commentedon Oct 23, 2026
Sounds good, I'll get started on the local setup and open the documentation PR shortly
Abdelrhman1326 commentedon Oct 25, 2026
Hi @jesperpedersen, I've opened a docs PR for #132 with a proposed Bugzilla mapping, based on exports from local Bugzilla 5.0 and 5.2 installs. Could you confirm or adjust these choices?
Product, component, assignee, and resolution would go into the initial message text. Descriptions and comments would need the Bugzilla REST API, so I'd leave them out for now. The import would expect the raw field names in the header (the CSV button in Bugzilla adds human=1, which gives labels instead).
PR: #204
jesperpedersen commentedon Oct 25, 2026
Yeah, that is good
No, that sounds good
What do you mean ? TheBugZilla system will be shut down
Sounds good
Agreed
I think the important part is to document which fields we support in the import, and how they map.
We just need something to get started with
Abdelrhman1326 commentedon Oct 25, 2026
Thanks for the review!
I mean:
On the base URL: the Bugzilla CSV only contains the bug_id, not a link to the bug. The import can use the base URL to build external_issue_link (base URL + show_bug.cgi?id= + bug_id), so each ticket links back to the original bug.
But since Bugzilla will be shut down, that link would eventually point nowhere, so I’d make the base URL optional:
If it’s filled in (for example, while Bugzilla is still online or archived read-only), external_issue_link is set as described.
If it’s left empty, external_issue_link stays empty. The original bug is still traceable through source_key (the bug_id) and the “Imported from Bugzilla bug # 101” line in the initial message.
On documenting the supported fields and mapping: that’s already in the PR: #204, in doc/manual/en/60-import.md:
Field mapping lists every supported field and where it comes from in the Bugzilla CSV
Status explains how Bugzilla statuses map to Open/Closed
Initial message shows which Bugzilla fields go into the message text, with an example
Limitations lists what is not imported
[mnemosyne-systems#132] Document Bugzilla migration
[mnemosyne-systems#132] Document Bugzilla migration
[mnemosyne-systems#132] Update Bugzilla documentation
[mnemosyne-systems#132] Document Bugzilla migration
[#132] Document Bugzilla migration