| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
| |
Just expecting the parsed file to include the expected one would mean
success in the case where nothing has been folded. Tighten up the
expectation, and add quoting placeholders to expected files that didn't
have them.
|
|
|
|
| |
Set to 'waiting_response' on creation, to match the displayed state.
|
|
|
|
|
|
|
|
|
|
| |
The data loaded with load_file_fixture is generally used
in the tests as if it were binary data received from the
MTA, so just load it as binary data - in Ruby 1.9 this means
that it will end up with the encoding ASCII-8BIT.
The same is the case when reading data from a fixture file
in receive_incoming_mail.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
just be loaded as binary.
|
|
|
|
| |
error, so that notification emails don't get sent.
|
|
|
|
| |
beginning and end of the whole string that we want to strip entirely, not at the beginning and end of each line (interpretation of ^ and $ is subject to default multiline behaviour of the regexp interpreter)
|
| |
|
| |
|
|
|
|
| |
Update the other API tests to take account of the changed error behaviour.
|
|
|
|
|
|
|
|
|
|
| |
The API was returning Rails (HTML) errors for certain error
conditions, which is inconvenient because it makes it difficult
for the client to extract the error message.
This patch changes add_correspondence to return JSON errors
(still with suitable HTTP status codes) for two common exceptional
conditions, and adds tests.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
|
|
|
| |
Not yet implemented, so the test fails.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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!
|