make *all* the forms in topactions float, see also #12796
topactions css lives in layout.css
we don't use ie7.js any more
TransactionBatch scrips are triggered twice

As a result of 2338cd19ed7a7f4c1e94f639ab2789d6586d01f3
we now clone the TicketObj and end up with two tickets being DESTROYed
and firing TransactionBatch.  If your condition is clever, you may not
have noticed (this is why Approvals weren't affected)

We probably need to fix this clone to skip _TransactionBatch, although
we aren't sure why we're cloning rather than a simple second load
anyway.

We also need tests for mail notifications from TransactionBatch

It would also be nice if changes to a ticket on Modify.html that were
done by a TransactionBatch scrip were displayed in the UI without
reloading the Basics page. This behavior was changed in
b5aedb8db1cfcd46162785587002ecf8c27b1335
We were running afoul DBIx::SearchBuilder::Record::Cachable

Flush the cache so that the Load pulls from the DB
Add a test that confirms that the CurrentUser isn't changed

This avoids the bug which 2338cd19ed7a7f4c1e94f639ab2789d6586d01f3
was fixing when it introduced the new "run twice" bug.
Stop TransactionBatch scrips from running twice.

Also prevent the privilege leak originally fixed in
2338cd19ed7a7f4c1e94f639ab2789d6586d01f3.

Unfortunately, cloning the ticket passed in to ApplyTransactionBatch
into $scrips->{TicketObj} means that we run TransactionBatch Scrips once
for the ticket that called ApplyTransactionBatch and once for
$self->{TicketObj}.

Trying to solve this with a Load that makes $self->{TicketObj}
completely separate from $args{TicketObj} means that $self->{TicketObj}
doesn't get the _TransactionBatch cache and when we get into
RT::Scrip->IsApplicable we won't have the Transactions handy to check
our Condition against.

Copying the _TransactionBatch cache into $self->{TicketObj} and deleting
it from $args{TicketObj} results in TransactionBatch scrips running
twice again because $self->{TicketObj} will be DESTROYed, triggering
ApplyTransactionBatch.

The only non-bandaid and smallish solution to this is having a flag for
'run transaction batch' which is separate from the cache of Transactions
which are batched.

The correct long term solution is most likely a separate table to track
which transactions are batched together.
Push this logic down into Prepare and Commit

Right now, Scrips->Prepare/Commit or only ever called
from Apply and from Transaction->Create.

If anyone ever changed Transaction->Create from passing
Ticket to passing TicketObj into Prepare, we would suddenly
start returning tickets from Ticket->Create with a current user of
RT_System.

This would be really bad, so we'll complicate this fix for
TransactionBatch scrips leaking privileges and running twice by pushing
our save/restore of CurrentUser bandaid farther down into Scrips.
Confirm that our Priority is 0

Suggested by Alex in case we ever change the default Priority
which would throw off my calculations.
Ignore the local directory which contains additional, temporarily non-public tests
Pull back docs/security.pod from 4.0-trunk
Add a note about the timeline on public announcements, tests, etc
Avoid shell interpolation when calling sendmailpipe

Use IPC::Open2 rather than three-arg open with "|-", to prevent shell
interpolation.  This allows not only fine control of the parameters to
the sendmail command, but also allows the STDOUT content to be dropped,
as was previously handled using a shell output redirect.  For backwards
compatability, use Text::ParseWords to split the configuration
parameters which are strings, rather than argument lists.

This prevents a vulnerability where specially-crafted emails could allow
code execution if VERP was enabled.

This resolves CVE-2011-2082.
Merge branch '3.8/ie7js-cleanup' into 3.8-trunk
Merge branch '3.8/topactions-form-css-fix' into 3.8-trunk
Merge branch '3.8/transaction-batch-twice' into 3.8-trunk
Prevent storing the old or new hashed password in the transaction table
Clean out sensitive user transactions
Add a consistent CurrentUserCanSee right
Enable ACL checks for non-Ticket transactions

Use CurrentUserCanSee on relevant object to prevent access to
Transactions that the user shouldn't be able to see.

This partially resolves CVE-2011-2084.