[Kde-pim] Review Request 109265: Store collection paths instead of collection ids in filter configuration. Part 2/2

[Laurent Montel]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109265/#review28551
-----------------------------------------------------------


Question:
if we rename collection outside kmail how it will get collectionid ?
For example.
collection number 5 == foo/foo/bla

we rename it outside kmail => foo/bla/bla

when you will reload filter it will not obtains it no ?

And for sync between computer I implemented export filter with save as path and we reload it and have a lot of dialog box to try to get collection.
But it's just when we import/export.

With our patch it will ask for each filter each time that we will load them no ?

I am not sure that it's optimum.

- Laurent Montel


On March 3, 2013, 5:40 p.m., Andras Mantia wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109265/
> -----------------------------------------------------------
> 
> (Updated March 3, 2013, 5:40 p.m.)
> 
> 
> Review request for KDEPIM, Laurent Montel and Volker Krause.
> 
> 
> Description
> -------
> 
> Currently the filter configuration contains a collection id. This id is specific to a single akonadi instance, thus making impossible to synchronize the configuration file between computers and also invalidates all the filters in case of Akonadi database corruption and recreation.
> The patch:
> - extends Util::fullCollectionPath to operate on real names if requested (needed, as otherwise we can't get back the collection id from a path)
> - changes the filter action with folder type filter action (;)) to return the path and adds code path so they can read both ids and paths from the config files
> - uses "export" flag when saving the filter config file, so actually the argsAsRealString() is called on the actions, not argsAsString(). 
> This could be debatable, I could also change argsAsString() to return the path instead. Sincerely I don't see why we need different code path for exporting...
> 
> 
> Diffs
> -----
> 
>   mailcommon/filter/filteractionwithfolder.h 46ee8e7 
>   mailcommon/filter/filteractionwithfolder.cpp 0795c30 
>   mailcommon/filter/filtermanager.cpp bfa8246 
>   mailcommon/mailutil.h 5441b9f 
>   mailcommon/mailutil.cpp 67e0645 
> 
> Diff: http://git.reviewboard.kde.org/r/109265/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Andras Mantia
> 
>

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/