| Commit message (Collapse) | Author | Age | Lines |
... | |
|\ \ |
|
| | |
| | |
| | |
| | | |
Closes #554.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Is there actually any point in tests of this sort? It is not testing
that anything works as intended, only that a particular SQL string is
passed to the database -- and surely the only way that string could
have been discovered for test purposes was essentially to copy it
from the code under test.
It seems to me that the only real function of a test of this sort
is to make it more difficult to modify the code under test.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also make the InfoRequest#is_old_unclassified? method a little
more conservative, by returning false only is the is_external?
method returns true. This makes it subtly inconsistent with
InfoRequest.find_old_unclassified, but it is better I think to
be subtly inconsistent than to risk breaking things that used
to work.
|
|/ /
| |
| |
| |
| |
| | |
no record is found using url_title.
Closes #553.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
app/controllers/admin_request_controller.rb
config/httpd.conf
spec/models/info_request_spec.rb
|
| | |
| | |
| | |
| | | |
visible to everyone, so can be served up from a file cache without authentication.
|
| | | |
|
| | |
| | |
| | |
| | | |
cache the associated objects for an info request in the file cache which will be served up without authentication.
|
| | |
| | |
| | |
| | | |
admin public authorities page
|
| |/
|/| |
|
|\ \ |
|
| |/
| |
| |
| |
| | |
Add the user_name and is_external? properties to the InfoRequest
mock objects used for view testing, where necessary.
|
| |
| |
| |
| | |
problem testing template results
|
|/
|
|
| |
CensorRules that aren't attached to a User or Request or Public Body (but don't expose this in the admin UI). Fixes #33
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need not only new requests, but new outgoing correspondence
of any sort.
The idea is that this feed will contain any event that would have
triggered an email to be sent to the public body, so can be used
as an alternative, equivalent way to stay up-to-date with happenings
on WDTK (or the Alaveteli installation of choice).
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Gemfile.lock
script/handle-mail-replies
script/handle-mail-replies.rb
spec/controllers/request_controller_spec.rb
|
| |
| |
| |
| | |
Otherwise we issue PURGEs every time, for example, we send out email alerts.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
files. Closes #428"
This reverts commit 506af7a640f63b17000ccfc5e1344bbc3039c913.
See issue #428 for a discussion
|
| |
| |
| |
| |
| |
| | |
contains an underscore.
Includes a bonus test to ensure that locales with unknown territories fall back to known languages.
|
| |
| |
| |
| | |
it less brittle.
|
| |
| |
| |
| | |
(exposed by the bug fixed in 7c846594 that was introduced in 775e122c)
|
| |
| |
| |
| | |
one for testing!)
|
| | |
|
| | |
|
| |
| |
| |
| | |
requested the attention, not the user who made the original request.
|
| | |
|
| |
| |
| |
| |
| | |
Replace another constant with a computed value, so we can accommodate
new test data without spuriously failing.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Remove another dependency of a test on the aggregate set of test
data, part of a long-term programme to make it easier to add test data
(and required here because recently-added test data was causing these
tests to fail!)
|
| | |
|
| |
| |
| |
| |
| | |
Since users must now be logged-in to report requests, the tests
need to reflect this.
|
| |
| |
| |
| |
| | |
The wording that was changed by e3cfe550fe835c68b25d693abd40aedd954913b3
turns out to be relied on by one of the tests.
|
| | |
|
| |
| |
| |
| | |
Not yet implemented, so the test fails.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
I’m sure created_at should not have been there twice. Presumably
the second one was supposed to be updated_at.
|
| | |
|
| |
| |
| |
| |
| |
| | |
The API must not allow people to update requests that they shouldn’t,
i.e. only requests that were created by the same public body, using
the API, can be added to using the API.
|
| |
| |
| |
| | |
You can add a followup to a request using the API.
|
| | |
|
| |
| |
| |
| |
| |
| | |
"when using the API",
it "should create a new request from a POST",
AND IT DOES!
|
| |
| |
| |
| | |
(corrected typo, added missing fixture data, etc)
|
|/
|
|
| |
This is not yet implemented. Test first!
|
|
|
|
|
|
|
| |
It’s weird that there’s so much code here that implicitly
assumes File.dirname(__FILE__) is an absolute path, because
really in general it very much is not! This assumption was
invalidated by the recent bundler-awareness changes.
|