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
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
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
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 91911159f5
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
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.
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
Revert "[FIX] ir_translation: remove control characters from translations"
This reverts commit 6d4e1cc73e.
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.
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)
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
Partners totals were not correct if the partner paid partially an invoice in advance
For an invoice of 20.000 in the future, with a payment made in advance of 5000
The column not due must contains 20.000, as the amount is not yet due
One of the column 1-30, 30-60, ... (accordingly on when the payment was made). must contains -5000
The total should be 15.000
When creating a return picking, the default invoice state is 'To Be Invoiced' if
returned picking was invoiced. However if the invoice of the picking has not
been generated yet (state '2binvoiced'), the return should also be invoiced.
Fixes#4002
Google api geolocation service returns a precise latitude and longitude, greater or equal than 5 digits
The precision is important as storing 2 digits instead of 5 can lead to an inaccuracy of allmost half a mile.
Catch only the error related to the access of the linked record.
Previous was hidding error to access the ir.config_parameter and eventual other
errors from the orm.
Uses SUPERUSER_ID to access instance URL (e.g. portal has no access to it).
Fixes#4234#4234
This is related to rev. db98434e85
rev. abe5c803a0 forgot some partial reconciliations when the date domain was other than BETWEEN (for instance, <= stop date or >= start date, alone, not between)
Besides, the rev. abe5c803a0 did not care about account move being posted or not.
rev. db98434e85 took several times the same partially reconciled moves lines
Another fix should probably be build for purchase price, but it isn't that easy, we need to know the partner to which the product has been purchased, as taxes are partner/country dependent.
Besides, included taxes in purchase prices happen less often.
When composing an email based on an email template, some parts of the template
(the result of name_get on fields) were not translated.
This was due to missing language in context when rendering the template.
Fixes#3708, opw 617309
Aaron Bohy
Ravi Gohil
Sandy Carter
Martin Trigaux
Denis Ledoux
Akash Balar
Xavier Morel
xmo-odoo
Sandy
Wolfgang Taferner
Olivier Dony
fka-odoo
Yannick Vaucher
Jérome Maes
Maxime Chambreuil
David Monjoie
Fabien Pinckaers
Antony Lesuisse
Cedric Le Brouster
Simon Lejeune
Lionel Sausin (Numérigraphe)
jbeficent
Gaurav Panchal
Somesh Khare
Christophe Combelles
senthilnathang
Martin Trigaux
Ravi Gohil