This reverts commit d970cc40f8.
point_of_sale does not depends on share. This domain can therefore not be applied.
It works for new databases as the module share is auto installed.
But as soon as the module share is uninstalled, this domain will lead to a crash
There is no way to "solve" this issue, other than by a view customization
if the issue is critical for the customer.
I did not pay enough attention when I reviewed the PR.
In order to hide fields method_number and method_period to hide them according to the asset, fields_view_get method was overriden.
An issue was present: if a search view on model account.asset.asset was added, and did not contain these method_* fields, this overriden fields_view_get was applied, and tried to hide method_* fields, while they were not present in the search view, which leaded to a crash.
I could have solved this the easy way, to not apply the invisbility if the fields were not present in the view, or if the view was something else than form, but I prefered to solve this the cleanest way.
When converting a lead to an opportunity, and choosing the option "link to an existing customer", the resulting opp wasn't actually linked to the ccustomer.
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
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
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.
Christophe Simonis
Denis Ledoux
Goffin Simon
Sandy Carter
Ravi Gohil
Martin Trigaux
Akash Balar
Wolfgang Taferner
Olivier Dony
fka-odoo
Yannick Vaucher
Jérome Maes
David Monjoie
Antony Lesuisse
Lionel Sausin (Numérigraphe)
jbeficent
Gaurav Panchal
Somesh Khare