[libalkimia] [Bug 439411] New: Add support for downloading online prices based on a date range

[Ralf Habacker]

https://bugs.kde.org/show_bug.cgi?id=439411

            Bug ID: 439411
           Summary: Add support for downloading online prices based on a
                    date range
           Product: libalkimia
           Version: 8.1.0
          Platform: Other
                OS: All
            Status: REPORTED
          Severity: wishlist
          Priority: NOR
         Component: General
          Assignee: kmymoney-devel at kde.org
          Reporter: ralf.habacker at freenet.de
  Target Milestone: ---

SUMMARY
With kmymoney5, support for WebPriceQuote has been extended to download online
prices based on a date range, which is currently missing in alkimia.

In kmymoney this is done by connecting the WebPriceQuote::csvquote() signal to
a method, then calling the WebPriceQuote::setDate(from, to) [1] method,
followed by a call to WebPriceQuote::launch(...) which triggers the mentioned
signal. The signal returns the queried online prices in an instance of a class
known only to kmymoney. Another method would have to be used here. 

Currently there is the following signal defined:

    void quote(const QString&, const QString&, const QDate&, const double&)

To cover multiple values an additional signal should be added providing a map
of online prices

    void quote(const QString&, const QString&, QMap<QDateTime, double>); 

The type QDateTime was chosen to support also dates with times. [2]

The URL used to download such online prices can contain variables to replace
year, month and day, as seen in the following example: 
http://www.nasdaqbaltic.com/market/?instrument=%1&pg=details&tab=historical&lang=en&date=&start=%d.%m.%y&end=%d.%m.%y&pg=details&pg2=equity&downloadcsv=1&csv_style=english
[3]

An implementation would need to support this, but also alternative dates, for
example in Unix time format, as can be seen in this example: 
https://query1.finance.yahoo.com/v7/finance/download/ORCL?period1=1593696392&period2=1625232392&interval=1d&events=history&includeAdjustedClose=true.

The supported variable names should be unique for the start and end dates to be
immune to a change in parameter order, which is not the case for [3].

For [1] a better method name would be setDateRange(...) and the parameter types
should be changed to QDateTime for the same reasons mentioned at [2], so the
complete signature is setDateRange(const QDateTime &from, const QDateTime &to).

-- 
You are receiving this mail because:
You are the assignee for the bug.