| Commit message (Collapse) | Author | Age | Lines |
|
|
|
| |
The UI provides a list of comment_ids and a newstate="visible" or "hide"
|
|\
| |
| |
| | |
ssh://git.mysociety.org/data/git/public/alaveteli into rails-3-develop
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Extract checking whether a user is banned from making Comments on an
InfoRequest to a filter in CommentController.
Removes responsibility from the #new method.
Adds a missing spec.
|
| |
| |
| |
| |
| |
| |
| | |
Extract checking whether comments are allowed on an InfoRequest to a
filter in CommentController.
Removes responsibility from the #new method.
|
| |
| |
| |
| |
| | |
Use a before_filter to make @track_thing available to all filters
called on the same action and remove responsibility from the #new method
|
| |
| |
| |
| |
| | |
Use a before_filter to make @info_request available to all filters
called on the same action
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes https://github.com/mysociety/alaveteli/issues/662
If /annotate/request/:url_title is accessed when comments are disabled
an exception is incorrectly thrown.
Conditionals should be used for control flow, so now the action
redirects to the info_request path and displays a notice.
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| | |
We only really want to redirect people to live sites, so pre-launch
sites don't belong in WorldFOIWebsites. Handle the case where the
current locale isn't there. Closes #1345.
|
|/
|
|
|
|
| |
Calling simple_date threw an exception as it uses a helper internally.
Only LinkToHelper is included in to the controller, so the underlying
helper was not available.
|
|\
| |
| |
| |
| |
| | |
Conflicts:
config/general.yml-example
spec/factories.rb
|
| |
| |
| |
| |
| | |
Otherwise they get marked as fuzzy in .po files and lose their existing
translations.
|
| | |
|
| |
| |
| |
| | |
This is the most rudimentary possible way to give them access to the batch request urls, pending #1239
|
| |
| |
| |
| | |
We're going to want to actually create and send the requests later.
|
| | |
|
| |
| |
| |
| | |
Add or remove all buttons, ajax search as you type.
|
| |
| |
| |
| |
| | |
Seems like you have to specify a limit with xapian. We'll probably want
to document the limit somewhere on this page.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
They're not finding by the existing object, they're finding an existing
object.
|
| |
| |
| |
| |
| | |
Create the batch and associate new requests with it, send the outgoing
messages, and redirect to a page for the new batch.
|
| |
| |
| |
| |
| |
| | |
This duplicates what's done in the new action, but I can't currently
think of a way of sharing functionality that doesn't seem overly complex
and/or risky.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
It doesn't make logical sense that they would. However I am preserving
the ability to make batch requests as a separate thing from not having a
daily limit - I think batch sending requires a (perhaps marginally)
bigger level of trust.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Add validation, preview as in single request creation. Add comments
noting further work to be done in this action.
|
| |
| |
| |
| | |
Reuse it for the batch request page.
|
| |
| |
| |
| |
| |
| | |
Give it basic access control, and add some conditionals to the 'new'
template around bits that use @info_request.public_body so that they
render something different if @batch is assigned.
|
| |
| |
| |
| | |
Should retain a list of selected public bodies across searches.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Make it updatable via the user admin page.
|
|\ \ |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
doc/CHANGES.md
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
For cases where we don't want to make the change suggested. There
doesn't seem to be any obvious default text to use in the response to
the person who requested the change.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Also add editable text for an email to be sent to the person requesting
the change.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously it accepted a user, but for this usage we won't necessarily
have one.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Refactor a bit so it's easier to read.
|
| | | | |
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Make specs a bit more focused, remove view specs - they're not relevant to the new code in their current form and don't seem to merit updating.
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is involved with the construction of meaningful xapian queries with
respect to InfoRequestEvents. This commit also removes the
get_tags_from_params method, which presumably was targeted at
PublicBodies, but doesn't seem to actually be used anywhere.
XapianQueries is used to extend InfoRequestEvent in order to prevent
InfoRequestEvent becoming too unwieldy and to preserve the association
between these methods.
|
|\ \ \ \
| | |/ /
| |/| | |
|
| |\ \ \
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
Gemfile.lock
app/views/layouts/default.html.erb
config/application.rb
public/admin/stylesheets/admin.css
|