Closed DocCyblade closed 7 years ago
This is an upstream issue no resolution yet
@JedMeister - This too is an upstream bug, however I think I may be on the verge of solving it, again like I asked on issue #28 if I do find a fix, should we patch it here, and submit our findings upstream?
That other one is different as the patch is already there. If you develop a patch yourself, push it upstream!
In the meantime it's fine to patch within the appliance as per my other comment.
I just added more testing info to the upstream issue on gitlab. The maintainer Roberto Rosario has tagged it with v2.1.4, I am not sure when that will be released.
On an interesting note, it seems that FireFox browser works, but Chrome just shows HTML code an Safari just downloads the file. The issue is that Mayan for whatever reason is returning the Document Type header as "Document" instead of HTML, so thats why some browsers depending how strict they are will behave differently. I have forked the repo on gitlab and trying to take apart code to help with a resolution, but I am just learning Python and Django
Great work Ken! Good on you mate. :+1:
It seems the issue was found upstream:
[Roberto Rosario]() wrote on issue 311 on gitlab
The cause for the issue was rather obscure. The Django database ORM has an object clasification system called ContentTypes which is totally unrelated to the HTTP content types. Since the event and ACLs views work with different object types (Document, Folders, Tags), they store the ORM ContentType in the context of the view instance using the variable self.content_type. The Django views that were being used took the variable self.content_type and used it to override the value of the HTTP reponse's content type.
Looking at the internals confirms this:
response_kwargs.setdefault('content_type', self.content_type) it looks like the Django developers made this choice to allow setting the content type of the response of a view without having to intercept the response generation.
In my opinion the Django developers should have made the view's self.content_type variable a private variable by prepending Python's underscore self._content_type.
There is now a mixin that will test all the views being tested for the correct 'html' content type making detecting regressions of this easier in the future. The permanent fix for this issue is to never use self.content_type in views. Previous instances of self.content_type were renamed to self.object_content_type.
Per upstream dev, 2.1.4 should be released next week as long as no there bugs are found
Looks like v2.1.4 will be released today. Will work on upgrading this version in build and close this once I confirm it's fixed
Version 2.1.4 is out and uploaded to PyPI. Thanks for the help finding out the cause of this issue.
@rosarior thanks for the quick turn around. As you can see from this repo I am working on a Turnkey Linux as I have picked Mayan to be my personal EDMS at home, and being a TKL dev I thought it would make a great addition to the TKL Library
@DocCyblade That is great to hear, I didn't knew TurnKey Linux existed! Will post a link to it in the ecosystem page once it is release. Awesome work!
@rosarior once the appliance is accepted and TKL releases it I'll tag you in a post. On a side note, I'll be happy to test new releases in the future. I'll be converting 5000 documents into Mayan and I can use this as a test as well.
Closing this, upstream has been updated and I have confirmed code builds and tests correct
When clicking any ACL button you get a page with just html code, not rendered