in migration process this colum was not filled

It was a design decision taken at the time this feature was implemented, not to try and populate the new mantis_bug_file_table's bugnote_id field, i.e. leave its value to its default of 0. See https://github.com/mantisbt/mantisbt/pull/1529.

For the record, there are 3 distinct states:

• 0 - file was added pre-2.23.0, it is therefore not explicitly linked to an issue or a note.
• null - file was added by 2.23.0 or later, and is associated with the issue.
• number >= 1 - file was added or linked by 2.23.0 or later and associated with the specified bugnote id .

When displaying issue activities, MantisBT will show bugnotes and attachments submitted by the same user at the same time (within delay defined by issue_activity_note_attachments_seconds_threshold config) combined in a single entry. This is the so-called implicit link Note that this is for display only, the database is not updated.

Currently the only action that actually updates the field (i.e. makes it an explicit link), is a change in visibility of the associated bugnote (i.e. public -> private or vice-versa).

Attachments with bugnote_id == 0 but not matching a bugnote, are treated as bug-level attachments, and therefore listed under Attached Files in the View Issue Details section. Again, this was a design decision; I guess it's arguable, but that's the way it is.

how could you solve this data problem?

I assume you mean moving the attachments with bugnote_id == 0 back down to the activity list, inserted in the appropriate sequence based on when the attachment was uploaded.

Technically, this just requires creating a new bugnote (and related bugnote text record) having a date_submitted (and last_modified) timestamp equal to the attachment's date_added.

As of this writing, his can't be done from the MantisBT GUI. One way to do it for individual files would be to add a button next to the attachment, that would call the necessary APIs to perform the above-mentioned tasks. It should be fairly simple to implement.

A global approach (i.e. batch job to update all attachments in one go, possibly as a database upgrade step, would be more complex but that's feasible as well although I would not recommend this approach because there is no way to know the intention of the person who uploaded the file (i.e. if it was meant to be a bug-level attachment, or a bugnote without text).

Pull requests welcome.

As of this writing, his can't be done from the MantisBT GUI. One way to do it for individual files would be to add a button next to the attachment, that would call the necessary APIs to perform the above-mentioned tasks. It should be fairly simple to implement.

Feature requested in 0023026 is another approach that could work too.