[Kmymoney-devel] Review Request: Add profiles to csvplugin to retain user's settings

[Allan]

On 21/12/11 20:49, Jack wrote:
> On 2011.12.21 15:39, Allan wrote:
>> On 21/12/11 19:49, Jack wrote:
>>> On 2011.12.21 13:37, Allan Anderson wrote:
>>> .......
>>>> That's the theory, anyway, but unfortunately, it's not always as
>>>> straight forward as that. In general, though, banking files should
>>>> be straight forward, but the 'last line' setting could cause a
>>>> problem if there are trailer lines that need to be dropped.
>>>
>>> Should/could the "last line" setting be the number of lines to ignore
>>> at the end, rather than the actual number of the last line to
>>> include? (The display could show either or both, but I'm asking about
>>> what is actually saved.)
>>
>> I implemented it that First Line is the first line to include, and
>> Last Line is the last to include.
>>
>> The Last Line setting is set by the plugin as the last line in the
>> file, but that could possibly be an unwanted trailer line that the
>> user would elect to drop. I do not therefore save the last line
>> number. If it was saved, but the new file had a greater number of
>> lines, those additional lines could get dropped if a previous setting
>> was used. I could scan the Date column and stop at the last line with
>> a valid date, but would probably need to warn the user about lines
>> being dropped.
>>
>> So what actually happens now is that, in profile mode, the detected
>> last line is taken to be the actual last line. If it is in fact a
>> trailer line, then the date validity check is likely to find a problem
>> and warn the user. Now, this raises an error and the wizard restarts
>> at the page after the intro page, allowing the user to move to the
>> lines setting to make a correction.
>
> In my experience, from a single source, you generally get the same
> number of trailer lines that have to be dropped, so if you were to save
> that, it would be likely to apply correctly the next time. I agree
> saving the actual last line to import is not useful. I suppose you could
> label it as "number of trailer lines to ignore" and then calculate and
> display but not save the actual last line to import.
>

In profile mode, though, the page where this would get displayed is 
skipped.  What could be done on these lines, though, is, when the 
profile is created, to leave the UI as it is, subtract the user's input 
of last line from the actual last line number, and save the "number of 
trailer lines to ignore" in the resource file.  Then, when in profile 
mode, deduct the saved number from the actual number and use the result. 
  That would avoid the potential problem with a differently sized file, 
and without having an ungainly "number of trailer lines to ignore" label.

>>>> When a profile is used, on completion of the import process, the
>>>> final wizard page has 'lost' its Back button (that is, it's
>>>> disabled). This, I'm pretty sure, is because, with several pages
>>>> being skipped, there is no 'history' available to the wizard.
>>>
>>> Could the "back" button go to the first page of the wizard, or does
>>> the whole wizard mechanism not allow that?
>>
>> In profile mode, after the file is read in, the wizard is set to start
>> at the completion page. I actually spent quite some time trying to
>> re-enable the Back button, but failed. As a test, I set it to start at
>> the page prior, and then used Next to get to the completion page.
>> Doing this allowed the Back button to appear. So, at this point, it is
>> my belief that the wizard knows of no prior page so disables the Back
>> button. There is a slight hint of this in the docs., but it refers to
>> having used the Commit page setting, but that helped confirm my
>> suspicion. So the user has to exit after using profile mode, but
>> that's probably as quick as backing up through several pages.
>>
>> Incidentally, the csv file you sent me a while back has a trailer line
>> which nicely triggers the error detection, allowing the user to
>> intervene. I've left its settings in the new resource file.
>>
>> Another re-write of the docs. looms, I'm afraid.
> Quite expected. Probably best to let the interface stabilize first, though.

Yes, those were my thoughts, too.

Allan