Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

from_date greater than 3 years ago gives initially displayed transactions and does not create an error. #7

Open
inktrap opened this issue Jan 9, 2016 · 4 comments

Comments

@inktrap
Copy link

inktrap commented Jan 9, 2016

I tested this via dkbweb.py which calls dkb.py, so this should apply to dkb.py as well.

If you specify a from_date like 1.1.1970, you won't get an error from mechanize. But it triggers another issue: The csv export will only contain the initially visible transactions because the date is not submittable. This means that the page won't update and the csv-file won't be generated with the new dates.

I "fixed" this for myself by fetching all the transactions from the last year every time and later I filter the results via sets. See: https://github.com/inktrap/dkb-export/blob/master/dkbweb.py#L215. Btw.: I also checked that BASEURL is an https-url. :)

Edit: Just to clarify: The allowed from_date is set server side and constant.

@hoffie
Copy link
Owner

hoffie commented May 29, 2016

Hm, I am not sure I understand. A quick test revealed that changing the from_date does work for me. I guess there may be DKB-side limits how long you can go back in time...?
So, either I misunderstand or there must be some other difference between your test and mine. :)

Regarding the HTTPS-enforcement: As the URL is hardcoded and not user-changable, I think it is OK to leave it as-is.

@hoffie
Copy link
Owner

hoffie commented May 29, 2016

Ok, now I see -- the web interface only returns about one year of data, if I see it correctly. Yes, this is a limitation, but I do not see any way to overcome this besides integrating locally "archived" data.

@okurz
Copy link

okurz commented May 30, 2016

well, at least the error handling could be improved on the side of dkb-visa. If I set 01.01.1970 in the current version and submit, the UI automatically sets to the first date possible, 01.06.2015, and tells with a popup field: "Die Eingabe wurde systemseitig angepasst."

@inktrap
Copy link
Author

inktrap commented May 30, 2016

Yes, that is the behaviour I ment: dkb falls back to the date where you
they have data. So the user of the script should be informed that they
don't get what they asked for.

Just FYI: In my fork I set the based on todays date minus two years and 11 months.
that way I get all the transactions. Then I wrote some code to
deduplicate the transactions.

Excerpts from Oliver Kurz's message of 2016-05-29 23:01:30 -0700:

well, at least the error handling could be improved on the side of dkb-visa. If I set 01.01.1970 in the current version and submit, the UI automatically sets to the first date possible, 01.06.2015, and tells with a popup field: "Die Eingabe wurde systemseitig angepasst."


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#7 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants