When url_for was looking for a route which match, it was only looking for GET route.
So routes which were restricted to be used only with a POST method, were never found.
The result was that urls in website for route post (form in most cases) was never prefixed with the lang.
So the request.lang was always the default lang from website...
If you was creating a sale order (in ecommerce), the lang used in sale order was wrong and the description not in the current lang.
Before 8.0, the field journal_entry_id did not exist.
For database coming from older release, like 7.0, this field is not filled in during the migration, because this is not possible.
Set the needaction to depend only on the journal_entry_id will have as effect to have every bank statement line entered when the database was under 7.0 to match the domain, while the needaction is made to display the number of records that need an action.
Besides, even in 8.0, this is possible that a line has not the journal_entry_id set, while not needing any actions (see 2bb38ca89d)
For bank statement line having an account_id, but no journal_entry_id, it is not possible to reconcile the line in the bank statement reconciliation tool, as a filter is applied to only reconcile lines having journal_entry_id AND account_id not set.
As written in the help message of the account_id field:
This technical field can be used at the statement line creation/import time in order to avoid the reconciliation process on it later on. The statement line will simply create a counterpart on this account
Not allowing the reconciling should not prevent to close the statement in such a case. The button "close" was displayed only when all lines had journal_entry_id set.
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
name_get of pos.category should use a browse instead of a read.
For a company having thousands of products and a few categories, using a browse
will greatly improve the load time as it is cached.
The constraint prevent sheets to overlap was broken because it relies on a check on the
user_id. The problem is that the latter uses an old-api function field
that is not recomputed yet at the time of the validation. The fix consists in
using a non-computed field instead.
This rev. is related to:
- 4fb9c8f0dc
- 6c78541978Closes#4217
opw-620175
Issue was the propagation of contextual values across actions, more
precisely conserving the selected fiscal year when selecting an account
from the chart of accounts tree view: the chart of accounts tree view is
generally opened for a specific fiscal year, and it seemed sensible that
opening an account would show only the journal items for the previously
selected fiscal years rather than all items ever.
PR #649 altered action.read by tentatively evaluating the action's
context, however this has the side-effect of providing evaluated
contexts when creating or editing actions via the UI, usually breaking
them in the process (as the context at this point is basically
nonsensical for the action's purpose).
This backs out the previous fix, and creates a fix restricted to the
tree view's JS (thereby removing the feature for window actions not
invoked from a tree view).
closes#4677, closes#4690
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
Once the bank statement reconcilation done, the back button should not come back to Home when it does not found the bank statement list in the breadcrumb history, but simply perform a history_back action, which will come back to the previous action, the statement form for instance.
opw-625397
Without this fix, the 'Total' line of the pivot view does not display any inventory value, because there is no __domain as we are not asking the inventory value for any specific product.
Only admin was able to create product.putaway records. Gives all access
to warehouse manager.
If a putaway strategy was present on a location, a warehouse user was not able
to transfer goods as he had no access to the rule lines (no read to
stock.fixed.putaway.strat). Give read access. opw 619774
When comment is created, emails are sent with subject: "Re: False" and footer: "About Forum False".
Now, when the post is a comment, we fallback to the name of the parent (the main forum post).
- admin is not follower anymore of all leads created through the
contact form. The famous no_subscribe key is added in the context
for that purpose.
- fixed medium and sales_team of the contact form leads. A bad
xml_id + bad use of get_object_reference + bad use of try/catch
prevented from having any of those. It now works correctly
even if the medium and/or sales team has been deleted.
Courtesy of Use Merge: Yannick Tivisse.
Reviewed by Use Merge: Thibault Delavallée.
I think this commit message is waaaay longer than the commit
itself, although I think I will never beat Olivier or
Martin. Those two are able to write 3 pages of commit messages
when doing a one-line fix. Well, this fix can be tricky
to understand but, hey, I am not writing stupid things just to
gain some characters. Not my style.
Have a good day.
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
fields received by the fields_get call sometimes have a digit
precision. This commit makes sure that it is used when
formatting the cells to be displayed.
When generating account.move.line from pos.order, orders with different analytic
account should not be groupped in generated lines (possible if inherit
_prepare_analytic_account).
Add the analytic_account_id in the key to avoid this grouping.
Fixes#4602
The validation of leaves was broken because it relies on a check on the
remaining days. The problem is that the latter uses an old-api function field
that is not recomputed yet at the time of the validation. The fix consists in
using a non-computed field instead.
Setting a constraint on an old api style computed field is broken in Odoo 8.0
The constraint is checked with the old value of the computed field, not the new one
So, it was possible to update an event with a start date greater than the stop date
And once done, it was impossible to correct the mistake
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
When invoicing from dropshipping picking, choose the correct partner.
Also, change the partner on the picking to be the partner of the purchase.
Change the picking report to include the destination partner or the warehouse address on the right.
[IMP] Only put partner_id on move from purchase when really necessary
[FIX] Default value of partner on stock move should be False
Before, all crm.lead of the partner were counted, whatever it was a lead or an opportunity, but the button opens the opportunity tree, which has a domain type = opportunity. So leads were not displayed, and the count was therefore misleading.
Besides, the button is called "Opportunities", and it was misleading to count leads for a button with such a name
Setting the margins of a paperformat to 0mm was ignored and fallbacked on wkhtml
default margins.
This change is considered as relatively safe as margin-* fields have a default
value and setting 0 is then an explicit choice.
Fixes#3367, opw 620130
This reverts commit 1fd13fbe2b.
For FIFO it was not needed as the cost is already set to the returned quant.
For standard price, this is wrong as the stock is reevaluated when the product
price is changed.
Revert edbd0df
Instead of removing the demo data (demo data is our friend), make the test more
specific, adding a date to match the rate of 1.5289 all year long.
Old demo data hardcoded the currency rate of USD to 1.5289 at the half
of the year, introducting new year red runbot.
Using assertAlmostEquals to avoid values like 32.730000000000004