Release 0.1.2

[nesnoj]

Waiting for #64...

[henhuy]

After upgrading django, I ran into error:
AttributeError: /usr/lib/libgdal.so.1: undefined symbol: GDALGetMetadataDomainList

INstalling gdal into env via conda solved the problem.
Maybe we have to adjust environment.yml or Dockerfile as well to get rid of this error...
I will check!

Nice work !

When testing locally, I run against the error :

django.core.management.base.SystemCheckError: SystemCheckError: System check identified some issues:

ERRORS:
?: (urls.E007) The custom handler500 view 'wam.views.WAM500View' does not take the correct number of arguments (request).

if I comment the handlers of 404 and 500 in the wam/urls.py, then it works. I only get the following warning

UserWarning: No directory at: ~/Dokumente/repos/WAM/staticfiles/
  warnings.warn(u'No directory at: {}'.format(root))

I didn't test the feedback form (by adding it to an app) and server-down pages as I presume they were tested before the PR #65 and #70 got merged into develop Should I do it nevertheless?

Because of the above error, I will not approve this PR yet ;)

Same here with new Django version.
I think this is due to new error handler style.
See also:
https://docs.djangoproject.com/en/2.2/topics/http/views/#customizing-error-views

For handlers:

handler500¶

A callable, or a string representing the full Python import path to the view that should be called in case of server errors. Server errors happen when you have runtime errors in view code.

By default, this is django.views.defaults.server_error(). If you implement a custom view, be sure it returns an HttpResponseServerError.

[nesnoj]

Nice work !

When testing locally, I run against the error :

django.core.management.base.SystemCheckError: SystemCheckError: System check identified some issues:

ERRORS:
?: (urls.E007) The custom handler500 view 'wam.views.WAM500View' does not take the correct number of arguments (request).

As @henhuy already said, this seems to be a django 2.2 related issue. (cf. thread on SO)

I didn't test the feedback form (by adding it to an app) and server-down pages as I presume they were tested before the PR #65 and #70 got merged into develop Should I do it nevertheless?

You do not have to, @henhuy and I did..

[nesnoj]

After upgrading django, I ran into error:
AttributeError: /usr/lib/libgdal.so.1: undefined symbol: GDALGetMetadataDomainList

INstalling gdal into env via conda solved the problem.
Maybe we have to adjust environment.yml or Dockerfile as well to get rid of this error...
I will check!

@henhuy We had a serious GDAL django bug before which was really a pain in the ..., remember? We had to fix this manually. Does django 2.2 fix this?

EDIT: I was wrong, it was a problem with libgeos (django bug tracker). As it was merged I guess it's included in v2.2

[nesnoj]

@henhuy: Apart from #74 / #75 which should be definitely included, is there more WAM work to be done prior to the release?
(we can integrate #71 via hotfix later)

[nesnoj]

BTW: The current situation reveals that it might be a good idea to restrict the version range of packages to a specific release, in this case django 2.2. (before, the django 2.1-optimized code was tested with 2.2 all the time according to the current versionless test_requirements.txt which always uses the latest package versions).

[nesnoj]

I'd like to release today, let me summarize the work to be done:

• Merge PR Fixes/duplicate installed apps #75
• Wait for FRED app rewrites leaflet config WAM_APP_FRED#49
• Travis error with 502 Release 0.1.2 #73 (review)

[Bachibouzouk]

I'd like to release today, let me summarize the work to be done:
* [ ] Wait for rl-institut/WAM_APP_FRED#49

I don't have time to work on this today, the WAM core is independent of the WAM APP though, I think the release can be done and we'll make the fixes to WAM_FRED app on monday :)

[nesnoj]

the WAM core is independent of the WAM APP

Right, I ensured my app to work properly so it's ok for me. Just wanted to have everything fixed in one go :)

[nesnoj]

Ok, I fixed the Django 2.2 argument error by switching to function based views in 4f18c8e (couldn't make it with class-based ones).

Furthermore, the correct http status codes are now served (ba432f2).