This changes the user agent to include the app name in API requests. https://trello.com/c/qkHdtob4/247-bump-gds-api-adapters-everywhere-it-s-used-to-include-user-agent-information
Vulnerabilities addressed: - CVE-2015-3225 https://groups.google.com/forum/#!topic/rubyonrails-security/gcUbICUmKMc - CVE-2015-1840 https://groups.google.com/forum/#!topic/rubyonrails-security/XIZPbobuwaY - CVE-2015-3226 https://groups.google.com/forum/#!topic/rubyonrails-security/7VlB_pck3hU - CVE-2015-3227 https://groups.google.com/forum/#!topic/rubyonrails-security/bahr2JLnxvk Notably, this upgrades jQuery from 1.10.x to 1.11.x. Release "notes" for this: http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/
Instead of getting a list of organisations and iterating over it, get the relevant organisation directly from the API Add spec for resolving an organisation slug to a title
Filtering should be possible by just organisation by itself but also by both path and organisation at the same time. - Permit params[:organisation] and add it to the terribly named 'at least one required' list of API parameters. - Stop depending on params[:path] for Feedex page header, breadcrumbs, etc.
- Stop parsing dates in the controller action. - Stop relying on instance variables and params from these helper methods. This had the added benefit of being able to write object-focussed specs instead of having to setup the environment beforehand, if you see what I mean. - Move the date filters-specific methods to a DateFiltersPresenter. - Move the remaining method to a more generic FeedexHelper (because it's not date filters-specific, didn't seem like it should live in the new object). All of this probably wouldn't be too badly placed in the AnonymousFeedbackPresenter. For now, I wanted as much as seemed logical to be moved out of helpers and since the original authors thought this merited its own place in the codebase, my knee-jerk response was a new object.
The 'etc' being the date filter-related instance variables used in the view and helper. It'd be good to rethink those filter variables soon, but for now, let's at least ensure we only bother initialising them for the correct response type.
Before too late and we're doing even more of the same