In a spreadsheet with multiple data sources (2 pivots), each data source
initially loads and triggers a new evaluation upon loading.
This results in two evaluations, even if both data sources resolve in less
than 10ms apart. In such cases, the first re-evaluation becomes redundant,
as a new one is immediately triggered.
The issue is worse when more than 6 RPCs are required, as most browsers limit
network calls to 6 in parallel. Consequently, the 7th RPC will unnecessarily
wait after the evaluation triggered by the first RPC to resolve.
For spreadsheets with many many data sources, the accumulation of these
pointless evaluations significantly impacts performance.
In a real-life scenario with 18 data sources from our production database,
the spreadsheet took approximately ~33s to fully load and become reactive.
With this commit, the loading time is reduced to ~7s (only one evaluation
instead of 18) (tested in 17.0).
Note that this testing was conducted locally, with minimal latency, and with
a limited amount of data.
One consequence of this commit is that cells won't load incrementally as
each data source loads. Instead, all cells will display "Loading..." until
all data sources are loaded. Given the substantial speed improvement, we
consider this trade-off worthwhile.
This fix only impacts loadable datasources (pivot, lists, graphs),
it could also include data sources using individual RPCs (currency,
accounting). Maybe for master.
closesodoo/odoo#150015
X-original-commit: 70877d29cc2368298f8716f64c248a86ed0416ce
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps to reproduce:
- Install Accounting, Inventory, Sales and l10n_it_edi
- Switch to an Italian company (e.g. IT company)
- Create a storable product (e.g. Product X)
- Update its available quantity to more than 0
- Create a SO with Product X and confirm it
- Deliver the products
- Install l10n_it_stock_ddt
- From SO, create an invoice and confirm it
Issue:
When confirming the invoice, a traceback is raised:
"TypeError: 'bool' object is not subscriptable"
Cause:
When installing "l10n_it_stock_ddt", a new char field "l10n_it_ddt_number"
is added to "stock.picking" model, but its value is False for existing
pickings.
When generating the electronic invoice, "format_alphanumeric" is performed
on the field, assuming it has a string value.
opw-3661824
closesodoo/odoo#151262
X-original-commit: 67bbf31e57959631d98586f5a4d22f981b344066
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Kode transaksi is a required field on account moves.
This field is either set on the move itself, or is
taken from the partner.
It NEEDS to be set when invoicing, but customers
cannot provide this values by themselves when
registering for example. This would cause issues
with automatic subscriptions amongst other systems.
In order to fix this issue, we will define the code 01
as default value.
closesodoo/odoo#151265
X-original-commit: 846f7cc9a7dbec4f9c6631ae2ccd484f9af47dd8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Since the Bootstrap5 migration (odoo/odoo#95450), the reports' table cell were centered vertically.
This was due to the fact that the property "vertical-align" which was set on the table itself by BS5 doesn't play
nice in wkhtmltopdf, namely, it seems to not get inherited by the table's children.
This commit adapts the css by reproducing what was done in BS4 for tables.
After this commit, the table cells have their text aligned at the top by default.
opw-3670533
closesodoo/odoo#151186
X-original-commit: 1335bce8e45bab473486e87c8a430cbc6dde587b
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Previous commit is fixing the code so that a view without `en_US` in
arch_db jsonb value won't make the code crash (`get_related_views`).
The commit before that actually improved the custom snippets so the
translations are forwarded to it when it's saved.
But that new code was introducing a way to have an arch without `en_US`
value, which led to the bug described above.
While the previous commit fixed the consequence of the issue, this
commit solves the root cause of the issue, introduced 2 commits before.
Arguably, this commit could be squashed in the one 2 commits ago, but
it makes things more clear to figure.
task-3375518
closesodoo/odoo#150945
X-original-commit: bf598d9098b4be36542a9a91c0dd1055cf36aed5
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since commit [1], the lang was removed from the context by setting it to
None.
In Odoo 16 and since jsonb, it's not correct, the lang should simply be
popped from the context.
Indeed, having `lang=None` in the context will not return any value when
reading the arch if the arch has no `en_US` default value.
The previous commit will make it so the translations will be forwarded
to custom snippets when saving a snippet. With that commit, the issue
described above will be problematic and lead to a crash.
There is probably other legit ways to reproduce the issue which are not
yet found as we don't really use non english DB often.
Step to reproduce (following previous commit):
- Create a db with french only and install website.
- Then enable dutch and add it on the website as second lang
- Drop a title snippet & translate it in the dutch version
- Save and go back to the main lang (fr)
- Drag & drop again this newly saved snippet (custom snippet)
- Save and to to dutch version
- Enter translate mode
-> A traceback will be shown, because `get_related_views` will fail on
"empty etree document", because when in the stack doing
`etree.fromstring(view.arch)`, it will fail since arch = ''.
Step to reproduce (without the previous commit):
- Remove the `en_US` jsonb key from a view, eg
`update ir_ui_view set arch_db = (select arch_db - 'en_US' from ir_ui_view where id = 4) where id = 4;`
- Start odoo-bin in `shell` mode
- Do `self.env['ir.ui.view'].browse(4).arch` -> Will output the arch
- Do `self.env['ir.ui.view'].browse(4).with_context(lang=None).arch`
-> This will crash on record not found error.
[1]: https://github.com/odoo/odoo/commit/fdb9f8273be62d0a6d8051f7ca0a66cdf22ae5e7
task-3375518
X-original-commit: 9cb17bc9cb1490219d1488c99e419a84681ca121
Part-of: odoo/odoo#150945
This commit adds translation capability to custom snippets.
Before this commit, the custom snippet was not translate friendly:
1. Neither when saving a block as custom snippet
2. Neither when dropping a custom snippet into a page.
This was a known limitation for years. But now it's time to make it
work.
Step to reproduce (part 1):
- Enable french
- Drag & drop Title snippet in a page
- Translate the Title
- Save the block as custom snippet
-> Go in the backend view of this custom snippet, in debug, there is no
translation that followed the title.
Step to reproduce (part 2):
- Following previous steps, now add the translation manually on the
custom snippet view
- Back in a page in edit mode, drag & drop this custom snippet in the
page
- Switch to french
-> The title is not translated, the drag & drop copy code but no
translations
Those are the "page/view" to "page/view" translation transfer, but it
could also be any html field (like a product description) to view
(custom snippet) or view (custom snippet) to any html field.
task-3375518
opw-3242100
X-original-commit: 2bd6c1a8d653453692211eef0f5d46a0047eb6f2
Part-of: odoo/odoo#150945
There is the following problem when editing the tax amounts on an
invoice (in quick-edit mode or via the journal item):
The changed amounts are displayed correctly on the PDF but not in the
EDI XMLs (e.g. the embedded factur-x).
This commit corrects this.
Reproduce
1. Create a new invoice
2. In tab "Invoice Lines" add 2 lines with taxes from different tax group
3. Go to tab "Journal Items" and change the tax amounts
(or use quick-edit mode; needs to be enabled in the settings)
4. Go back to tab "Invoice Lines" and notice the tax amounts of the groups
were changed.
5. Generate a PDF: Here the tax amounts are correct (the changed amounts)
6. Look at the embedded XML: Here the tax amounts are
wrong (initial / unchanged amounts).
The same issue applies to multiple other EDI exports.
To activate the EDIs go to:
Accounting > Configuration > Journals > Customer Invoices
> Advanced Settings tab > Electronic Data Interchange
The EDIs can then be found as attachment in the chatter after confirming
and/or printing an invoice.
task-3535411
closesodoo/odoo#151090
X-original-commit: 5d456ce13970980efa8b1efab92323e995eaa848
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Problem: The test value for the expiration date was being shown on gift card reports that don't have expiration dates.
Purpose: The expiration date should only be shown if it's set for the gift card code.
It will be consistent with loyalty_report and the email template mail_template_gift_card in which both conditionally displays the expiration date.
Steps to Reproduce on Runbot:
1. Install Sales
2. Settings > Sales > Enable Discounts & loyalty programs
3. Navigate to Sales > Gift cards and create/generate a gift card code with no expiration date
4. Print the gift card report and the report will show the expiration date of 2023-12-31
opw-3686110
closesodoo/odoo#150954
Signed-off-by: Mylyna Hy (myhy) <myhy@odoo.com>
This bug was introduced from this commit 21ca976
This commit fixes it.
closesodoo/odoo#151067
X-original-commit: a3d1b5b22ec172ca194621ee6a8d577d05aac5d0
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
- Currently, once the SMS code has been created, it's valid forever,
which is not very secure. Verification codes should expire after some time
and users should have an opportunity to request a new one after
some time elapses instead of having to cancel the registration and retry.
- We've had several cases where users tried to register while having
an active registration somewhere else. In that case, we cannot register them
and we have to reach out to the user asking to deregister from the other service.
It is better to catch that instantly.
task-3677877
closesodoo/odoo#150970
X-original-commit: ee2064b9055f9abfcc82227cee033af0b0c7be48
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Commit [1] introduced a responsive font size feature was. Following
this, in the context of mass mailing, an issue arises when users select
a font size from the toolbar dropdown. Specifically, the
`_computePxByRem` function converts the `px` value selected by the user
to the wrong `rem` value. This is because it relies on the font size of
the `html` element of the main window's document rather than that of the
iframe's document. Since the iframe's document has a font size of 14px
where the main document has a font size of 16px, the conversion was
faulty. Also, the value was cached on the window object, which is common
to both documents. So this commit moves that cache to the document so
two different values can be stored.
[1]: https://github.com/odoo-dev/odoo/commit/ddf25a16c46bfc3628512aba1390a1e345ec719a
task-3653543
closesodoo/odoo#147685
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Co-authored-by: Vishal Padhiyar <visp@odoo.com>
Co-authored-by: Dieleman Guillaume <gdi@odoo.com>
Summary
-------
wkhtmltopdf's "smart shrink" option does not work properly with rtl
languages, unless the direction is specifically set on the body/html
tag.
Steps to reproduce
------------------
* install Accounting and the Saudi Arabia localization
* switch the Saudi Company
* language to Arabic
* print the General Ledger
You should see that a few columns do not appear on the PDF. They are out
of bounds.
Cause
-----
The "smart shrink" option in `wkhtmltopdf` is a feature designed to
automatically reduce the font size of text in order to fit content
within the specified page width. We use this option to help prevent
content from overflowing the designated page boundaries.
However, it seems that "smart shrink" doesn't take into account the text
direction unless it is set on the `body` or `html` tag specifically.
opw-3472357
opw-3567655
opw-3520084
closesodoo/odoo#151049
X-original-commit: 210a529b0b43fe36f7f2e44363dfe039128f7f80
Related: odoo/enterprise#55107
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
The utm parameters i.e. utm_source, utm_campaign, utm_medium, are only set
when a sale order is attached to an event registration. If no sale order is
generated the event registration won't have any source despite it being
accessed via a campaign.
Reproduction steps:
1. Create an event and copy its website link.
2. Go to link tracker and create a tracked link with utm values filled.
3. Use this tracked link in incognito preferably to register for the event.
4. Check the attendees of the event and check the marketing utm values.
The registration has no campaign. When it should have one.
This is because event.registration mistakenly does not inherit from
the utm mixin. The fix is to call the default_get of the mixin
as it is independant from any field defined in the mixin.
OPW-3222179
task-3458877
closesodoo/odoo#151047
X-original-commit: 06803bc12115ccb2afb7ea7b8dd101e3a75bfb67
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
This commit reverts an unwanted diff introduced by Commit[1].
Recently, Commit[1] introduced some wording changes within the portal
layout, which required an update of the `.pot` file.
While the terms where correctly updated, Commit[1] also removed a line
about the version of the project, which could cause some issue within
Transifex.
Commit[1]: 7aa06fd
closesodoo/odoo#151046
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit:
On clicking the saame paragraph while emojipicker is open, it doesnot close,
resulting in multiple emojipicker being opened at the same time.
After this commit:
Now onclick away from emojipicker on the same paragraph emojipicker closes.
task-3555717
closesodoo/odoo#151038
X-original-commit: be671cce046a72402d1746917b4b5b8715ba1d41
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Sanjay Sharma (shsa) <shsa@odoo.com>
This commit does 2 things:
- It prevents saving the parallax bg css properties which does not makes
sense as those properties are related to the current screen scroll
position. Each scroll position has its own css properties.
Saving those did no harm tho, as on start those were recomputed.
- It prevents flagging that parallax bg css properties change as a dirty
change by stopping the observer while changing those properties.
This is not really helping much apart from being right, since when
discarding, to know if something is dirty, it's not considering the
`o_dirty` class but doing some DOM comparison before/after, so:
- In this case, the css options are most likely still not the same,
see below "O_DIRTY EXPLANATIONS" for explanation about that part.
- There is still some stuff that will get in the way and make the
before/after DOM not the same:
- Scrolling a few px will hide the navbar and reveal the other one,
flagging it as a dom diff
- When having a few menu end entering edit mode, some will end up
in the "extra menu area" (grouped inside the "+" menu entry),
which will also be considered as dom diff
Step to reproduce:
- Enter edit mode and drag & drop a parallax snippet
- Update its "Parallax" sub-option from "Fixed" to "Bottom to Top"
- This option change adds some css properties to the `s_parallax_bg`:
top, bottom and transform. Each time you scroll, those are updated.
- Save and then inspect the source code of the page (CTRL-U)
- BUG 1: The `s_parallax_bg` was saved with those css properties set to
the values related to where the scroll was when saved.
- BUG 2: Now enter edit mode again and check that the `#wrap` is
automatically and directly set as `o_dirty`.
--------------------
O_DIRTY EXPLANATIONS:
- The "cancel" is comparing dom before and after edition to know if it
is dirty or not (and thus to know if it has to show that pending
changes modal)
- The "save", to know is something has changed and need to be saved, is
not doing that dom comparison
- Before this commit, the "o_dirty" class would be added when entering
edit mode, as the parallax would recompute its css top/bottom values,
which would differ from the ones saved in DB (because of the right
panel reducing the content size)
- Before this commit, on top of the "o_dirty" class, there would be the
top/bottom style diff too, as explained above
- After this commit, the o_dirty class is not added anymore
- After this commit, the top/bottom style is not saved in DB, but it's
added when the widget is started, meaning that there will also be a
DOM diff (before: no style, after: top/bottom style)
- On cancel, the snippets are not destroyed, meaning the style added on
the start of the parallax is not removed before considering the dom
diff
--------------------
Related PR about mitigating dirty issues: https://github.com/odoo/odoo/pull/144121
Related PR which should solve this kind of issues one day: https://github.com/odoo/odoo/pull/74923
opw-3672851
closesodoo/odoo#150994
X-original-commit: 4f8d8072a87ad0a67fbe5e61c5845d18c0e05d71
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Current behaviour before commit:
In v16.0 and above clear format button was missing from
snippet toolbar.
Desired behaviour after commit:
Now clear format button is getting appeared in snippet
toolbar.
task-3638147
closesodoo/odoo#150620
X-original-commit: 701bbe40554ea9b6867171a755124fe5b635988b
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Issue:
Main attachments on expense sheets was never correctly set, leading
to missing attachment previous in the hr.expense.sheet form view,
and unnecessary RPC requests to `register_main_attachment`, because
the attachment was never set.
Steps to reproduce:
- Install Expenses
- Create 2 different expenses with different attachments
- Create a report from those 2 expenses, save it
- Notice there is nothing in the preview for the attachments, but if
you zoom in or zoom out the page, then you can see it. Also
swiping on the list of attachments isn't persistent, once you
refresh the page, the main attachment we selected lastly is lost.
Cause:
There are 2 main issues:
- `hr.expense.sheet` has `message_main_attachment_id`, but it's
never set.
- When writing an attachment via `register_main_attachment`, we
pass only the id of the attachment. Then in the backend, the
related record is based on the model of the attachment, but the
attachment is linked to `hr.expense`, not `hr.expense.sheet`.
Therefor we re-write the same attachment on the record we read the
attachment from. And then the frontend will continue to call
`register_main_attachment` everytime it tries to find the
attachments linked to the sheet, but it's never done.
Fix:
- Add a compute to initially set the value of the
`message_main_attachment_id` based on the spec "we take the first
line that has a main attachment (attachment if no main attachment)
and we set it on the sheet"
- The `hr.expense.sheet` now maintains a copies of the attachments
linked to it's expenses, for proper ACL and functionality of
`register_main_attachment`.
Affected versions:
16.0 up to master = saas-17.1
Reference:
task-3572440
closesodoo/odoo#150501
X-original-commit: 2e02a05838ab62e48c65ba90980bd9e21b677019
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Versions
--------
- 17.0+
Steps
-----
1. Go to Employees app as admin;
2. clear the "Working Hours" field & save;
3. go to Time Off app.
Issue
-----
Odoo Server Error.
Cause
-----
Commit 8f87e102a9 added the
`_get_consumed_leaves` method to `hr.employee`, which calls on
`resource.calendar` methods with `ensure_one()` active. The
`resource_calendar_id` is not a required field for employees, so an
error occurs when these methods are called on an empty record.
Solution
--------
Default to `company_id.resource_calendar_id` where a calendar is
expected.
Also fixes a potential issue in `hr_contract` when getting attendances
between a time interval that includes multiple contracts using different
calendars.
opw-3665412
closesodoo/odoo#149908
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Before this commit, if the user tried to settle a sale order
in PoS restaurant, then went back to floor and then returned
to the table, the sale order reference will disappear.
The problem is that the `sale_order_origin_id` is not loaded.
opw-3550351
closesodoo/odoo#149262
X-original-commit: 13db10c1c73418ce4eabc52ef2415a1f27f1e24e
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Instead of changing the type of lists to make an ormcache that works,
we'v extracted the function that call the server apps.odoo.com to pass
it the payload in json (as it will be sent to the server), and use the
payload value as ormcache
closesodoo/odoo#149015
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Issue:
For the Chilean localisation of POS, all orders generates the pdf of the invoices,
sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs)
Cause:
A wkhtmltopdf bottleneck, since odoo/odoo@19916059c5
we "Send and Print" the newly created invoices, which generates the pdf.
Some localizations have this as a requirement, but Chili apparently is not one of them.
Fix:
There are 2 types of invoices (boleta/factura), but the POS button "to_invoice" at order
checkout was used as a toggle between the types of invoices,
instead of a choice to invoice or not. And since the generation of the invoice is strongly coupled
with the generation of the pdf, I've added a context key to skip the pdf generation during POS checkout.
The user can still "Send & Print" the invoice from the backend.
The key is present when we *don't* select the invoice option at checkout (so for boleta invoices),
for factura the invoice's pdf is created in sync.
Affected versions:
17.0 up to master
Reference:
opw-3610333
closesodoo/odoo#148159
Related: odoo/enterprise#53655
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Prior to this commit, there was no `title` attributes in the accordions
of the filters.
They are also added in the `website_event.pot` file
task-3626957
closesodoo/odoo#145064
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Prior to this commit, the design of all the `off-canvas filters` was wrong.
It was `list-group` with a `dropdown-item` class on the elements inside.
Also there was a wrong `border-top` class on the `accordion button`,
causing display issues on `hover.
`Aria-control` was also missing from the `categories filters`.
Checkboxes and radio buttons are also added to increases the usability.
task-3626957
Part-of: odoo/odoo#145064
Prior to this commit, the position of the `<li>` and `t-foreach` was not
correct.
They needed to be swapped, because we had single `<li>` with multiples
`<a>` inside, instead of multiples `<li>` with a single `<a>`.
task-3626957
Part-of: odoo/odoo#145064
Prior to this commit, the `countries` filter was not appearing in the
off-canvas filters on mobile.
The `date` filter was also appearing all the time in the off-canvas, even
when it was not supposed to.
task-3626957
Part-of: odoo/odoo#145064
Prior to this commit, the `countries dropdown` filter was still a `li`
on desktop.
The spacing between the `dropdowns` was also wrong.
The `countries filter` was showing after the `searchbar`, so the template
position is modified.
`is_active` value is set to ease classes conditions on the dropdowns links.
task-3626957
Part-of: odoo/odoo#145064
After https://github.com/odoo/odoo/pull/109736, we started rendering all day
events in the all day slot. However, some calendar views don't have an all day
slot, so these events weren't being shown. Therefore, this commit adds an all
day slot to the hr_holidays module to show multiple day events. Therefore, we
add a new last_several_days computed field in hr leave.
task-3566710
closesodoo/odoo#150980
X-original-commit: cdd8b2fb6b5b3c6a7b1d163368eef791d3d14b3a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this PR, a race condition could occur when restarting the
chatbot: if the rpc returned before the restart message reception
on the bus, the chat would not restart. This was due to the message
being inserted twice. Since the id is used as an unique `t-key` in
the thread template, any duplicate would lead to an error.
This PR fixes the issue by checking that the message is not already
present before adding it to the thread messages.
Steps to reproduce the issue:
- Go to the contact us page
- Start a chat with the bot and proceed until the end
- Put your network in slow 3g mode
- Click on the restart button
- The chatbot is not restarting as expected
closesodoo/odoo#150975
X-original-commit: 6c535bb71edc40aaf3fa75bab702fb9be4a24779
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Steps to Reproduce:
- Activate packaging
- Create a storable product update on hand qty 1 package: "PACK6"
- Create a sale order with the product qty 1
- Confirm the order, picking will have a package already assigned
- Edit the sale order and set the product quantity to 0
Bug:
a new move will be created with negtaive quantity and merged with original
(correct behaviour)
but when the picking is confirmed an extra move will be created due to the
picking still having a package level set
Fix:
unlink the package level when its last linked SML is unlinked
opw-3597188
closesodoo/odoo#150939
X-original-commit: 4983923973bacbff84d67cdd442d4b6985f33577
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
- open project updates of any project by clicking three dots
- add some update of project
- switch to mobile view
Issues:
- in kanban cards of project update, no spaces between progress bar and date
Solution:
- add some space between progress bar and date to have better experience
Task:3633405
closesodoo/odoo#145774
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
If the user selects a branch and deactivates the parent company, he
will not be able to create any LC.
Explanations: Since the company field is a related one that targets
the company of the journal, and since the journal belongs to the parent
company, the LC created in the branch actually belongs to the parent
company, which triggers an access error.
Asking users to create branch-specific journals would just cancel
all the benefits of the company branch feature.
OPW-3651022
closesodoo/odoo#150972
X-original-commit: 915b2e2b8401db937db4162e32e84cf968728072
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
For the indian case, when facing two percent price-included taxes having the same percentage,
both need to produce the same tax amounts.
task_id: 3410529
closesodoo/odoo#150971
X-original-commit: 235347db954495b8c0a1bf3bfd0cd408aec7ef0f
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce:
- Create the following subkits boms
F-> SK1 -> A
-> B
SK2 -> C
-> D
- Set all these products to be available in pos and have AVCO automated
valuation with A,B,C and D having a cost of 5$
- Sell F in pos creaing an invoice
- In accounting check the expense account (cost of goods) wrong cost
Bug:
´comp[1]['product']´ referrs to the kit product of the last children boms
(SK1 and SK2 in this case) which would then each be counted twice
instead use ´comp[0].product_id´ (the components of the child boms)
also fixed total_cost computation for pos lines which would filter out
all the subkits moves
opw-3538285
closesodoo/odoo#150937
X-original-commit: d6a513355ee0ae4b02e38baacdde760cc35fb873
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
- install timesheets module
- install all related timesheets bridge modules
- open timesheets module
- click on configuration
- click on settings
- under the timeoff, create a new project and click on create and edit
Issue:
- the current company is not set by default on the newly created record
Cause:
- the project id did not have any default company id attribute
Solution:
- if we gave a default attribute to the project id field then the issue
will be solved
task-3607053
closesodoo/odoo#150675
X-original-commit: 61a6ad35280dcca0e03dc0ca7ad3923ae1a12027
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
How to reproduce:
- Create a new quotation.
- Add a product 'Event Booth'.
- Select an Event, and select any available booth category.
- From the available booths, select some of them.
- Click 'Ok' and manually save the quotation.
- Now, edit the same SO line, and select 'Event Booth' again(similar or different).
- Confirm the SO.
Before this commit:
Users can now see the incorrect total event booth count as 'Booths' on the
stat-button.
Issue:
While editing the booths in the configurator, the new selection does not get
updated in the 'event_booth_registration' table.
After this commit:
The records in the 'event_booth_registration' table are updated with the user
selection of event booths. Users can now see the correct event booth count in
the stat-button.
Task-3309218
closesodoo/odoo#150974
X-original-commit: 1b077436fcb09d9a8cbf3d81e9978b696900924e
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
issue:
- calendar mobile view (month) > pressing on a day or timeframe to create a task doesn't work
if the view does not have the "day" calendar scale set up
Fix:
- We are removing the condition preventing the renderer to use the createRecord callback when
the view is Mobile and in monthly scale
So now a record will be directly created when a user clicks on a timeframe in monthly view even
if he's in mobile view
Task-3677216
closesodoo/odoo#150624
X-original-commit: da23aa3d68e0f8b833d085c09bcf81d8aa2a4285
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since [1] `model.clear_cache` is no longer recommended.
Most models were changed besides the function responsible
for regenerating asset bundles. This leads to a deprecation warning
when pressing the button in the debug menu in 16.4+
1: #119813
opw-3694331
closesodoo/odoo#150948
X-original-commit: ef0db39416c678a3a3e53ddb97971f87e912f44c
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Andrew Gavgavian (andg) <andg@odoo.com>
When a 'scheduled_date' is given to posting API notifications are delayed.
They are send using a cron running on a schedule model. However SMS are
not respecting this parameter. This is now fixed.
We also use sql.now() instead of datetime.now() when checking notification
delay. This leads to values that are consistent through the transaction
and avoid non deterministic behavior.
This leads to fixing a global mock of "cr.now" that has unexpected side
effects in composer tests. Indeed now that the scheduled notification checks
cursor now instead of datetime now this global mock leads to some notification
not being sent. We now mock cr.now() only for creating records, allowing
to effectively test templates using create_date for dynamic scheduled date
computation.
closesodoo/odoo#150911
Related: odoo/enterprise#55052
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since 1be6866b15, when VAT can't be
edited, the country_id select field is disabled.
Disabled fields aren't submitted in the POST query, which causes an
error `Some required fields are empty`, with the Country field being
highlighted even if a value is selected.
With this commit, when the user cannot edit their country, the value is
forced into the POST data so that it is found.
closesodoo/odoo#150909
Signed-off-by: Paul Morelle (pmo) <pmo@odoo.com>
Before this commit, the cropper tool was opened by a closure that spawned the Cropper
tool aside from the editable document.
This was anoying as the editable document can be in an iframe, hence the Cropper would have
been virtually unusable.
This commit factorizes the code in a method to allow overrides. Which is done in
web_studio:ReportEditorWysiwyg.
opw-3484065
closesodoo/odoo#150904
Related: odoo/enterprise#55049
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
To load images in an iframe, the web_editor code expected the iframe to have an src
attribute and built an URL for the image on the basis of that url.
With the srcdoc attribute, there is no need for an src, making the code crash.
After this commit, if an iframe only has srcdoc, we build images' url on the basis of
the main window.
opw-3484065
Part-of: odoo/odoo#150904
Before this commit, the image processing code always added a listener on the load event
of an image before opening the Cropper tool.
If the image was already loaded, the promise did not resolve at all.
After this commit, an image can be already loaded without any Promise not to be resolved.
Part-of: odoo/odoo#150904
Before this commit, the Picking Operation report's texts were small and the layout
was somewhat odd.
This was because of [1]:
- an oe_structure div was added in a bootstrap row that was already filled (all bootstrap cols were used)
This did not play nice in wkhtmltopdf and made the texts size very small.
- a scalar t-field add a default content which was rendered if the field's value was False
(which can happen when the field is unset)
opw-3668900
[1]:567b8d676b3b6dc747df4d9bf10e7a91b4cb61bb
closesodoo/odoo#150905
X-original-commit: 2a511bc5cd105e2e59d797886efa192bb821f6aa
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Lucas Lefèvre (lul)