Switch to system random as number generator instead of the
default PRNG, which is not recommended for generating
security-related values such as unique tokens.
(Complements parent commit)
Closes#7761
Switch to system random as number generator instead of the
default PRNG, which is not recommended for generating
security-related values such as unique tokens.
Closes#7761
Commit 856bc6f2b1
may cause an issue if the auth_crypt module
is loaded before the base module. That should never
happen in normal circumstances, but forcing an
explicit import does not hurt and makes it safer.
Closes#6742
When a purchase order line doesn't have a product_id, the current onchange
method would return False as uom_id since b675ff1, thus introducing an issue
since uom_id is required and the field may be not shown (so not changeable).
closes#7770
opw-646088
The fact that it uses the correct template id now, fixes#6860
The read_group calculates the sum for every group for the non-stored fields as it is not possible
anymore to add it in the xml, fixes#6638
The read_group simply searches for all products in the group and sums the totals of the fields for these
products.
Due to commit 1576bc9891,
when name_search() is called on analytic accounts with
multiple path components (e.g. A/B/C), the intermediary
searches are done without the extra domain criterions,
because they should only apply to the leaf.
However because the limit was applied for each step
of the multi-path search, it was quite likely that
no valid results were found in the final filtering,
returning no result at all.
In fact the intermediary steps should not apply the
limit at all, because the leaves we're looking for
may actually be located under parents that are not
found when the limit is applied on each step.
This commits removes the limit (hopefully without
too much of an extra penalty for large databases)
It also introduces a better fallback in case the
multi-path search did not produce any result,
for example if the name of the lead really contains
a '/', and it was not meant to be a path separator.
The next action date (date_action) should be red if in the past, not if the
deadline date is in the past.
Introduced at 9f68a37
Courtesy of @sve-odoo 🎅
When clicking on the BOM state button from product.product, and clicking
on create afterward, it must open mrp.bom view with the product and product variant
already set(as with product.template).
opw:645045
If the price in a price list line is based on "Supplier Prices on the product form",
the model "product.supplierinfo" and "pricelist.partnerinfo" must be readable by the
public user.
opw:645709
Display claim_count and claim_count_out only to salesman and contact creation
group members as it requires these access rights to be computed.
Fixes#2458, Closes#7734
The state of a crm claim has been removed in f14eddb.
Thus, it is not possible to know the closure date and this commit hides
the field in the view.
opw-645826
A jquery selector $('td[id^=]') may have been valid once uppon a time,
but it cause error on current jquery versions.
Also in some case when we want to add a field on a view, there may be
a mess to detect the parent.
opw-645557
Unlink typical domain evaluation (ir.rule, filters,...), the evaluated domain
for automated actions did not included time in the context so it was not
possible to make time based conditions in domain.
This should be used with care as filters 'Based on Timed Condition' are still
possible and will probably be enough (and safer) in most cases.
The field "state" in "sale.report" model must consider the state used
by "sale.order.line" to be consistent with the view created in this model.
The function _sale_count in 'product.product' model must return
the number of product included in a "confirmed" or "done" sale order line.
opw:644200
If the variants are displayed by list of attributes, the image of a
product displayed would be updated to the image of the first variant.
But this was not done when using the customizing option "List View of
Variants".
opw-645729
Accessing the phonecall and the lead do not require the same permissions so
should not be computed in the same method.
The effect of the multi was already lost as the phonecall_count was already
computed in another loop.
Add the phonecall_count button in a second view to make the computation only if
the user has the requried access rights.
Fixes#2458
When the max seats available is set to 0, there should not be a limit to
the seats available.
Previously this was not taken into account in the frontend event ticket
sale, so an event would appear to be sold out.
fixes#6999
opw-645542
The onchange on partner field must not fill the company name if
the partner is not a company or not in a company. If the partner
is not a company, the contact name field must be filled with the
partner name.
opw:644878
Delete the code introduced by 656f8241d5
Group by didn't work in calendar tree view, group of records showed (0)
as number of related records for each group.
closes#7602
opw:644735
When calculating the cost, quantity did not take the product efficiency into
account when calculating the cost. The quantities on the MO order were correct,
but not the cost that needs to be increased to compensent efficiency.
Closes#5927Closes#7648
When doing a copy of a google drive spreadsheet (in google_drive.py's
copy_doc method, using the following google API call
https://developers.google.com/drive/v2/reference/files/copy). Google
server return an error if we used the old spreadsheet KeyId.
The new FileId is available in the AlternateLink and this commit updates
it.
closes#7660
opw-644889
In backend, the method "_unit_compute" doesn't round the fixed tax amount
before adding to "cur_price_unit" in the case "tax.include_base_amount".
opw:644421
When giving back change, prioritize the same cache method as the one that was
use for the transaction.
This prevents cases where cash input is registered in journal B and change in
journal A.
Fixes#6975, closes#6976
The commit 312b85e added a reloading of the chatter messages after
closing the mail composer. But e.g in Messaging > Inbox a simple reload
isn't enough. For now this commit restrict the reload to chatter logs
(e.g the chatter of a quotation).
related to PR #7596
In order to fix Python bug https://bugs.python.org/issue16041
a maximum line length was introduced in poplib when reading
email contents from the POP3 server.
That limit is set to prevent DoS attacks via malicious POP3
servers.
The default limit (2048) seems to be too low for emails
commonly found on the internet, retrieved via POP3 from
popular mail services such as GMail, Hotmail, etc.
(The POP3 servers might send back the lines verbatim
without splitting them up)
This is discussed in follow-up Python bug
https://bugs.python.org/issue23906.
Workaround implemented by forcing a higher default limit
to accomodate POP3 responses with lines up to 64KB.
Once the document module installed,
It was mandatory for a user to have the
Knowledge User group in order
to edit/unlink an attachment, even
if this attachment wasn't using
the document directory feature
opw-644712
Fixes#7599
4adb4b8d15
corrected the fact the quotation email
wasn't sent if you did not come back
from the payment provider
(when you closed your browser after
the payment but before coming back
to Odoo).
Before the above revision, the quotation
email was sent for payment methods
not redirecting to payment providers,
like transfers. It was no longer the case
with the above revision.
This revision re-introduces this behavior:
If there is a feedback from a transaction,
but the transaction isn't confirmed,
we send the quotation email without confirming
the sale order, like it was the case before
opw-644670
Always reload the message after the mail composer message is closed.
Since there is several unrelated model it would probably messy to go
from the mail thread to the mail composer popup to see if a new message
is posted (or get it and add it in the chatter like done in the simple
message editor).
With this change, anytime the mail composer modal is closed the mail
thread messages are reloaded.
closes#7596
opw-644406
In the tree view, the domain for the field `analytic_account`
was already
`[('type','in',['normal','contract'])]`
It's therefore normal to apply the same domain for
this field in the form view.
Closes#2733
When the view form is loaded passing by the kanban list, the kanban
dataset data could be loaded after the view form is displayed.
When going manually to the view form, the human is usually enough slow
so the dataset ids are already loaded, but when loading directly the
view form (for example an "Edit" link from a record on the website or a
refresh) it can not be. For example on runbot the issue happened more or
less 50% of the time, and on localhost 90% of the time.
closes#7525
opw-642636
If too many tags (or too long tags) where present in a many2many tags
widgets, it could go over the field and cover other thing in the UI.
Now the field size expands with the content (and in a way it is more
visually similar before and after 'Edit' so it is nice).
closes#7579
opw-644236
When name_search is called with an extra domain
filter (args) and a pattern (name) containing
multi-level accounts, such as `A / B / C`, only
the last account (`C`) has to match the domain.
The intermediary parent accounts do not have to
match.
The domain was previously applied for each parent
in the lookup. This prevented searching for
multi-level accounts or copy-pasting full account
names whenever a domain was present and did not
match every account in the hierarchy.
In case you customize these emails, you do not want
to have them reset when you update the module (-u)
Same thing for the two default value in this file
for event.type
opw-644082
The field property_account_position is added by the view
account.view_partner_property_form which is restricted to users with accounting
rights. If tired to access the view, the inheritance made on l10n_ro would fail.
Fixes#6952
In the receipt report, the quantity decimal precision
was hardcoded to 0, while it should use the decimal
precision from the field definition.
opw-644507
There is no easy way to edit the values sent
to newly generated users from oauth_signup.
In some cases,
the mapping from an oauth provider can be different.
* ex: login is something other than email
In other cases,
there are additional fields in res_users added by a module
* ex: firstname and last name in `partner_firstname`
This factorization allows modules inheriting from `auth_oauth_signup`
to alter values sent to the copy of Template User.
This means smaller changes to the default behaviour
and the ability to properly inherit
(multiple times if needed)
this module without losing needed behaviour.
Closes#2355
Not just when coming back from the payment provider to the
payment validation route `/shop/payment/validate`.
Otherwise, if you do not come back from the payment provider
page, that you quit just after having paid but just before
being redirected to Odoo, you do not receive the email.
The change within the `sale` module, while this issue concerns
`website_sale` only, has been accepted because this is a mechanism
that could be used by other modules.
opw-644348
In the aged balance report, the reconcile entries are excluded
except if the reconciliation date is greater than the date for which the aged balance report is requested.
But this exception should never include opening entries.
opw:643172
The amount to pay must be sent without comma to ogone.
e.g., for 66.99 EUR, the amount sent must be 6699.
To do that, we simply applied 66.99 * 100, which
seems rather good.
However, due to the fact how floats are handled in computers,
`66.99 * 100` returns 6698.999999999999
and
`int(6698.999999999999)` returns 6698
while we expected 6699
Using `float_repr` with `0` as decimal precision
instead of using `int` solves this issue.
`float_repr(6698.999999999999, 0)` returns 6699, as expected.
The valuation wizard is based on stock moves and currently only takes into
account the moves which have different companies in source vs destination
locations.
This is a problem because all user-created locations have a default company set
to the user's company, even the "virtual" ones. For example in the demo dataset
visible on runbot, some supplier locations have a company set and some don't.
So we have to make sure to include every move coming from/going to
outside locations based on the locations's type too.
Closes#7530
Method action_produce does not support the case where the same product appears
on multiple lines. We do this to avoid major changes in a stable version.
opw-644093
When building a new suvery, and sending invitation
trough private emails, it wasn't possible
to fill the survey from the link sent
if you were not logged as the user who sent
the invitation, or as a survey manager
opw-644210
Fixes#7486
The menu entry in Warehouse > Current Inventory Valuation is a shortcut to the
same results as the wizard in Reports > Warehouse > Valuation. However when
using the "current valuation" menu entry, the list is given without grouping by
product and location, so it's basically just a glorified list of stock moves
that no Warehouse manager is going to understand.
Let's just add the same default grouping to let the results make sense.
Closes#7531
A log analysis showed that the normalized query below was executed very often
with a slow explain plan using a seq scan.
```sql
SELECT move_id, date
FROM account_move_line
WHERE journal_id = <journal_id>
AND period_id = <period_id>
AND create_uid = <user_id>
AND state = 'draft'
ORDER BY id DESC LIMIT 0;
```
This query is called in the _default_get of account.move.line to find the last
unbalanced move line.
The existing index can be improved to cover this query as well, showing an
impressive improvement of the explain plan as explained here:
https://github.com/odoo/odoo/pull/7430#issuecomment-119521031Closes#7430
When a PO is created automatically from a procurement, the fiscal position is
not chosen correctly. We need to choose the fiscal position in the same way if
the PO is created manually or automatically.
Follows commit 1062905acbFixes#3863
opw-643916
It is necessary to round the quantities with the appropriate precision. Indeed,
since onchange_quantity and onchange_uos_quantity trigger each other indirectly,
it is quite easy to fall in an infinite loop if the uom and uos precisions are
different.
Follows commit 6e346f0adb
opw-643651
The behavior of the datetime widget was to focus in the field every time a date
is chosen. This causes an issue if the datetime widget is called from an
editable list. Indeed, the list editable will consider that the value has been
set, and therefore the value will not be changed anymore if the user choses
another date.
The new behavior is to put the focus only when the date picker is hidden,
therefore the editable list will consider the value set only when the selection
is done.
opw-644062
Fixes#7463
To be consistant with the results of _get_stock. Otherwise search made on
stock_available may not display results with the same value than the search
criteria.
Fixes#3976
When we go from one field to another via the tab key, in the form view what happens is:
{{we get a blur from the current field}}
-> if [[widget was not in state clicked (which can be gotten for example by clicking on a focused field)]]
-> blur event is cancelled,
-> the blur event is set to be triggered soon
-> the clicked state is set to false
{{we may get a focus for the next field}}
-> if [next field get an onfocus event]
-> blur event is cancelled,
So if :
- the state is not clicked and,
- the next field don't get an focus event.
We get a blur event which will either save (if a field value has been changed) or cancel
the form view editing and will hide the current edition, hence losing the focus.
For example, it happens on a readonly fields with field containing an `<a />` tag, on
some browser (for example google chrome), the focus event will not get triggered (it still
work if we were in a clicked state) so we can't cycle thought a list editable cells if there is a readonly field in it.
closes#7446
opw-643718
If 'Product UoS' has a higher precision than 'Product Unit of Measure', the
method onchange_uos_quantity will be called over and over by an infinite loop
if 'product_uos_qty' doesn't have the sufficient number of decimals.
opw-643651
The product_id_change method of sale.order.line
ignored the passed context.
The context was simply overwritten,
which is no a good practice.
Besides, it prevents customizations.
Closes#7447
opw-643983
Use the lang from the sale order's partner when updating suggested
product line. To achieve this, the onchange has been replaced by an
onchange of the new api which gives access to all the fields.
closes#7268
opw-643098
When sending an email from mail.compose.message using a template, the system
should use the outgoing mail server associated to the template.
Introduce context hack to keep these values.
This should NOT to be forward ported to version 8 where a proper fix exists.
Fixes#3848
This reverts commit 2f5d681135.
The previous commit was intended to fix a wrong assumption in case the
purchase uom was different to the standard uom.
The wrong assumption:
- price is related to purchase uom
- therefore it was tried to convert the bom price accordingly
- as the price needs to be already in standard uom it does lead to a
wrong calculation now
Closes#7421
To determine the account.move.line to reconcile, first it tries to match with
the ref and the amount of the account.bank.statement.line and if it doesn't match,
it just tries to match with the amount.
opw:643867
If copy=True for production_id, a move created from a push rule will be added
in the list of Product Produced. Therefore, we must set manually the value of
production_id of the scrapped moves.
opw-643877
Besides, the test was particularly useful:
It tested that when 'Buyer' was sent as firstname
and 'Nobert' as lastname to Authorize,
authorize returned the opposite, 'Norbert' as firstname
and 'Buyer' as last name.
In the partner model, there is only one field `name`.
The first name and the last name are not within two
separated fields.
By assumption, the firstname is written before the last name
(first <> last)
This assumption should be kept when sending the
first name / last name of the partner to the payment acquirers
e.g. Paypal.
opw-643120
When duplicating analytic accounts, child accounts are duplicated as well.
The custom copy method removes the analytic lines but this applies only on the
first copy. As the copy_data method recursively copies child accounts, these
child accounts did not use the custom copy method but the basic copy_data.
Move to copy_data
Fixes#6368, lp:1149676
Ship in 2 steps:
The Packing zone location is inactive but it is used by default as destination
location (instead of Output) in the Pick operation.
opw-643734
The field display_name is present in account_report_company but not in base
on the res.partner (has been added in v8 in base).
Create a hook method to keep using the slow CASE in base and switch to the
faster display_name when installing account_report_company.
When you apply payment in POS,
it takes current time for "date" field
on bank statement line,
but should use context_timestamp to take care
of user timezone adjustments.
Example:
If user is in time zone GMT-6:00,
then after 6:00pm all bank statement lines will be recorded
with date of next day, and all closing reports and related
accounting will be wrong!
Fixes#2199Closes#2200
When a landed costs is applied on goods that are already out, these landed
costs need to be subtracted in the stock valuation account and added in the output account.
(they were just added before)
When the landed cost is negative, it needs to do the opposite for what is already out also.
When the public user comments the website, he will be redirected
to the login page and his comment will be posted with his logged
user name.
opw:643412
This is related to rev. 55b7f15ee2
Prevent crash when there is no line to display
in the stock valuation report
Reporting > Warehouse > Stock Valuation.
Like when there is not yet any data, or the filter gives no result
opw-643748
While working on project task it is possible
to record "task work" that will automatically
create timesheet lines. These are not by default
included into any timesheet, but they need to
appear in reporting nonetheless.
These lines disappeared from the analysis view
after the performance improvement of
rev. fe31451899
which introduced a JOIN with the `totals`
CTE table - and should have been LEFT JOIN.
When printing these reports from the accounts list
Accounting > Configuration > Accounts > Print menu > General Ledger
the ID of the wizard was considered as the ID of an account,
leading to obvious issues when this ID wasn't available
in the account_account table, or when the user
do not had the access rights to see the accounts with this
ID.
The override was completely useless: The wizard is
launched whether you print these reports from
Accounting > Reporting > Legal reports > Accounting Reports
or from the accounts list, and the super _get_account can
be called correctly for these two use cases.
opw-643589
The precision of the field 'hours' in project.task.work and the precision of
'remaining_hours' are not the same. This is why the difference between them can
generate some very small negative difference which implies an infinite percentage for
the working progress time.
opw:643649
This revision is related to 279f225cf0.
`_get_pickings` is used as trigger store method
for several computation fields.
The trigger restriction applied in the above commit should
only be applied on the `min_date`, `max_date` and
`priority` fields.
This rev. is related to 279f225cf0.
The `product_qty` computation priority should be
important, as other compute fields depends on it
such as `weight` and `weight_net` from the
delivery module
This is a performance revision.
Some stored functions field were recomputed uselessly.
In mrp, `hour_total` and `cycle_total` were recomputed
at each write on `mrp.production`, while they should be recomputed
only when there is a change on the `workcenter_lines` field,
or when there is a change in the `hour` or `cycle` field
of these `workcenter_lines`.
In stock, `min_date`, `max_date` and `priority` of
`stock.picking` were recomputed each time a new move
was added to the picking,
wether or not the 'expected_date' of this move
was between the `stock.picking` `min_date` and `max_date`,
and the priority not greater.
In stock, `product_qty` of `stock.move` was recomputed
at each write on the `stock.move`, while it should be
recomputed only when there is a change in `product_id`,
`product_uom` or `product_uom_qty`, as the computation
method only depends on these three fields.
In stock_account, the `invoice_state` of `stock.picking`
was recomputed each time a new `stock.move` was associated
to the picking, wether or not the `invoice_state` of the move
was already the same than the `invoice_state` of the picking.
opw-643560
This fixes 2 issues.
First, it keeps consistent the precision required for posted entries and the
precision for the balance assertion. This could be an issue if the account
precision is larger than 4.
Then, it makes sure to round the amount with the appropriate precision to avoid
numerical errors. For example 1.2344 - 1.2345 = -9.999999999998899e-05, which
is indeed smaller than the required precision 10 ** -4.
A minimum precision of 10 ** -5 is kept for historical reason.
Fixes#7276
opw-643305
Revert the modification from commit 8ae67f6a54 ; it appears that the test of required field is done before the computation of the related field and that leads to a Validation Error.
As the field employee_id is already required and the user_id is related to this field, the attribute required is redundant and unecessary.
When we return goods and a refund is created, we check the purchase order
linked to the original move. Therefore, the appropriate currency and unit
prices will be chosen.
opw-643085
The price without taxe must be rounded on each line like 'price_subtotal' in "sale.order.line"
with digits_compute= dp.get_precision('Account').
The total taxes included must be the sum of the rounded total without taxe and
the rounded taxes like in "sale.order" in _amount_all.
opw:643254
Returning `picking_id` can be useful for overrides.
In addition, when there is no return statement,
the method basically returns None.
As this is a public method (not beginning with '_'), it can
be called with an xmlrpc call, and `None` is not an
accepted return value for the xmlrpc protocol.
Closes#1714
A variable "lines" is instancied few lines above,
with the exact same browse call, and there is no
operation that could lead to an update of the result
between these two browse calls.
Closes#1394
When confirming a sales order with invoicing control
based on "Delivery order", confirming the quotation
didn't post the "Quotation Confirmed" message
subtype in the sales order thread.
opw-642744
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
Incoming shipments are marked red according to creation date which does
not really make much sense.
closes#1061
note: it was already like this in 8.0 with 201f1c323
When creating an event in at 4 pm,
while being in UTC +2 (Europe/Brussels),
The start date sent to Google was set as
'2015-07-03T16:00:00+02:00',
but the timezone was described as 'UTC', giving
therefore giving contradictory information.
At the end, in the google calendar,
the event was set in the UTC timezone,
while it should have been set in GMT +2 (Europe/Brussels).
opw-640825
When column 'writeoff_amount' gets displayed on a tree view and function
_get_writeoff_amount() is called with multiple ids, the returned amounts keeps
getting bigger every row.
Closes#7211
Before this rev.,
if you define a carrier
- without advanced price rules
- with a normal price set to 0.0
- Free if more than amount unchecked
When you try to invoice a delivery order
(coming from a sales order with as invoicing policy
"on delivery order)
No grid was found, while there was one, with as price 0.0
Closes#1364
The amount total computed for pos order must be the sum of the rounded tax amount
and the rounded untax amount. Inspired from _amount_total in "sale.order".
opw:643254
Don't retrieve the binary contents just to display the size, but pass context
with bin_size=True instead
Always pass filename in download link
Combination of patches from the bug report from Enrico Ganzaroli, Cedric Le
Brouster and Holger Brunn
Fixes#4899, lp:1167429
In account_budget module,
when creating a budget position,
the user can select view accounts and also accounts with consolidation children,
in addition to normal accounts.
However, when viewing budgets with positions containing only view accounts,
the "practical amount" field was always zero.
Since these type of accounts are accepted as budget positions,
the system should take into account children and consolidation children
when computing the practical amount.
Fixes#372Closes#1247
Don't preload company logo of the wrong company
When a user other than the admin signed in
and was in a company different than the admin
and this company had a different logo,
the company logo (in the upper left corner)
displayed the logo of the admin company,
instead of the logo of the company of this
user.
As soon as the user refreshed the page
in his browser, the issue was resolved,
but the logo should be the good one
from the beginning.
Closes#1453
Fixes the impossibility to invoice purchase order lines, which were never
invoiced but set to invoiced by validating a first invoice created by invoice
control "manual".
In the method action_invoice, the call to the method "_prepare_analytic_account" in dict "inv_line"
had no effect because the value of account_analytic_id was being cleared by the product_id_change statement.
So in the end the invoice line was created without any account attached
Now it checks for an existing value, and if it is not already filled in,
the value from _prepare_analytic_account is taken.
As of version 8.0, search_count method has been implemented
Usage in this place is not needed though,
as we just need to know if there are messages in domain,
not the exact number of them.
Due to that we replace method search_count with search and add a limit of 1,
which provides better performances.
Fixes#6670Closes#6679
When invoicing in currency A and being paid in currency B, the exchange
rate between those currencies might differ between the invoice date and
the payment date.
When reconciling, invoiced amounts should be converted using the invoice
date exchange rate.
opw-640248
In the Account Tax Decalaration wizard,
Accounting > Reporting > Generic Reporting > Taxes > Taxes Report,
When not choosing the start/end period, but choosing
a fiscal year, the fiscal year was simply ignored,
the report took a fiscal year randomly.
In addition, if no fiscal year was chosen,
the fiscal year randomly chosen could even
not be a fiscal year of the right company,
in a multi-company environment.
closes#7219
opw-643194
Some tests (e.g. mail) have expensive and significant DB setup for a
number of small and cheap tests. Using a TransactionCase, the DB setup
far dominates the tests themselves, by up to 10x (mail unit tests take
~130s on my machine, the tests themselves take ~15s).
The SavepointCase introduced here is an hybrid of SingleTransactionCase
and TransactionCase: it uses a single transaction for all tests in a
class, but each test case is isolated by a rollbacked savepoint. This
allows a common DB setup (via setUpClass) while keeping independent
tests.
TransactionCase should remain the primary test case superclass, but
SavepointCase can be a fair optimisation when setup costs far dominate.
The computation of total_invoiced field was very slow when the size of
account.invoice.report grows. This is due to usage of the field
user_currency_price_total that requires to build the full view (generates query
(id in []) for function field).
Using temporary SQL view (inspired by caf333e), directly filter the needed
items and avoid building the full table.
Fixes#6654
To distinguish two ir.attachment 'File Content', we base it on the file
size (this I imagine is for efficiency).
This is done by setting bin_size in the context. Doing this, the
returned db_datas field will be the file size of the converted to base64
content (if no filestore).
But this size is returned in string format, so "get_nice_size" (in
openerp/osv/fields.py) which gets this size calculates the length of the
string. e.g: if the size is '2142' get_nice_size will return 4.
This fix solves this by converting the string to an integer, thus
unifying it with the filestore case (where we use os.path.getsize which
return an integer).
Also, the field presenting the issue (FieldBinaryFile) has been changed
so it is always updated even if the size is the same (as it was already
done by 3632949 for FieldBinaryImage widget).
closes#7223
opw-643071
- remove 2011 tax data
- remove unneeded tax account for 0% taxes
- TVA en amont moved under 421611 instead of 422611
- Fix issues with IB-PA, AP-PA, IP-PA and all taxes with children
- improve structure for tax codes
- fix account type (other -> view)
- add fiscal position mappings
- credit part of IC/EC taxes goes into account 461 instead of 421
- add missing template account for TVA en amont extracommunautaire
- fix a long standing issue with the reconcile flag on accounts
- use TRUE/FALSE instead of t/f in the csv
- added source XLS file with conversion script
Closes#5870
The paid status should be removed automatically once the membership is
expired. Previously, it would only be done when some other models fields
changed (invoice, membership_line, res.partner).
closes#6823
related to opw-640440
Field show_menu generates three menus Introduction, Location and Register on the
page of the event on the website.
Generating new menus requires the Technical Features groups so checking this box
would produce and error on non-technical users.
Moreover these menus are hardcoded, making it less useful and may produce
unexpected behaviour (replaces previous menus).
Hide the menus to non-technical users and add help message explaining the
effect of the field.
Fixes#7099
When a PO line is deleted, it sets the related procurements in exception.
This fix logs this action in the procurement chatter, for WMS administration
and maintenance purposes.
When a MO is cancelled, it sets the related procurements in exception.
This fix logs this action in the procurement chatter, for WMS administration
and maintenance purposes.
This decision comes from the following bug:
- Go to Sales -> Quotations, and open any existing quotation in form view (the
partner must have an address defined)
- Click on the partner
- Click on the stat button "Claims"
- You notice that the address of the partner is included in the search
This is due to the context property show_address which is set to 1 when a
quotation is open. Therefore, it is necessary to filter out this keyword.
Since the prefix "show_" is used for only few context variables, it was decided
to define this pattern as a standard pattern to filter out.
opw-642893
If the transaction already exists, the amount total of the transaction must
be updated.
The case occured when:
[1] you put a product A in the cart
[2] click on "Process Checkout" and click "Confirm"
[3] select Adyen or Paypal as payment method
[4] click on "Pay Now"
[5] return in the cart instead of paying your order
[6] add a product B in the cart
[7] click on "Process Checkout" and click "Confirm"
[8] select Adyen or Paypal as payment method
[9] click on "Pay Now"
Now check the transaction payment linked to the order in backend, the total amount of the order is equal
to price A + price B and the total amount of the transaction payment is equal to price A.
This commit solves this problem.
opw:634119
The procurement created from a move has as source document[by priority]:
[1] move.rule_id.name
[2] move.origin
[3] move.picking_id.name
ps: the internal transfer is created with this procurement.
opw:641887