[FIX]:Add noupdate in project data
[IMP] when selecting filter 'To Pay', also display the expense which is in Waiting Payment' state
[FIX] Restore the appropriate accounts on tax ACH-19.6
[FIX] */report: font names are case sensitive
[FIX] account,account_followup,l10n_{ch,es,pt,us,ve}: correct or remove wrong fields in <record> creation
[FIX] survey/report: correct style name
[FIX] sale/edi: do not import non-existing field date_planned
[FIX] point_of_sale: POS delivery orders were incorrectly using the internal picking sequence
[FIX] point_of_sale: POS delivery orders were incorrectly using the internal picking sequence
[FIX] portal: mail access right test is not totally accurate

The access right test expect an exception
to be raised when accessing any of the
followers, but this is not 100% correct,
as the test user (Chell) should be able to
read her own record.
This worked by chance because the ORM
prefetching was triggering an access error
whenever any follower was accessed, but
this was a bug, now fixed in server at
rev-id odo@openerp.com-20131119153700-5sbo2cl13vvqsgz5
revno 5136
[FIX] portal: mail access right test is not totally accurate

The access right test expect an exception
to be raised when accessing any of the
followers, but this is not 100% correct,
as the test user (Chell) should be able to
read her own record.
This worked by chance because the ORM
prefetching was triggering an access error
whenever any follower was accessed, but
this was a bug, now fixed in server at
rev-id odo@openerp.com-20131119153700-5sbo2cl13vvqsgz5
revno 5136
Launchpad automatic translations update.
Launchpad automatic translations update.
Launchpad automatic translations update.
[FIX] portal: mail access right test is not totally accurate

The access right test expect an exception
to be raised when accessing any of the
followers, but this is not 100% correct,
as the test user (Chell) should be able to
read her own record.
This worked by chance because the ORM
prefetching was triggering an access error
whenever any follower was accessed, but
this was a bug, now fixed in server at
rev-id odo@openerp.com-20131119153700-5sbo2cl13vvqsgz5
revno 5136
[FIX] point_of_sale: POS delivery orders were incorrectly using the internal picking sequence
[FIX] stock: chained location type `Customers` was not working at all for pickings without partner

This can create inconsistencies in the warehouse inventory
in case delivery orders are not customer-specific, e.g.
when using the POS.
When there is no destination customer we can still use
the default Customers locations.
[FIX] stock: chained location type `Customers` was not working at all for pickings without partner

This can create inconsistencies in the warehouse inventory
in case delivery orders are not customer-specific, e.g.
when using the POS.
When there is no destination customer we can still use
the default Customers locations.
[FIX] stock: chained location type `Customers` was not working at all for pickings without partner

This can create inconsistencies in the warehouse inventory
in case delivery orders are not customer-specific, e.g.
when using the POS.
When there is no destination customer we can still use
the default Customers locations.
[FIX] point_of_sale: `update` button in POS order form was calling a non-existing method

This dummy button is only meant to save the
order and refresh the view, which is easily
accomplished by sending an non-existing
workflow signal. Setting the button type
to the default `workflow` type (or simply
removing the wrong type) fixes the problem.