| Commit message (Collapse) | Author | Age | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Store the search parameters in the flash when a search is made via the
select_authority_path page. Stores the parameters for both POST and
AJAX typeahead searches.
The presence of stored search params renders the link on the
PublicBodyController#show template.
“keep”s the search params in PublicBodyController#show so that if the
user clicks the browser’s back button the “Back to search results” link
can still be rendered on the next search result they click.
“keep”s all flash keys in ServicesController#other_country_message
as it’s called through AJAX and ends up sweeping the flash. [1]
[1] More details about this:
http://mikenaberezny.com/2007/09/08/keep-the-flash-and-test-it-too/
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Dropped the law_used_full interpolation:
So I think there are two significant bits of context here. One is that the
law_used_full attribute is derived from law_used, which in turn is set on
InfoRequest initialisation based on the tags applied to the public body. So
different requests in a batch could have different values for law_used_full
- some of them might be to bodies that only accept environmental
information requests. So using the value from the batch template is not
really a good proxy for the whole collection.
The second is that, in any case, the distinction between the two types of
request is a UK-specific feature which should be moved to the UK theme
(#2085).
Given these two factors, I think the cleanest thing might be to drop
law_used_full from this descriptive text, and just have it say "Your
requests will be sent shortly", without specifying what law will be used.
– Louise Crow (@crowbot)
|
|/ |
|
|\ |
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Handle attempts to edit or destroy global or public body censor rules
with a notice and a redirect.
Closes #2009
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
So data changing actions require a POST and can be protected against
CSRF.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Move specs that involve receiving email and then viewing the interface
to be integration specs, which is what they really are.
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Seems more logical to make this one method that figures out what to do
based on file type. Plus, incoming message does so many things, it
seemed like having these related methods be separate would make them
easier to read and understand. Also, email, mobile and login
substitution texts weren't being translated. Finally, I think passing
the censor rules and masks as arguments is a first step in some more
decoupling of models.
|
| |/ /
|/| |
| | |
| | |
| | |
| | | |
Problem described in http://seclists.org/fulldisclosure/2013/Sep/145
Pattern taken from https://www.coffeepowered.net/2013/09/26/rails-session-cookies/
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | | |
Include URL and error in notification and log.
|
|\ \ \
| |_|/
|/| | |
|
| | |
| | |
| | |
| | | |
Use the per_page parameter to limit the results returned
|
| | |
| | |
| | |
| | |
| | | |
Action now supports the `request_from` param as per the Xapian filtering
system to filter search typeaheads by public body
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Easier to check against the assigned variable, but the spec still fails
because an internal error is raised if the rule is not associated with
a User or InfoRequest
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Direct the (re-rendered) form at the correct route for the association
(or use the generic route if the rule is being created for some other
reason)
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Build the CensorRule against the object that is found by an additional
parameter (either :info_request_id or :user_id)
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Direct the form at the correct route for the association (or use the
generic route if the rule is being created for some other reason)
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Build the CensorRule against the object that is found by an additional
parameter (either :info_request_id or :user_id)
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Note that these specs describe what the system does – not what it
_should_ do!
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Note that these specs describe what the system does – not what it
_should_ do!
|