As entering a wrong value in the grouping field of res.lang,
for instance '[,]', leads to an unavailability of the web interface,
We add a constraint to prevent entering wrong values.

The first term of a po file is a comment for translator e.g.:
msgid ""
msgstr ""
"Project-Id-Version: openobject-addons\n"
...

This comment is ignored if there is no source and it is the first term of the po
file. The first flage was disabled too late and if the following terms also
started with an empty source (for too long terms), they were skipped as well.

Disable the flag as soon as the condition is evaluated to make sure no
additional terms are ignored. opw 619786

Remove installation of v8 requirements in package.dfdebian as this
is unnecessary for v7. This fixes a bug occuring during the installation
of openerp (precisely when installing reportlab dependencies), because
reportlab now requires a more recent version of pillow than 2.5.1.
Also use pip instead of /usr/local/bin/pip in test_tgz (package.py)
as pip script isn't installed there anymore.

Upstream traceability on produced goods (serial number on finished product) was
broken due to wrong values in cache for production.move_lines2 after production.
Refresh the value of production after each action_consume to make such the state
of the cache is correct. opw 609450

Similar fix for manufactruing order not going in done state in some specific
configrations (e.g. some components being phantom BOM).
Again due to wrong cache state after consumption. opw 610515
Fixes #1296

This means group category names can be translated in the
default/installation database language.

Closes #3921

The tracking reference and other delivery references are not relevant to
duplicated pickings. Overwrite copy to remove carrier_tracking_ref, volume and
number_of_packages.

Add fallback on stock.picking.in and out to use copy method of stock.picking.

For partial delivery, the duplicated picking is the delivered order and
the existing picking is the backorder of the delivery (why so much hate?).
This means we have to switch the delivery info between the backorder and
the delivered picking.
Combo opw 615593 and 618802

The method test_if_product, used in the workflow to test that the mrp production is for a product (!= service), used to call the method _action_compute_lines in order to compute the production lines and determine from them the production type.

The thing is, the method _action_compute_lines, despite the fact it returns the lines of the production, actually creates the lines. So, just to test if the production was of product type, the productin lines were created, in database.

This rev. introduces a _prepare_lines method, which returns the computed production lines, without actually creating them in database, so the test_if_product method can test if the production is of product type without creating the production lines.

Therefore, production lines are now computed and created during the action_compute method, instead of computing them when the production was tested to get the production type.

Computing the lines before the action_compute has as side effect to not set the scheduled date of the work orders in module mrp_operations, at MO confirmation (as, on confirmation, the action_compute method is called only for productions for which the lines are not yet computed, and mrp_operations overide action_compute to set the scheduled date)

opw-620189

As date_start and date_stop are date field and not datetime, should use
DEFAULT_SERVER_DATE_FORMAT for search. opw 619592

POS users should not be able to create nor modify payment methods (account.journal)
POS users should not be able to create nor modify point of sales (pos.config)

At first opened session, if no payment methods was set, this is possible that the pos user should temporary have accesses granted to mark a payment method as pos payment method. This is done by the openerp.SUPERUSER_ID added by this rev.

opw-625489

This rev. is associated with rev. 38aa984f

closes #4660

Extract dropping of connection from exp_drop (as in 8.0), call it from
relevant database-alteration functions (drop, rename, duplicate)

[FIX] Issue #4424

Use `tools.ustr` for error conversion to prevent `UnicodeDecodeError` when
converting errors which can be unicode in depending on data.

Example:
```python
from openerp.osv.orm import convert_pgerror_23505
from psycopg2 import IntegrityError

e = IntegrityError(
    'duplicate key value violates unique constraint '
    '"hr_job_name_company_uniq"\nDETAIL:  '
    'Key (name, company_id)=(Directrice comptabilit\xc3\xa9, 1) '
    'already exists.\n'
)

convert_pgerror_23505(None, [], None, e)

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 129: ordinal not in range(128)
```

This rev. reverts 91911159

