The `tax_amount` of move lines is by default set to `0.0`.
Nevertheless, this default value is set by Odoo,
not by postgresql.
This is therefore likely that the `tax_amount` is set as
null instead of 0.0, in database.
Therefore, when getting this value directly with a SQL
request, this is possible that `null` will be returned.
Therefore, in this specific case, `res.get(record.id, 0.0`
could return `False`, if the sum of `tax_amount` is `null`,
and try to multiply a boolean with an integer is not possible:
`_rec_get(rec) * rec.sign`
opw-633903
Make sure the purchase order is marked as invoiced only when fully invoiced.
If the invoices are generated on delivery order (invoice_method picking), make
sure all products are delivered before setting it as invoiced.
opw 614256
The previous filters didn't take timezones into account, and
returned stringified naive datetime values in local browser
time. Those would then be interpreted by the server-side as
UTC date, and depending on the current timezone offset vs UTC,
yield partially incorrect results.
By returning directly a datetime.datetime object instead of
a stringified version (see previous commit 76881fb),
we can get the expected result regarless of the timezone.
Fixes#2972Closes#6229
opw-621282
This fix adds the toJSON() method to datetime.datetime,
so domain expressions can use datetime values directly,
without having to compute the stringified version
with convoluted strftime() and timezone calculations.
The datetime results are sent down to the JSON-RPC
level where the JSON.stringify() serialization will
convert them to UTC string, to be deserialized
properly as UTC datetime values on the server side.
Thanks to this we can use the browser's local midnight
timestamp in a filter expression, for example like this:
`datetime.datetime.combine(context_today(), datetime.time(0,0,0))`
and get the expected result regardless of the user/browser's
timezone.
related to issue #2972 and pull request #2914 and #6229
(Next commit will fix them)
opw-621282
Correctly creates menu and add implied groups.
Since the conversion from res.portal to res.group, we lost the field
parent_menu_id so a search is needed to find parent menu.
To add the access of existing users to the new groups, implied id rules are
needed. opw 612594
When opening the list of meetings from an opportunity, show only the meetings
linked to the current opportunity.
Use search_default_ to be able to remove the filter if not needed.
Remove context on meeting button as it's ignored in action_makeMeeting (and
there is no field attendee_id linked to a crm.lead anyway)
opw 614039
As event_obj._length doesn't return the number of days when the selection spans
multiple weeks, the test was wrong when the selection ended on the first day of
a subsequent week.
This fix was originaly written by rha-odoo at 95d344b, but I rewrote it a little.
I would have liked a cleaner way of finding how many days there were between the
two dates, but I couldn't find anything better, considering I didn't want to
create new objects just for that test.
Fixes opw 614703.
When doing a manual reconciliation, the current filter could restrict the
visibility of move lines and show empty results for some partners (e.g. filter
the lists on only one partner will show empty list of moves for other partners).
This is also the case for multicompany restrictions.
Integrate the current filter to the search to only get results for displayed
lines.
Fixes#3817, opw 618134
Fixes#5221, opw 632095
The name field contains the refund reason.
The reason is filled when you create the refund
from the refund wizard available when
pressing "Ask Refund" on a supplier invoice.
As this field wasn't visibile on the supplier
invoice form, this wasn't possible to change
the reason on draft supplier refunds after
having created them through the wizard, while
you could change your mind or having done a
silly mistake in the wizard, that you could
edit since the invoice is stil draft.
This was also not possible to set a reason
when creating the refunds without going through
by the wizard.
This was also not possible to change the reason
when you duplicated your supplier refunds.
opw-632756
closes#6301
Taxes can be applied on the repair fees.
The field was defined in the model, it was just missing
in the view.
In addition, the product_id_change worked already for the
taxes.
opw-632898
When creating a chained picking, the first move has no sequence, this is because
there is no sequence for stock.picking.internal.
Set the sequence before the chained move so that the sequences are in the right
order. opw 621261
Reasons:
- the currency conversion is done assuming that the cost price currency is the company currency
- we support only one price type per field. Defining several price types on the same field using
different price types is not supported.
Backport of 8.0 code, rev f61339b
Create a new journal item with an tax included, the automatically created tax
line had the amount computed as tax excluded.
Fixes#3731, opw 618305
The context wasn't defined in the below methods:
- action_production_end
- action_in_production
while it is defined in the base methods, in the mrp module.
This doesn't lead to any issue in standard
modules, but it prevents to correctly
override these methods within custom modules
when mrp_operations is installed.
opw-632425
When the margin is calculated, the purchase price is calculated using the currency of the price
type 'standard_price' instead of the currency of the company, since they can be different.
opw: 631884
The state 'Quotation Sent' was not visible on the sales analysis report (e.g.
group by Status). Add the missing state to the report to correctly disaply it.
opw 619748
Relax the constraint on BoM to allow to have two different lines with the same
product. As the error message says, the purpose of the constraint was to forbid
having the manufactured product as one of the components but had this side
effect.
Such scenario of the same product twice makes sense when using the date
attributes on the lines (e.g. changing quantities)
opw 621468
Previously, when updating subscribers of a mail.thread, the default_{key}
arguments could override a {key} in the values.
e.g: for an new opportunity, the salesperson was overrided by the default user_id
This fix gives the priority to the values over the default_ in context.
opw-631741
The report generated by this wizard considered all the partners without taking into account
the filters and target entries set.
To show the right partner the function _set_context
must consider the "self.query" which sets the period, the dates, the states, the accounts and
the journals of the sql query used to give the demanded partner.
opw:631649
The working time unit can either be hours or days. In case of days, should
replace the references to hours in the view to days. In case of days, use float
field instead of float_time.
Using the string 'Hours' as a way to determine the unit is too weak as:
1. it does not work in other language than english
2. if the unit is renamed (*cough* 1626eca *cough*), it will fail as well
Using the object with context to compare strings in the user language.
lp:1080191, opw 595397
When setting a task as done, the state is done and the progress written to 100%.
If this task is reopened, the progress was not resetted as the stage is changed
but not the state (still done).
Partially backport behaviour of 8.0 (8fbfc997) by using the fold attribute
instead of the state to reset the progress.
opw 597688
If a customer changed of company while having
account.move.line records in the former company he was in
It wasn't possible for someone else than the admin
to print the partner ledger report including this partner.
opw-631800
In the form view of a unit of measure,
if the unit of measure was of type
"Bigger than the reference unit"
The help in the tooltip of the ratio field was wrong
Besides, this help message was contradictory
with the formula written just below the field.
opw-631672
On an invoice, tax lines are generated in tax_line field. When modifying
manually the tax amount, the recomputed tax_amount field was incorrect in
multicurrency environment, leading to an entry with different tax amount and
debit value.
opw 611474
When showing a kanban, there is differences between dataset of types:
* DataSetStatic: self.view.dataset===self.dataset, their ids attributes are the entire ids list,
* DataSet and DataSetSearch: self.view.dataset.ids are the already in the view ids, self.dataset.ids are the last gotten ids.
Hence with DataSetStatic dataset, when self.view.dataset.ids.splice(0) is done
self.dataset.ids is also emptied. And in the read_slice function, the slice is
done on that (now empty) array.
This fix removes the splicing of this ids array (which doesn't change a thing
since the array is overwritten latter), a _.difference is used to remove
eventual duplicates since in the DataSetStatic case, the same array is being
concatenated to itself
opw-630654 opw-617090 opw-619563
On a line write in a account.move.line tree view, the on_write return all the
sibling move lines of the written move line. The lines are then displayed even
if they do not match the current search domain.
This fix adds the context on the given on_write callback request, and in
on_create_write use a on_write_domain in this context to filter the returned ids.
fixes#3161, closes#5727
opw-630093
When auto subscribing to a message
(For instance, change the ```user_id``` field on a record,
like an invoice)
The new user is notified of the last message of the thread.
He must be notified of the parent message as well,
to have access to the first message of the thread,
to prevent access rights issues to the thread.
This mechanism is applied in the _notify method
of model ```mail.message``` as well, for the same reasons.
opw-630286
The timezone of hr_analytic_sheet should be the timezone
of the employee as well, so sheet analytic lines and attendances
lines are grouped within the same timezone, the timezone
of the employees, so the time difference between the analytic
lines and the attendances lines can be properly computed.
Fixes#5809Fixes#5379
Related to rev. 3bf1615ad4
The BBA communication is now only checked when provided as input
(created or modified).
Avoids useless check for uniqueness when it's not modified, and
prevent errors when several invoices are modified in batch.
opw: 629649
Closes#5700
In the accounting settings, we prevent having gain and loss accounts that are linked to a
different company than the one selected for the chart of account.
opw: 630494
The sequence for new items in some models is simply set to a constant 10.
Hence if 3 items had after reordering sequences 10, 11 and 12. If a new item is
added, it would get after saving at the second position.
This fix set the sequence of a new item to the maximum+1 or minimum-1 sequence
of current items sequences (max if tree has editable="bottom", min if tree has
editable="top").
opw-627830
The result of the residual amount of an asset is : asset.purchase_value - amount - asset.salvage_value
where purchase_value and asset.salvage_value are in the currency of the asset. Amount is the difference
between debit and credit of an account move line expressed in the currency of the company.
This is why the amount must be convert in the currency of the asset.
It is possible, if the user created a new country by himself, to have a country without a code, we then need to check that.
Fixes opw 629891, where the customer wrote "Belgie" trying to find "België", didn't find it and created a new "Belgie" country without code.
The test for account followup use UTC time, but the default `date_maturity`
and `date_due` of an account invoice come from fields.Date.context_today`.
One failing test for project_timesheet also used `today` instead of
`context_today`.
So depending on the test user timezone, an error of one day (if UTC time
and user time are on different day) occured which failed the tests.
For example:
* user has GMT+1 timezone, test fails 0:00am–1:00am (11:00pm-0:00am in UTC)
* user has GMT+3 timezone, test fails 0:00am–3:00am (9:00pm-0:00am in UTC)
This fix removes UTC use in the tests.
After discussing with jco, we decided to keep it simple and have a coherent behavior between different versions, we then changed the behavior from the one of jbefficient PR at 92adf673f7.
Allows exporting fields whose string is a non-ascii *byte*string (rather than unicode).
backport of 7286f4e424 fixing #773 to branch 7.0 by request of @flotho
Amount in payment order is not correct if the account move
line has already been paid by another way. The right amount is
in the residual field related with move_id to the account invoice.
opw:628903, 628428
Text fields, or char fields having widget="text",
were not sized correctly when the field was not
visible by default, ans was set visible thanks
to attrs and other fields values.
opw-629394
Before this revision, the overdue payments report contained all payments due,
including the ones in the future, that are not actually due yet.
opw-628874
When setting a partner on the lead,
the on_change_partner method retrieves
the various partner field values.
title & function fields were omitted, without obvious reasons
opw-629374
Closes#5388
It wasn't possible to create a new dashboard,
as a user other than SUPERUSER_ID,
using the "Create board" menu specifically
Reporting > Configuration > Create Board
(Technical Features & Administration > Settings groups required)
Because it creates a new menu for this dashboard,
which lead to the automatic creation of an "ir.values" record
which is prevented for other users than SUPERUSER_ID
opw-629367
In a timesheet, when a sign in is added, and a sign out
is not following, the current time is took as sign out value.
Rev. dbb2a669f4 corrected an issue
regarding the worked hours summary not taking into account
the employee timezone.
This timezone has to be applied on the current_time also.
e.g: For an employee being in timezone UTC + 1
If the current_time is presently 12:00 (UTC+1)
If the employee set his sign in to 10:00
and do not entered a sign out
The hours summary table displayed 1:00 of worked hours,
based on computation (11:00 - 10:00)
11:00 being 12:00 but in timezone UTC
Besides, another issue was present when entering
a sign in at midnight exactly without a sign out:
If the employee set his sign in to 00:00:00
and do not set a sign out, worked hours displayed 0 worked hours
whatever the current time.
Fixes#5379Closes#5378Closes#5503
When accessing an existing record in form mode directly (enter the url or refresh a page), the daterecord has not been initialized yet. This means that the value of actual_mode will be set to 'edit' before loading the current record (method _actualize_mode() called from do_show()).
This was problematic for one2many fields that we loaded in edit mode, showing add/delete icons/buttons in readonly views. (opw 607910)
Backport of 7ec7f1ba40 for 7.0 and saas<6. (opw 627885)
When the number of records n and the limit l were such that n%l = 0
(e.g. 16 records total, 8 displayed per page), clicking on the
previous button on the first page, or on the next button on the
last page produced a bug because the total number of pages
computed for this edge case was incorrect.
When selecting a product in a sale.order, the asked quantity is verified against
the available quantity.
If the user changes the UoM or the onchange from super call changes it,
the context should be updated accordingly.
Fixes#2559
The precision 'Product Unit of Measure' was defined after the declaration of kg.
Since fc85a7ee, the precision of kg is set in data to 0.001.
As the Product Unit of Measure was not defined yet, the rounding was stripped to
(16,2) precision, so getting a rounding of 0.0 for the kg unit of measure.
[FIX] product: the declaration of decimal precision was done after
the declaration of uom precision, preventing uom precision from going above
the default decimal precision. + made the Kg unit precise up to grams by default.
27a48f8026 introduced the use of self.dataset
It appears it is not always defined.
Few lines above, self.getParent().dataset is used,
and looks to be always defined.
We therefore now use this dataset in order to get the context,
to correctly pass the current session language.
Closes#5416
This rev. reverts partially 1d76586a1b
This rev. is related to #3462
Regarding addons/web/controllers/main.py
---
name of model ir.actions.actions is not translated
it's the name of server actions, client actions and window actions
that are translated.
Meaning the name of the ir.actions.actions will always be in English,
even when passing the user language within the context.
Regarding addons/web/static/src/js/views.js
---
There is no reason to pass the field values within the context
of the /web/action/load call: The read methods of actions are
not overidden to use the field values. Besides, it pollutes
the context of the action, leading to unwanted behavior, such
as the translation of the action name within the lang available in the
fields of the form view (e.g. the partner form).
Initially, the field values added in the context has been added
within the rev. 542928adde
Indeed, sidebar_context (or sidebar_eval_context nowadays), contains
the field values, and the additional_context passed to /web/action/load
is an extension of this sidebar_context.
We are not sure the reasons why the sidebar_context was passed to the
/web/action/load, but we believe it was to pass the session/user context
containing the lang, timezone, and so on, not to pass the fields values.
Setting an expense with a tax included with a negative base code sign was
getting the wrong amount (tax line as a credit instead of debit). So leading to
a total for the accounting entry superior of the total of the expense (should
not happend as the tax is included).
Add test to verify this scenario.
Fixes#4260, opw 618531
Module 'Warning' overwrites onchange_product_id method of purchase.order.line
The signature in the warning module had 'notes', while there isn't any 'notes'
parameter in the original method, in the purchase module.
The super call was also wrong, ignoring the optional fields, which
were therefore always set to the default value
The name must be changed when changing of product,
but not for other changes, quantity for instance.
The 'or not uom_id' is just for retro-compatibility concerns
uom_id being False actually means we just changed of product,
and the name must therefore be changed
name as been set as False in the onchange call in the view
for the product_id field, in this rev.,
so the name being False now means th change of product
Nevertheless, existing databases for which the view
is not up to date won't have this change
and we therefore have to rely on something else to know
when the product has been changed or not.
fixes#5295
opw-628138
When clicking on an element in a listview editable, the record_id
is not updated in the dataset, which means that when you switch to form
view, the list view does not display the last selected record.
Also, it should fix the issue solved by PR pull/2725
For example avoids a crash with:
TypeError: can't multiply sequence by non-int of type 'float'
when setting the quantity field of a salary rule to `1,0`
instead of `1.0`.
Fixes#5154Closes#5155
When having an invoice with multiple lines having the same
product_id and account_id, the residual amount was wrong.
This is due to the fact the residual amount of each line
was computed on the residual amount of the invoice divided
by the number of lines of the invoice, and the fact the main
select of the sql view was grouped by product_id, account_id.
So, for an invoice defined as
Product Account Total
A 1 10
A 1 10
B 1 10
The invoice analysis, grouped by product, account, computed
Product Account Total Residual
A 1 20 10
B 1 10 10
The residual amount '10' of the first line being
30 (the residual amount of the invoice)
divided by 3 (the number of lines in the invoice)
The residual amount of the invoice should actually be divided by
the number of lines in the invoice * the count
of occurences in the group by clause
So, in this case, (30 / 3) * 2 = 20
Replacing the big jointure by
SELECT count(*) FROM account_invoice_line l where invoice_id = ai.id
to get the number of lines in the invoice
is just an optimization for performances
opw-621672
when the user press tab in editable list views, the focus is supposed to
go to the next cell unless it is at the last cell of the line. in that
case, it is supposed to create a new record.
Sadly, when the last cell is readonly, this does not work. This commit
make sure that read only fields are properly ignored when computing the
last_field state.
When using %(date)s in the follow-up text in the follow-up levels configuration
the date was formatted within server date format
instead of the partner language date format.
Closes https://github.com/odoo/odoo/pull/5168
The module analytic_user_function allows to define a specific product
to use, when creating timesheet activities for a specific employee
with a specific contract
Nevertheless, the product was not set accordingly to this feature
for the first timesheet activity, because,
when initilialing the timesheet line,
the on_change_account_id, which returns
the product to use according to the user and contract, was called
without passing the user.
Besides, by default, on_change_account_id does not have a user_id parameter,
this parameter is added by the module analytic_user_function, overriding
this onchange, and adding a new user_id parameter (which is not a good pratice).
We therefore use multi_on_change_account_id, which allow to pass the user_id,
within the context
This reverts rev. 9f9e7ef0e1
As explained in 9f9e7ef0e1,
if a field "lang" is present in the view, clicking in any action item
in the more menu leaded for the action title to be translated
in the lang value of the form, such as in the partner form.
9f9e7ef0e1 fixed the issue,
but has as side-effect to not update correctly the active* keys.
So, if "active_id" was used in the context of the action button,
and the active_id was set in the dataset context, for example
because you come from another form, trough another action button
(For instance, Customers > Opportunities > Logged Calls),
the active_id was not updated with the current id of the record.
opw-620293
opw-617321
fixes#3462
Most pop servers don't perform deletions until QUIT. If for some reason
the process is killed while fetching a large quantity of messages, the
quit method isn't invoked, while the commit method has been. We may thus
end up with duplicated messages the next time we try to fetch. It therefore
helps to fetch the messages in small subsets and call the quit method between
those subsets.
Once a timesheet confirmed, the activity hours should not be modified,
for any reasons.
The constraint _check_sheet_state prevents to modify activities
for confirmed timesheets, but does not prevent the addition
of new activities within the current, but confirmed, timesheet.
opw-627415
fixes#5128
When sharing a record to a share user (for instance, the quotation),
the action in the url was set to "action_id=" instead of "action=",
therefore, the link sent just leaded to nowhere.
In saas-3, at rev. c7afc04be3
an assert has been introduced, asserting the record_id of the record class
is an integer.
Therefore, write operations using a string as id lead to a crash
if they trigger a workflow
If the date_done field of the model stock.picking is already filled in
it means the user do wanted to have this date of reception date
instead of the moment when the user clicked the receive button.
opw-627219
When converting a datetime field to date, using the widget date,
the date time value was just cropped, removing the hours,
therefore ignoring the user time zone.
For instance, if the user was in UTC + 1, for a date time 02/02/2015 00:30:00,
applying the widget date on this datetime had as result 02/01/2015,
due to the fact the UTC value of the datetime field was 02/01/2015 23:30:00
fixes#4420
opw-621281
This was broken by mistake at rev. d6c6f31231
partially undoing the introduction of this feature at
rev. 49c0ed6467 (probably due to the
confusing name of that manifest option)
In cases where data is directly given to the saveas_ajax controller,
the filename was not correctly set, as no read method was performed.
(The read call is useless as the data is already avaiable in such a case)
In such cases, the filename must be given in advance
opw-626707
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.
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
When sending a message with the "Compose new message" button on the right of the user menu, in the top bar, if you tried to save the message as template, you had a traceback because model field of email.template is mandatory, but was set to True because there is no model in such a case.
As there is no any relevant model in such a place, and that the field is mandatory, mail.message is pretty convenient as the default value.
Potentialy, the timezone too.
On item action click (such as menus in More.. and Print..), the data in form view had the priority on user context (through the sidebar_eval_context)
Therefore, if a field "lang" was present in the form view (like in partner form), the web/action/load xmlrpc call was using the partner language instead of the user language.
Example of wrong use case before the fix:
- Set the user language in French, then go to a partner form of a partner with English set as language
- Click on any button of the partner form, such as the "Invoices" button, notice that the last item of the breadcrumb is in English, instead of Frenh (the user language)
- Click on any menu opening a wizard in the More.. dropdown menu, notice that the wizard title is in English instead of French
- Print any report from the Print dropdown menu, notice that the report file name is in English. If you print the same report for the same partner but from the list view, the report file name is in French.
The destruction of one2many fields is forced with the event change:effective_readonly
This revision add the forced destruction for cancel(discard) button as well
Otherwise, one2many fields are not properly destroyed when hitting the button "discard" (from save or discard).
This can be problematic for one2many editable list views (such as invoice lines) if you discard while having a mandatory field not filled in the invoice line: You can't recreate an invoice, the one2many editable list is messed up
Use case: Create an invoice, create a line, leave the description, required field, empty. Then, discard. Then, click on create.
opw-616946
Denis Ledoux
Martin Trigaux
Josse Colpaert
Nicolas Lempereur
Martin Trigaux
Rifakat Haradwala
Vincent Vinet
David Monjoie
dhr-odoo
Christophe Simonis
rmu-odoo
Nicolas Martinelli
Olivier Dony
Somesh Khare
Rucha Dave
Akash Balar
Goffin Simon
Cedric Snauwaert
han-odoo
Monica
Jérome Maes
Loïc BELLIER
odoo-tac
xmo-odoo
Laetitia Gangloff
jbeficent
Romain Deheele
Olivier LAURENT
Aaron Bohy
Lionel Sausin (Numérigraphe)
Frédéric van der Essen
Anthony Muschang
Géry Debongnie
Christophe Combelles
Julien Laloux
Julien Legros
Sylvain LE GAL
Goffin Simon
Sandy Carter
Ravi Gohil
Wolfgang Taferner
fka-odoo
Yannick Vaucher
Antony Lesuisse
Gaurav Panchal
Martin Trigaux
Ravi Gohil