Bug 312496 - PIM items are saved with the Akonadi item ID as their filename on drag n drop
Summary: PIM items are saved with the Akonadi item ID as their filename on drag n drop
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.9
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-02 17:56 UTC by Antonis Kanouras
Modified: 2017-01-07 22:15 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antonis Kanouras 2013-01-02 17:56:20 UTC
When drag n dropping a PIM item (mail/contact/event) from one of the KDEPIM applications to a folder in a Dolphin window, the saved item's filename is just the Akonadi item ID, with no extension.

It would be great if at least the item's subject were used instead, and even better if it was customisable in a printf-style option hidden somewhere.

Reproducible: Always

Steps to Reproduce:
1. Open a KDEPIM application's window side by side with a Dolphin window
2. Drag an item from the KDEPIM application to the folder widget in Dolphin's window
Actual Results:  
The created file has a name like "2314"

Expected Results:  
The created file would have a name like "My test email.eml" or "John Doe.vcf" or "My test event.ics"; even better if it could be something like "20130102_John Doe_Hi from Spain.eml" in the case of emails.

I should note here that most other PIM clients work this way.

Also, it would be nice if the file's mtime was set equal to the email's Date header, if the item was an email.

As I would like to gradually get into KDEPIM development, I would appreciate some pointers on how to proceed with implementing this feature, although, being only a beginner in C++, I'm not sure I'm up to the task.
My first thought was reading the items in AkonadiSlave::entryForItem(), however I feel it's not the proper solution.

Thank you for your work!

PS: I have left the severity as bug because of the lack of a file extension, making life too hard for ordinary Windows users (we still have some of them) as Windows Explorer does not inspect the file's contents.
Comment 1 Denis Kurz 2016-09-24 20:37:55 UTC
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 2 Denis Kurz 2017-01-07 22:15:46 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.