When adding a font-awesome icon to a mail template, the icon is
converted to an image once the template is saved. To do that, the
code checks all the `.fa-XXX` definitions in the stylesheets to know
which content the image have to use. The problem is that this was
not considering the font-awesome aliases. Indeed, the `fa-facebook-f`
icon was able to be used while its alias `fa-facebook` was not working.
Rev acd8c4de18 prevents the creation of default values for fields that
are not defined. This is too restrictive because of the following
points:
- one may want to create default values for fields that are yet to be
defined
- "fake" default fields used in res.config that do not point to real
fields
The initial scenario this revision was trying to fix is the creation of
wrong default values through studio. This scenario is still fixed, as it
concerns the last `except` branch.
The tests have been updated to reflect these changes.
In a SO, the "Invoiced Qty" can decrease if the refund is generated from
the SO. It doesn't decrease if the refund is generated from the Invoice.
However, we don't have this mechanism in a PO since the invoice is not
generated directly from the PO. There is therefore no way to decrease
the "Billed Qty".
We authorize the "Billed Qty" to decrease in the case of PO.
Complement of commit 9b5281adb4
opw-724474
A warning was raised when an invoice line had a negative amount that may cause some
trouble when dealing with discount (negative amount). Now, the warning is raised
when the amount total of the invoice falls bellow 0.
Currently there are several issues with this configuration box
* default_<field> does not generate automatically ir.values anymore.
Defining default_model does not work since it is not linked to an
existing <field> in current model sale.config.settings. Checkbox
value is therefore not saved and lost at reload;
* box label is not clear as user may understand unchecking it drops
all aliases or email support. This is not the case as it is only used
to define an alias creating unassigned leads. This is a rare use case
where leads assignation is done manually;
* checking / unchecking the 'Emails' box does not have any effect on
default info alias. This is counter-intuitive as user asks to remove
the feature but it still works in background;
This commit fixes those issues by
* correctly setting the checkbox value in an ir.config_parameter so that
it is not lost anymore at reload;
* inactivating info alias by default;
* adding onchanges so that values are reset when unchecking checkboxes;
* updating string and displayed label and helps for the 'Emails' section;
* putting that Emails checkbox in advanced mode as it is a rare use case;
When not logged in the webstie on Safari and clicking on "Have a Question? Chat with us",
it creates a mail.channel from get_mail_channel and it also creates a translation.
But with Safari, the accept_languages is set with the value 'fr-fr', and this value was set
in the context as the lang='fr_fr'. So when the translation was created, a bad insert query was
raised in sql because the lang didn't exist in the res.lang table. When a translation is created,
the function _get_languages checked that the language is in the table.
So it was impossible to use the chatter when the user is not logged.
NB: interseting functions to see:
-setup_lang in odoo/http.py
-_dispatch in addons/website/models/ir_http.py
-get_mail_channel in addons/im_livechat/models/im_livechat_channel.py
opw:716519
When clicking on smart button "Manufacturing" for a variant, the action
"act_product_mrp_production" was called to apply the default filter on
product_id = active_id to select the right mrp.production. But the field
product_id was also called "Raw material" and a wrong domain was applied
each the action was triggered from a variant.
opw:725050
When unlinking an ir.model, all the ir.model.constraint linked to this
ir.model must be removed to avoid to call unexisting model.
The ir.model.constraint records, are created with module = the module where the related field
has been declared. But when unlinking the ir.model in function _module_data_uninstall, the related
ir.model.constraint to remove were chosen according to the removed modules. So with models
declaring constraints on inherited fields, some problems occured because the model could be removed
and not all the related constraints.
opw:716032
- Create an expense with a tax
- Validate and post entries
3 AML are created, one on the expense account, one on the account
payable, one for the tax. However, the AML of the expense account is not
linked to the tax, and therefore does not appear in the reports.
opw-715488
- Create a partner who is a contact of a company
- Associate this partner to an employee
- Create an expense for the employee, validate and post entries
The AML created are linked to the company, not the partner.
Since the bank account account is registered on the partner, and not the
company, this is more logical to link the AML with the partner.
opw-724550
This reverts commit 2d10c5eb43.
The fix was only needed up to saas-14. In saas-15 and over there is
another fix which adds the `uid` parameter back: 65ac6b8ae
The `issuperset` method check if a set contains all the element of the set given
in paremeter. So in our case, the user needed to be in all the view groups
to get the inherited view. That's not the behaviour expected.
If the user is in only one of the group required to have access to the view,
we want to return the inherited view.
If you followed these steps, Chrome deleted the link and image:
1. Create a new mass mailing, fill the subject.
2. Drag & drop any snippet with pictograms.
3. Change a pictogram for an image.
4. Add a link to the image.
5. Save the record.
This happen in chrome if the image was for example floating in
the link, so this change check if an element is a contained element
is visible before removing it.
This issue doesn't happen with [jQuery 3][1] and may be linked to
[this][2].
[1]: http://api.jquery.com/visible-selector/
[2]: http://stackoverflow.com/a/8337382/1468388closes#15623
opw-710237
note: this is only needed in 9.0 and saas-11 because this features
doesn't seem present in version 10.0
The editable list has a `is_valid` method which checks that all the
records it contains have valid data. The problem is that it was
considering that all the records in the `dataset.cache` were part of
the x2x field the editable list is working with. This is wrong as the
`dataset.cache` can contain information which are not part of the
editable list anymore.
See the commit which introduced the use of the `dataset.cache`:
a9d20d9fa0
This was causing issues with rare cases of an editable list which
contains another editable list (even invisible) which was sharing
common information with its parent editable list.
opw-710627
This adds the hw_screen module which is responsible for receiving
rendered HTML from a POS client and sending it to a running Chromium
browser. This is done by sending Remote Debugging Protocol messages over
a WebSocket provided by Chromium. This allows hw_screen to evaluate
arbitrary JS. This is used to seamlessly (without flickering) update the
browser.
This also includes changes to the POSBox. X, Chromium and some
miscellaneous other programs were added. Functionality was added that
automatically displays a fullscreen, UI-less Chromium browser when the
POSBox starts up. This is accomplished through x_application.sh, which
gets executed only when a display is detected. After the browser starts,
it will display a specific screen until it receives the first order update
from a POS client.
Creates a public controller to be able to display the interface on an external
device not connected to the posbox (e.g. tablet)
Courtesy of JOV, LPE, ODO and MAT
A customer facing display is any monitor that can be connected through
HDMI on the POSBox. When enabling the customer facing display option the
customer will get a realtime overview of their current order, what they
have to pay and the change they should receive.
What is displayed on the customer facing display is fully customizeable
through web_editor, two snippets are provided that will be dynamically
updated (Order Block, Payment Info Block) as the order changes in the
POS.
The POSBox handles the live updates through hw_screen.
The HTML that eventually gets sent to hw_screen contains references to
remote resources. All of these remote resources are available on the
Odoo server, no other external connections have to be made. Resources
that are unavailable for the POSBox (like product images) are base64
encoded and included in the HTML. This is accomplished by using the BASE
HTML tag. This does mean that the customer facing display will *not*
work with a POS client opened through localhost or 127.0.0.1. The POS
has to be opened through an IP address (or URL) the POSBox can reach.
Courtesy of JOV, LPE, GED and MAT
When a session was opened in Internet Explorer (11 at least), it was directly
closed.
This is due to the concurrency mechanism created to avoid having two tabs opened
with the same window.
To avoid having two tabs opened on the same session, the browser listen to
'storage' event, triggered when the localstorage is updated.
On most browsers, this is only triggers when the localstorage is updated in a
different window of the same browser.
On IE 11, it is also triggered when the localstorage is modified in the current
window.
It is unclear if this is a bad interpretation of the specification or not.
A bug has been reported[1] to Microsoft about it but is, as of today, postponed
without action.
To avoid the above issue, add a parameter containing a timestamp at the session
launch and be able to detect that the storage events comes from the current
window.
opw-724851
[1] https://connect.microsoft.com/IE/feedback/details/774798/localstorage-event-fired-in-source-window
OPW: 716163
This is needed to fix the following problem: adding a partner to res_partner.child_ids will mark all element of child_ids as 'todo'
and trigger a write on res_parner.commercial_partner_id for all element of the child_ids and then on the related field
account_invoice.commercial_partner_id. This can cause problem if partner in child_ids belong to different company and have invoices. This will throw a
read access error when doing the _write method of account_invoice. Adding the compute_related=True to account_invoice.commercial_partner_id
ensure that the _write on that field is done in sudo.
In fb05d884 event that were not displayed for arabic were fixed but
there could be an error when displaying timezone caused by this change.
As said in https://fullcalendar.io/docs1/event_data/ignoreTimezone/ the
ignoreTimezone parameter is set to `true` by default in FullCalendar 1
(this is not the case in current FullCalendar).
So there is two way to solves this time zone issue:
- keep fb05d884 and have the parameter ignoreTimezone set to `false`
- use momentjs `.toString()` to get a javascript english date string
which will thereafter be parsed by javascript `new Date()`.
This commit use the second way since it is nearer what was originaly and
hopefully safer.
opw-705752
momentjs doc on toString: http://momentjs.com/docs/#/displaying/as-string/
Steps to reproduce:
-Go to accounting dashboard
-Click on "More" in vendor bills dashboard
-Click on "bills analysis"
Bug: it opened the account.invoice.report view, which crashed.
Reason: The function get_names in addons/product/models/product.py got an empty record set
product.category(None,) and returned [False] so when joining " \ " with [False], it crashed.
The empty record set was returned when the categ_id of an account.invoice.report() was None.
opw:724783
In a form view, when a field onchange lead to a change on a x2many,
there was two different behavior:
- if the x2many had an embedded view (eg. a tree view inside a form
view) the onchange would notify that it expected the x2many field in
this embedded view to be changed and handled the changes correctly.
- if the x2many had a default view, the onchange ORM would not be
aware the x2many could be modified and would not sent the changes
back causing blank or not updated x2m lines and error on save.
---
Two solutions were birthed to solve the second point:
=> PR #10557 = solving everything
With this PR the onchange in the ORM is aware of every fields in the
current view (even field in a x2m in a x2m in a x2m in a form view) and
if any of these are change the javascript gets back the value of the
fields present in the view.
This PR has currently not been merged by fear of changing too much and
anyway could only be done in master.
=> PR #12249 = if no field for x2many, send its form view fields
With this change, if the ORM onchange is not aware of the fields in the
x2many widget to returns, all the field in the x2m default form view are
returned.
This was merged in bbdf960 but introduced a number of other issue:
- in most situation the x2many is represented by a list view, which may
have fields missing of the form view, so the original is still present.
- the view used may differ from the default form view in other way
(depending on value in context or other possibilities).
- the form view could have fields not present in the form view which
could end up in `write` on fields which should not be written to.
---
This commit reverts bbdf960 and adapts a small part of #10557 so the
x2many with default view works as an embedded x2many. For more than one
level (eg. a x2many in a x2many) this would still not work but it is
only solvable by a PR such as #10557 which could only be targetted for
master.
With this commit:
- the list of fields sent to ORM onchange is computed at the first onchange
- the fields from a x2many field default view is sent for onchange
- the initial onchange on record creation is delayed to when x2many are loaded
closes#12249, closes#15336, closes#15890fixes#11236, fixes#12249, fixes#15129, #15419
opw-705965 opw-716095 opw-715619 opw-710440
note: already present in 10.0 (with a test) as f65475d68
In f65475d6 one2many fields of default view in a form view were propagated
to the ORM so the value received from an onchange was not empty.
These new steps test this on a tree view embedded in a form view, or a
tree view originating from a default view by testing onchange adding row
or updating values of a one2many.
In a form view, when a field onchange lead to a change on a x2many,
there was two different behavior:
- if the x2many had an embedded view (eg. a tree view inside a form
view) the onchange would notify that it expected the x2many field in
this embedded view to be changed and handled the changes correctly.
- if the x2many had a default view, the onchange ORM would not be
aware the x2many could be modified and would not sent the changes
back causing blank or not updated x2m lines and error on save.
---
Two solutions were birthed to solve the second point:
=> PR #10557 = solving everything
With this PR the onchange in the ORM is aware of every fields in the
current view (even field in a x2m in a x2m in a x2m in a form view) and
if any of these are change the javascript gets back the value of the
fields present in the view.
This PR has currently not been merged by fear of changing too much and
anyway could only be done in master.
=> PR #12249 = if no field for x2many, send its form view fields
With this change, if the ORM onchange is not aware of the fields in the
x2many widget to returns, all the field in the x2m default form view are
returned.
This was merged in bbdf960 but introduced a number of other issue:
- in most situation the x2many is represented by a list view, which may
have fields missing of the form view, so the original is still present.
- the view used may differ from the default form view in other way
(depending on value in context or other possibilities).
- the form view could have fields not present in the form view which
could end up in `write` on fields which should not be written to.
---
This commit reverts bbdf960 and adapts a small part of #10557 so the
x2many with default view works as an embedded x2many. For more than one
level (eg. a x2many in a x2many) this would still not work but it is
only solvable by a PR such as #10557 which could only be targetted for
master.
With this commit:
- the list of fields sent to ORM onchange is computed at the first onchange
- the fields from a x2many field default view is sent for onchange
- the initial onchange on record creation is delayed to when x2many are loaded
closes#12249, closes#15336, closes#15890fixes#11236, fixes#12249, fixes#15129, #15419
opw-705965 opw-716095 opw-715619 opw-710440
Having more than one supplier invoice with the same reference is sometimes
possible. For instance, in Switzerland, the use of BVR/ESR numbers as a type of
reference permits this. Generally, this number is unique and used only for one
invoice. However, some suppliers do use the same BVR reference for several
invoices (e.g. recurring invoices).
This commit allows to disable this check if required, which is only possible
if it is extracted from 'invoice_validate'.
Closes#15891
A recurring event with a start date and a time duration had a wrong start and
stop date computed.
Introduced at 76b724294a.
Previously the r_date contained only the start_date but now it contains both
start and stop dates. This implies that the method 'get_recurrent_ids' could
use 'get_search_fields' with a stop_date (depending on the domain order) and
returns incorrect dates.
This commit ensure to launch the get_search_fields with the start date.
Closes#15922
Steps to reproduce:
-Create a new journal called VISA of type=bank
-Allow the reconciliation on debit and credit account
-Create two expenses (700$ each one)paid by company with the VISA journal
-Submit to manager, validate and post the entries
-Create a bank statement of -1400$ on Bank journal
-Click on reconcile button
Bug: the two account move lines linked to the expenses are not available
to be reconciled with the statement.
In 9.0, it was possible but due to this commit: 9188d01934
the two aml were not available because
this two aml had a payment_id, no statement_id and were with an account_id different of the bank journal
(not in reconciliation_aml_accounts) because they had been paid with VISA journal. So they were rejected
with the domain_reconciliation due to the account_id on VISA journal and they were rejected with the
domain_matching due to the payment_id not False and statement_id False.
In 9.0, they were accepted with the domain_matching so the same behavior has been done in saas-11.
opw:709861
- Define a user with accounting rights "Billing"
- Create an invoice or vendor bill
- Add an invoice line without product
It is impossible to save because the mandatory field "Account" is hidden
and empty.
This is because of an onchange which overrides the default method.
opw-716208
Richard Mathot