Most JPG image attachments are not found after PartKeepr import

[mindsolve]

Describe the bug
After importing the data from PartKeepr, following the instructions, some attachments are not available/marked as "not found" in the UI.

Based on my research, the file extension does not match for JPEG images, where the extension field in the PartKeepr DB is empty. PartDB assumes the extension to be .jpg, while PartKeepr used .jpeg (at least in my instances). In the PartDB database, the filepath is recorded as %SECURE%/PartAttachment/6f8b40d2-1976-11e8-928b-0242c84f1654.jpg, whereas the actual file lives at %SECURE%/PartAttachment/6f8b40d2-1976-11e8-928b-0242c84f1654.jpeg.

To Reproduce
Steps to reproduce the behavior:

1. Import PartKeepr database and attachments according to https://docs.part-db.de/partkeepr_migration.html
2. Open a part with a JPEG attachment
3. Observe the File not found marking on the attachment

Expected behavior
I expected PartDB to be able to view all attachments that were visible in PartKeepr.

Screenshots

• Not working attachment in PartDB
  
• Working attachments in PartKeepr
  

Server Side

• Part-DB Version: Part-DB master @ 8bb8257e627eef0e77523980a6734cfa4e4cc098
• PHP Version: PHP 8.1.2-1ubuntu2.11
• Database Server: none, sqlite
• Server OS: Ubuntu 22.04.2 LTS

Desktop (please complete the following information):

• OS: Windows 10 x64
• Browser: Firefox
• Version: 113.0.1

Smartphone (please complete the following information):
n/a

Additional context

• Database entry in PartKeepr database:

  +-----+---------+----------------+--------------------------------------+-----------------+------------+-------+-----------+-------------+---------------------+---------+
  | id  | part_id | type           | filename                             | originalname    | mimetype   | size  | extension | description | created             | isImage |
  +-----+---------+----------------+--------------------------------------+-----------------+------------+-------+-----------+-------------+---------------------+---------+
  | 144 |     257 | PartAttachment | 6f8b40d2-1976-11e8-928b-0242c84f1654 | com-max232n.jpg | image/jpeg | 86281 |           | NULL        | 2018-02-24 15:21:50 |    NULL |
  +-----+---------+----------------+--------------------------------------+-----------------+------------+-------+-----------+-------------+---------------------+---------+
  

• Database entry in PartDB database:

  id   type_id  original_filename  path                                                              show_in_table  name             last_modified        datetime_added       class_name  element_id
  ---  -------  -----------------  ----------------------------------------------------------------  -------------  ---------------  -------------------  -------------------  ----------  ----------
  529  1        com-max232n.jpg    %SECURE%/PartAttachment/6f8b40d2-1976-11e8-928b-0242c84f1654.jpg  0              com-max232n.jpg  2023-05-01 23:15:43  2018-02-24 15:21:50  Part        257
  
  

[jbtronics]

PartKeepr seems to use just the second part of the mimetype (e.g. "jpeg" of "image/jpeg"), when no explicit extension was set. That also meant that the file extension of the saved file were jpeg, even if the uploaded file had a jpg extension.
I changed the import function to emulate the PartKeepr behavior and with the latest master commits it should work properly.

I also fixed some import bugs related to importing price information of Parts: Now currencies are correctly imported too.
However in cases where there are the same price informations, but in different currencies, you will have to delete the prices in one of the currencies, when editing the part the next time. Part-DB automatically calculates prices in your favorite currency based on a defined exchange rate, and giving one price in multiple currencies could lead to conflicts.

[mindsolve]

Thanks a lot! Just to make sure I understand correctly: I have to re-import the PartKeepr Database for this fix to work?

[jbtronics]

Yes. The change was in the import routine, so you have to redo the import (which also means that your database will be purged again).