Spike adding a enquiry on behalf of another

[BenJam]

17 could be tricky, let's try something...

[stevenday]

Thoughts about making an initial request appear overdue:

The simplest hacky way to do this is to edit the last_sent_at field of the latest outgoing message (presumably when we create the request this will be the only outgoing message). This can be got at with something like:

request.last_event_forming_initial_request.outgoing_message

And a robust way of making it overdue is to set it to:

Time.now - (AlaveteliConfiguration.reply_late_after_days + 1).days

The catch here is that both the request event and the message itself have other datetime fields which will bely the fact that we've faked this. I'm still investigating whether this is good (we can see which ones we've doctored) or whether this will cause something else that makes the (logical) assumption that, e.g. last_sent_at >= created_at.

Luckily, request mails in Alaveteli are sent synchronously with the form submission, so we should have access to the message after it's been sent (which would normally set last_sent_at to Time.now).

If we decide we want to fake everything, there's quite a few other dates we'd need to doctor:

• the request created and updated
• the request event created and updated
• the message created and updated

[garethrees]

Luckily, request mails in Alaveteli are sent synchronously with the form submission

As an FYI, this is unlikely to always be the case.

[stevenday]

Aha, thanks @garethrees, our next step after looking at some of this stuff was going to be to ask you and @crowbot for your thoughts, but you're too quick!

If email sending switched to delayed_job or similar, I guess this would then require either a hack to that job/adding a new job to do something different after sending, or running another job entirely to do our date fiddling later on. Neither of which is ideal. I think this is an obvious -1 for the idea of fiddling with dates.

On 20 August 2014 14:08, Gareth Rees notifications@github.com wrote:

Luckily, request mails in Alaveteli are sent synchronously with the form submission

As an FYI, this is unlikely https://groups.google.com/forum/#!topic/alaveteli-dev/jL-7pChXd90 to always be the case https://github.com/mysociety/alaveteli/issues/1240.

— Reply to this email directly or view it on GitHub https://github.com/mysociety/panama-theme/issues/74#issuecomment-52774904 .

[lizconlan]

Meanwhile, I've been failing to find a good way of adding a request on behalf of another user in the first place....

For our use case, requests added in this way will be treated as having been escalated to ANTAI for them to take the case forward so they will be the owners of the request, all the requester emails need to go to them but it will be on behalf of the user who raised the original request and whose details, by law, need to be part of the request documentation.

The intention is that this functionality should only be available to superusers (who would most likely access it through the admin interface) and we'd be looking to disable/enable it at a site level via a config setting.

Having constructed a test form to accept the simplest variation of the user details alongside the request data, I spent some time trying to pass a fake user object though as far as the Mailer so that the template could be hacked to include the user details from the form fields rather than the details of the admin user making the request. I've now stopped doing that having a) spotted the resend method and b) read the conversation above about using asynchronous email sending.

So if we still want to build this, it feels like we could take one of two approaches:

1. we continue to assign the request to the admin user and create a new table to store our "fake" users in (not for login purposes - will not have email or password information); this fake user will probably be associated with the InfoRequest model as the sanest way of accessing it
2. we create actual user accounts for the request that are controlled by the admin user and make sure that the emails gets routed to ANTAI (given that we shouldn't be storing duplicate email addresses - tricky)

Although it feels like a pretty Panama-specific feature, it also feels as though it may be adding too much complexity for it to be part of a theme so it might be better as an alaveteli core feature... Hmmm

[crowbot]

Just noting a couple of thoughts in case this issue revives: For dates, my initial feeling is to fake everything. We're trusting ANTAI to add these correctly, and so want them to appear and act like normal requests in every way. For user accounts, I wonder if there's mileage in creating real accounts with names like "ANTAI (on behalf of Joe Bloggs)" and email addresses that use '+' - eg. 'antaiproxy+joebloggs@antai.org'. That gets over uniqueness, but they could all go into one account on the ANTAI end, or be processed according to the last part of the local_part, if they want.

[crowbot]

Or even 'antaiproxy+joeblogs=example.org@antai.org' - then you just need a simple pipe on the ANTAI end to forward correspondence to the user's email account

[crowbot]

VERP is vaguely analogous.