The above rev. was a good idea, except that internal_set_value expects the raw value, while the records attributes can be tuples(for instance, many2one are tuple(id, name) or list of command(one2many, many2many).

set_value must be use here, as all fields (js) override set_value in order to handle their value repr (for instance, many2one fields handle the tuple (id,name).

Besides, avoiding the re-render provides a huge performance improvment, as rerendering fields can lead to xmlrpc calls (for instance, re-rendering a many2one field implies calling the name_get method)

opw-620111
opw-622108

Closes #3127

Fixes #4582

The previous matching rules were too fuzzy and allowed random
prefix-match or tail-match of other user's emails.
For example when looking up a partner matching 'foo@bar.com'
the system would sometimes find 'dom.foo@bar.com' instead,
or 'foo@bar.com.tw'.

Fixed by only allowing direct case-insensitive email match
of an addr-spec, or substring match of the addr-spec enclosed
in angle brackets, within a name-addr pair.
See also RFC5322, section 3.4

Also adapted related message_find_partner_from_emails() method
to factor out the partner email resolution mechanism to avoid
the same problem.

Adds corresponding regression test.

A _prepare method had to be introduced in the wizard for the lines invoicing method

If an employee in UTC + 1 (Europe/Brussels) entered an attendance from January 2 00:00 to Januay 2 23:59, the summary by day table displayed two different lines, for two different days:
 - 1 hour on January 1 from 23:00 to 23:59
 - 22:59 hours on January 2 from 00:00 to 22:59

 Which is obviously wrong, the employee, in its own time zone, worked on January 2 only.

When adding several lines in an editable list (adding 7 lines to an invoice for instance), then clicking on the first row direcly after having filled the last line, the value of the cell sometimes had the value of the last line. Just a display bug, but still.

Using internal_set_value avoid the re-rendering of the cell, and solve the above issue

opw-620111

It was intended to be replaced by log-handler at first but log-level is still
a very convenient way to manage the level of debug.

Revert "[FIX] ir_translation: remove control characters from translations"
This reverts commit 6d4e1cc7.

This was intended to clean malformed translations but it introduced the side
effect of removing all '\n' in translations.

Fixes #4092, opw 619175

For models using a datetime field as name (hr.attendance for instance), the user timezone wasn't applied in the display name.
Therefore, in the breadcrumb, the datetime was different than in the form if the user had another timezone than UTC.

The name of the product was stripped from the product label report
Fixes #3138 (only blank entries)

Backport of ead3f039
Fixes #4341

[FIX] mail : close #2250. If trying to send empty message in chatter, no other messages can be send wihtout refreshing page. Moving the flag_post allow sending a new message only when the previous one is sucessufully sent. If case of empty message, nothing will happen, and the chatter will not be blocked.

If the date format language was changed to invert month & day values (so, changed to the classic european format instead of the american format)
Then, when entering manually a datetime without the time (so just '01/02/2014' instead of '01/02/2014 00:00:00', the day and month were inverted (the datetime was set to 02/01/2014 instead of 01/02/2014) because the datetime entered did not exactly match the date + time pattern.

We therefore added a fallback case, to test to parse the value with the date pattern alone (without the time)

If the sales details only fetches the pos sales details of his own company, it should be the case for the pos payments and taxes as well.

use selected user and not admin to run yaml tests

Courtesy of Alejandro Santana

Closes: #1046, #1047

Closes #831 aka lp 1322191

[REF] Packaging: backport of a7ab5a41
[REF] Packaging: backport of a700a113
[REF] Packaging: backport of 9d0bd280
[REF] Packaging: backport of b0722d3e
[REF] Packaging: backport of 24b2c938
[REF] Packaging: backport of e874cdaf
[REF] Packaging: backport of 56b61da1
[REF] Packaging: backport of be96dd85
[REF] Packaging: backport of 50a4da99
[REF] Packaging: backport of 1c41f369
[REF] Packaging: backport of cc113317
[FIX] Packaging: backport of 13471630
[REF] Package: backport of 93845d68
[REF] Package: backport of 012bc01c
[FIX] Package: partial apply of d9e72a37
[REF] Package: backport of 67036fef
[REF] Package: backport of 73de0138
[REF] Package: backport of 30d987ed
[REF] Package: backport of 29132669
[REF] Package: backport of 7db12dc4
[REF] Package: backport of f668f9c6
[REF] Package: backport of 2cf4051a
[REF] Packaging: backport of 73592487
[REF] Packaging: backport of f2598ecd
[REF] Package: backport of fd21912c
[REF] Package: backport of 9a8cdf49
[REF] Package: backport of 2f4984b8
[REF] Package: backport of 6e9edeeb
[REF] Package: partial backport of d4624fa8
[REF] Package: backport of 9f13722f

The gantt view does not have enough data to properly display a project's length
based on only the planned hours.
It also makes it impossible to change the project's length using drag & drop.
It's safer to simply display the start and end dates recorded in the project
Fixes #2632

Fixes #4269