- 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
Commit 906875fc78 (followed by commit
76be5eed44) tried to tweak to copy/paste
functionality of the editor.
Indeed, in PDF file, when copying a paragraph, a line feed is added at
each forced line break (page width end). This forced a line feed and
a new paragraph in the pasted text. The goal was to get rid of those
useless linebreaks when pasting.
The ideal solution would be to detect that the text was copied from
a PDF but it is not possible. However, this commit improves the
heuristic: if this is not plain text, then nothing is done, the content
is pasted normally. If it is plain text (like when copying from pdf),
then each line break which is surrounded by letters or numbers is
considered an useless line break and replaced by a space. This is
obviously not perfect but the previous implementation was really wrong
(it was removing line breaks which were not preceeded by punctuation in
all cases, which was removing lots of useful line breaks).
Note: this commit also fixes a bug -> text was not able to be pasted
with Internet Explorer.
opw-715920
This commit partially reverts 5b4f7c1 where `fields_view.fields`
had been replaced by `fields`, which could have been set to all
fields in the model.
This modification can sometimes lead to a problem, during the
fields value transformation. The ID, which wasn't given previously
is now parsed. When creating a new record, the field ID is not an
integer but a string (representing the virtual ID). If the field
is in the arch, it will be postprocessed
(see https://github.com/odoo/odoo/blob/saas-11/addons/web/static/src/js/framework/data_manager.js#L201)
and its type will become `id`. As this postprocessing is not done
if the field in the view, the parsing was on the original type
(integer) and not the special id type.
This commit add some configuration menus to
avoid switching app to configure the POS.
It also add a new 'Catalog' menu to display
product, variants, and pricelists. Some labels
were renamed too.
The new menu structure looks like
Dashboard
Orders
Catalog
- Products
- Product Variants (if set)
- Pricelists (if set, only editable by pos managers)
- Loyalty Programs
Reporting
Configuration
- Settings
- Point of Sale
- Point of Sale
- Floor Plans
- Order Printers
- Barcode Nomenclatures
- Payment Methods
- Mercury Configuration
- Products
- Attributes
- Attribute Values
- PoS Categories
- Internal Categories
- Create an invoice with two products
- Each line has a long description (spread on 2 lines)
- The second line has a negative value
- Print the invoice (PDF)
The amount spreads on two lines, split as:
$ -
1,000.00
This is due to the wkhtmltopdf version with patched QT. Unfortunately,
upgrading to the latest version 0.12.4 doesn't solve the problem.
The solution is to replace the '-' by a non-breakable hyphen.
opw-711002
When using the iframed editor with multilang selector (present if there
is another lang installed than en_US) an "English" language was present
before each translation language.
opw-696891
1. A zoom is needed because the virtual viewport of wkhtml is bigger than
a A4 paper size. Hence we go over the size of the A4 paper with the zoom
and the content is then resized down to what we want.
2. There was also an issue for example with the title (outside the isr)
which had no margin so could be over the report header.
3. Tidy-up some comments in the ISR report
4. Use OCR-B font for optical reference if available
task-30535
Fullcalendar expect as `start` and `end` property of an event object:
> When specifying Event Objects for events or eventSources, you may
> specify a string in IETF format (ex: "Wed, 18 Oct 2009 13:00:00 EST"),
> a string in ISO8601 format (ex: "2009-11-05T13:15:30Z") or a UNIX
> timestamp.
(as seen in https://fullcalendar.io/docs1/event_data/Event_Object/)
Before this commit we could for example in arabic provide an invalid
date string "٢٠١٧-٠٣-١٦ ١٦:٠٠:٠٦" instead of "2017-03-16 16:00:06".
This commit solves this by always providing fullcalendar an ISO8601 date
string.
opw-705752
The transcoder (which transforms stylesheet rules to inline style) did
some compression of the padding and margin css properties to not always
have margin-top + margin-right + margin-bottom + margin-left.
This could cause an issue when the value of margin or padding contained
an initial or inherit value because browsers (at least firefox and
google chrome) doesn't allow it. Thus the preview could for example have
bigger veritcal spaces arround `<p />` tag than what was seen when
editing.
With this fix instead of invalid:
margin:initial initial initial initial
we have:
margin:initial
And instead of invalid:
margin:initial 5px 6px 7px
we have:
margin-top: initial; margin-right: 5px; margin-bottom: 6px; margin-left: 7px;
opw-706535
Nicolas Martinelli