When opening the calendar view in, for example, the timesheets app, the first
day of the week used for the number calculation is provided by the localization
service, which in turn requests it from the database. Because the first day of
the week is stored as a number between 1 and 7 in the res.lang model and a
value between 0 and 6 is expected by the DateEnv, offset errors can occur.
The error is fixed in various components (for example, the CalendarDatePicker
and CalendarCommonRenderer) but not in others (CalendarYearRenderer). Instead
of patching each component separately, a better solution is to require the
CalendarModel to expose a 0 to 6 firstDayOfWeek value as part of its public
interface.
opw-3389617
closesodoo/odoo#142056
X-original-commit: aea22a46515304df41dfaf427f5955824fe342f5
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
When performing a manual stock revaluation, the value difference is distributed
equally among the available stock. This method breaks down however in case of a
devaluation where some items in stock are already valued less than the unit
cost difference: this results in a negative value.
This commit will prevent such devaluations by raising a UserError whenever the
remaining value of a stock.valuation.layer becomes negative. Additionally, after
a revaluation, the standard_price field will now also be updated for fifo valued
products.
opw-3340298
closesodoo/odoo#143437
X-original-commit: a6db4b48f1d32f1020ee3ad242c77211aa10b3b2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The safeConvert function in the useDateTimePicker hook will call parseDate with
an undefined format when no format option was provided to the hook. Before this
commit, since the options object passed to parseDate still contained the format
property, the undefined format will also be passed on to the parseDateTime
function. This is problematic, because now the parser will use the default
datetime format, and it will fail because of the absence of a time value in the
input string.
For some input formats, parseDateTime will still yield the correct result using
one of its backup parsing methods. However, a wrong result will be returned for
date formats containing some textual parts (for example MMM/dd/yyyy).
Making sure no undefined format values are passed on in the parseDate function
resolves the problem.
opw-3478797
closesodoo/odoo#136221
X-original-commit: b04482ed87db05b3fc2523a08ce7ca5818af578b
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
Switch to using scss variables instead of hardcoded colors to support dark mode
in field selector popover.
Steps to reproduce:
Turn on Dark mode. Open Automated actions and add a model. Edit domain and
start typing: text is white on white, the popover does not adapt to dark mode.
opw-3453065
closesodoo/odoo#134458
X-original-commit: 5a57bd799688ee7a2c2e29d775fda73bba34c777
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
When using a list view for an x2many field in a form view, the parent node
containing the list view will adapt its size to its contents. This can be a
problem for the list renderer as it calculates the allowed total table width
from the width of the parent node.
To resolve the issue we make sure the table does not cause any overflows at the
moment the allowed width is computed, just before the calculation of the column
widths.
Steps to reproduce:
Go to Inventory > Inventory Adjustments > Select a product from a line
In the many2many additional_product_tag_ids add a tag with a name longer than
the width of the column. Now all the labels in the column are broken (they will
wrap after every character).
opw-3358116
closesodoo/odoo#132759
X-original-commit: 1fa97b5a814ca678b831ef0545fd5a24f577c979
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
The _compute_amount_residual method computes residual amounts on reconcilable
account move lines. As it uses an sql query for an efficient computation it
discerns stored records from new records (having a new id) by filtering out
records with a falsy id field (new ids are always falsy). It then proceeds the
computation for stored records only.
The bug arises when the compute method is called on records during an onchange
call, as the records get reassigned a new id as well. This can be seen when
opening the total due followup view and toggling the blocked field on any of
the unreconciled entries. The problem is resolved by including records during
an onchange in the computation: in practice the computation can simply be
carried out on all _origin records.
opw-3388389
closesodoo/odoo#131465
X-original-commit: 3d52fca2979cc4bfe87540122ea7cc979040be4f
Related: odoo/enterprise#45591
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
Identifiers (including column names) that are not double-quoted are folded to
lowercase in PostgreSQL. Before this commit, this resulted in errors when
updating translations for translatable fields, because the query did not
correctly quote all identifiers.
opw-3287428
closesodoo/odoo#125641
X-original-commit: 70ae8de223fc10f6e80dae06b0f6a6f15c198b5f
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
The autocomplete component intercepts certain key presses allowing the end-user
to select an option from the autocomplete dropdown using either the enter or
tab keys. Before this commit those keypresses where only intercepted when the
autcomplete selection list was already completely loaded.
Consider now for example an x2many list where the lines can be selected using
the autocomplete component. To add a line to the list the end-user will usually
type part of the record name and then select it with tab or enter. Three things
can happen:
* The enter keypress is handled after the list of options is fully loaded
* The enter keypress is handled while waiting for the list of options to load
* The enter keypress is handled while still debouncing the input, no request
to load the options has been made so far
The last two cases commonly occur when inputting lines with a barcode scanner
for example. In this case the enter keypress is ignored by the autocomplete
component and is instead handled by the list renderer component. This generally
results in the list renderer trying to create a new line but failing because
of missing required fields in the previous line. This seems more or less
acceptable. However, if required fields are already filled out or not present
in the list view, a new line is created while the current one remains empty.
This behavior is clearly counterintuitive, as such, this commit proposes to
wait for handling tab and enter keypresses while debouncing the input or
loading the list of options.
opw-3235288
closesodoo/odoo#125464
X-original-commit: 7776e89e293045731e077801113d4ff40507b7c1
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Use the many2one_barcode widget for the product field in the account.move.line
list view, similar to the sales order and purchase order views.
X-original-commit: c8918e799b23bd4e57a63f354731be78d308b97b
Part-of: odoo/odoo#125464
As of this commit, only confirmed leaves will be considered when computing the
current leave or absence of an employee. Additionally, a bug in the is_absent
search implementation was fixed: before this commit, the same results were
returned for absent and non-absent searches.
opw-2877328
closesodoo/odoo#124968
X-original-commit: 28ccbbab07a0c25570ca9b940428b8e541d262d7
Signed-off-by: Kevin Baptiste <kba@odoo.com>
After uninstalling the stock module on a database which also has the purchase
(and purchase_stock) module installed, the qty_received_method is removed for
purchase order lines handling the reception of the products through the stock
module (qty_received_method = 'stock_moves'). Because of this, a recompute
is triggered on the qty_received, setting it to zero.
This leaves the purchase order in an invalid state (the received quantity did
not change through the uninstallation of the stock module), additionally the
problem cannot be corrected, since the receiving method is not set to manual.
Functionally, the uninstallation shouldn't update the purchase orders, instead
they should be decoupled from the associated stock moves. To this end, an
ondelete handler is added for the stock_moves selection option.
Steps to reproduce:
- Install Purchases app
- Install Inventory app
- Create a purchase order with purchase lines and quantity > 0
- Confirm the purchase order
- Click on receive products
- Click on validate
- Uninstall Inventory app
- Check that the purchase order lines have the received field set to zero and
it is not editable
opw-3006951
closesodoo/odoo#121549
X-original-commit: cedd0603a24aa0c0e6716c2e0f49e89c870eae04
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Co-authored-by: Pedro Manuel Calheiros Lima de Sousa (peso) <peso@odoo.com>
*: web_editor
The table of contents menu entries are generated automatically which
poses a problem in translation mode. The menu translation entries
are not be editable separately, but the users might be trying to.
This commit shows a notification when the user clicks on the menu
entries while in translation mode, explaining that they are generated
from the title entries.
It was initially intended to use a tooltip - but the amount of code
needed to display a tooltip without marking the DOM as modified is
needlessly complex.
To avoid that styles applied on a plain text during translation were
also appearing in the navigation menu, an attempt at adding a span
around them to make sure that their translation was distinct from the
one inside the main content. But this led to the risk of losing
existing translations.
Because of this, and because that situation seems unlikely, any
remaining style in the navigation menu is instead stripped when the
table of content is started to maintain consistency with what is shown
during translation.
An `o_translation_without_style` class has been introduced to indicate
to the synchronization mechanism that only the text must be replicated
for those elements.
For labels that have a different `data-oe-translation-initial-sha` than
their related header, that value is temporarily kept in another
variable, the value is replaced by the one from the header, which make
the synchronization mechanism properly associate them, then on save
the initial value is restored so that the translation is saved for the
right slot.
task-2752391
closesodoo/odoo#116270
X-original-commit: 5776a358e1b42186d2c26c9bc25010a12811f416
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
The current domain on the forum post child_ids field is not guaranteed to work
since it requires the recordset on which it is applied to be a singleton.
closesodoo/odoo#109596
X-original-commit: d9983167a7c534a08854ad5327e36a8343ef1e5d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When creating an employee with an associated user, the work email of the
employee is copied from the user (or actually the partner associated with the
user).
However since this [commit], both the mobile_phone and work_email fields on the
employee are computed fields based on a linked partner in the work_contact_id
field. This partner is created on the fly if it did not previously exist.
Both of these behaviors interact in such a way, that the linked partner of the
employee is created automatically using the email from the linked partner of
the user. This is a bug, since both linked partners of the employee and the
user should be the same.
The bug is easily resolved by adding the work_contact_id field directly to the
values dict for the creation of the employee (instead of the work_email).
Reproduction steps: the bug can be easily triggered by repeatedly installing
and uninstalling the employees app. An extra partner gets created for each
employee in the master or demo data, after each install/uninstall cycle.
[commit]: https://github.com/odoo/odoo/commit/3c6060b7bbe9c67aca8073ef43c1e89fb7e820ca
opw-3031187
closesodoo/odoo#108045
X-original-commit: 35b7e0e128f1cfd72c11ebb16d68bc48fdcbdb57
Related: odoo/enterprise#35004
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The tests in the purchase_stock module include some tests that make sure or
depend on the fact that the price_unit from the generated move lines equals the
price_unit from the purchase order line from which they were created.
However, the price_unit in the move lines exclude taxes (at least those that
have an account set, it uses the total_void computed from the purchase order
line). This means some tests will fail if an installed localization defines
taxes that are included in the price.
The problem is resolved by explicitly creating the test product used in those
tests without supplier taxes.
opw-3033340
closesodoo/odoo#104825
X-original-commit: 70f7e2d70d04df989d3ff8039d3bae7ebdb73a6b
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Unlinking a model during uninstallation can potentially fail when the query
removing any related mail activity types fails. This happens when such a record
is still referenced in the mail_activity table. Explicitly removing related
mail activities (as is done for the activity types and other related mail data)
resolves the issue.
Two tests are added, one that demonstrates the general flow and a regression
test triggering the behavior that caused a bug in the uninstall procedure of
the hr_holidays module.
closesodoo/odoo#104152
X-original-commit: b315f7f562fc84a09d99d6e7676567eb6f285402
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
The changes introduced by [commit 1] broke the getSelectedVariantValues method
when using the optional products modal with a preconfigured variant. When the
variant is preconfigured, the variant selection form is not rendered. As a
consequence the VariantMixin fails to retrieve the combination used when
calling getSelectedVariantValues.
In v14 this problem was solved by including an element in the DOM containing
the attribute value ids in one of its data attributes. Restoring this element
and the associated logic for retrieving it solves the problem.
[commit 1]: https://github.com/odoo/odoo/commit/2b832269f474d9b08c7c6cd827e5f78ebcfafeca
opw-2722176
closesodoo/odoo#101843
X-original-commit: 2959641fcee0c599162ed6b1dfc8efebd0c9211c
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
The cache currectly fails to correctly invalidate relational fields that depend
on a non-relational field. Two passes of invalidation are done, to reflect
dependencies on both the old and the new written values. In the first pass
only relational fields are considered, as explained in the comments:
> It is best explained with a simple example: consider two sales orders SO1 and
SO2. The computed total amount on sales orders indirectly depends on the
many2one field 'order_id' linking lines to their sales order. Now consider the
following code:
>
> line = so1.line_ids[0] # pick a line from SO1
> line.order_id = so2 # move the line to SO2
>
> In this situation, the total amount must be recomputed on *both* sales order:
the line's order before the modification, and the line's order after the
modification.
The written values can be seen as the roots of a dependency forest (a
collection of dependency trees). Before this commit all non-relational roots
and their corresponding trees were filtered out during the first pass. However,
this approach is wrong, as relational fields can also depend on non-relational
fields. Instead, the complete dependency forest has to be traversed, skipping
invalidation for non-relational fields during the first pass.
The test that was previously included accidentally succeeded because of a
separate and unrelated bug in the orm domain parser: in certain one2many or
many2many leafs the domain parser would not take into consideration the domain
included in the definition of the field. As a result, the test still passed
by accident, because the records that no longer matched the domain after the
write were still invalidated during the second pass.
The problem can clearly be demonstrated, however, when the dependency is
generated by a compute function.
closesodoo/odoo#101038
X-original-commit: d4a5827b42d80f0f830455dcd2056701eb09aed1
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Allow the user to select multiple languages in the website creation modal.
task-2745347
closesodoo/odoo#86541
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website
Setting transformations on images is handled by the jQuery transfo
plugin. This plugin, however, also manipulates animations related css
properties allowing the plugin to work on animated images.
After closing the transformation tools these properties stay in the DOM,
preventing the animation options to work properly. Animations are not
played when previewing or selecting a choice from the dropdown list.
Instead they remain stuck in their initial keyframe.
To avoid complications from the interaction between both options, this
commit hides either option when the other is activated. Additionally,
css properties added by the transform option are cleaned, avoiding
potential interactions after the transform option is reset again.
opw-2765529
closesodoo/odoo#97137
X-original-commit: 3ac59a7f841b528a32c14a2111e7a1a7e11c830a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
The autoplay option for youtube videos in a .media_iframe_video snippet
does not currently work on mobile devices. This happens because the
autoplay param in the url is only considered for desktop devices.
Mobile autoplay can be forced by using the youtube js api, in the same
way as it is already done for background videos. Therefore, the common
code is extracted into a mixin, extended by both widgets.
opw-2607308
closesodoo/odoo#89439
X-original-commit: 83972aa28957414d53c69bb41ce36646891a829e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
When selecting a quotation template for a quotation all the template lines are
copied into the quotation. However, the sequence field is omitted when adding
the lines. As a result all quotation lines have, by default, the same sequence
number.
This should not be a problem, since the lines are still shown in order in the
frontend quotation view. Once the lines are shown, the user can freely reorder
the lines, while the frontend takes care of reordering the sequence numbers.
However, there is an interaction with an existing problem in One2Many and
Many2Many fields. When these fields are paginated a sequence update will only
update the sequence numbers on the first page. This means that, before this
commit, when we move around a line on the first page, all the lines on the
second page will be inserted at the second position on the first page (because
of the way _onResequenceRecords is implemented).
This commit does include the sequence number in the copied quotation lines,
resolving the problem described above.
Note: It is still possible to insert new lines in the first page, extending
the sequence numbers at the end of the page. Since the sequence numbers on the
second page still remain the same, there are now lines on the first and second
page having the same sequence numbers, resulting in a similar bug.
opw-2730746
closesodoo/odoo#89344
X-original-commit: 6f11060d6afd9edce904dd34a2d415a2a2461108
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
SVG images are considered an xml like format, as a consequence restrictions
apply for manipulating svg type attachments. This poses a problem when a
website designer tries to save a page containing images with svg shapes. This
commit allows writing attachments with an xml like mimetype to anyone with
write access rights on views.
opw-2806930
closesodoo/odoo#89185
X-original-commit: d5aa54ca108eb99c7eb855a7d456bfe2f208a8eb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit e834173314f00e36cb3a1f99690d9f220584682c fixed an issue where editable
elements could not be removed if they were nested in a non-editable element,
because the editor considered them to be an editable root.
However, the same logic also applied when doing a history step after adding
such an element. Adding a nested editable element would make the history step
invalid and result in a rollback.
Such a situation can be encountered when adding a recaptcha legal notice to a
website form. The footer of the form is a non-editable paet of the document,
however the legal notice can still be updated by the user. This commit adds a
separate test for the addition of such editable elements that were previously
considered unremovable.
opw-2723017
closesodoo/odoo#88733
X-original-commit: f693e8ed27f753a728d903dfe4d7d10ae1334526
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
A mechanism is provided by the OdooEditor to circumvent certain problems while
editing links. More specifically, editable zones are patched when editing a
link. This avoids the cursor ending up outside the link whenever the link tag
is emptied.
However, the mechanism does not check if the link is also in the editable zone
before doing so. In translation mode, the editable zones correspond to the
individual translation strings. When translating link texts, this means the
anchor tag containing the translation string is outside the editable zone. The
patching mechanism still applies, resulting in the anchor tag becoming editable
as well.
This causes problems while translating links, for example oDeleteBackward
commands are being rolled back. Checking if the anchor tag is inside the
editable zone resolves the problem.
opw-2780312
closesodoo/odoo#88674
X-original-commit: 99050b26446bbbe949e1fa797210c2a8a68d94cd
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The website_forum_share_templates does not exclusively contain templates
to the forum share widget since the addition of the toolbar template.
Renaming the file to public_templates arguably makes more sense.
task-2749467
closesodoo/odoo#85998
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
An extra xml dependency was inadvertently added in the ForumCreateDialog in
commit [1] by inheriting the web_editor.toolbar template, since the file where
it is inherited is an xml dependency of the ForumCreateDialog widget. While the
dependency is correctly loaded in the public widget it is not in the creation
dialog widget, resulting in a crash.
Furthermore, the ForumCreateDialog widget does not actually need this template
and neither does the public widget need the other templates already present
in the same file at the time of the mentioned commit. Moving the extended
toolbar template to the website_forum_share_templates file, allows for removing
of the unnecessary dependencies. This includes the missing dependency of the
ForumCreateDialog, preventing the crash.
[1]: 740168ce8d
task-2749467
X-original-commit: 4ad966de67278c2081c1896c354b9b1782cf6dc1
Part-of: odoo/odoo#85998
When running test tours logging a message to console.error causes the
test tour to fail. Only one such message can cause the tour to fail, if
other message are written on the console they are simply logged in the
odoo logs. The offending message, however, is only shown at the end of
run, as part of the failing test logs. Arguably, it is better to
include it in the browser logs as well.
closesodoo/odoo#75197
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When editing a countdown with a redirect action, sometimes the
countdown block will be hidden when toggling the "Hide countdown at the
end" option.
The problem is caused by the button that allows previewing
and editing the end message of the countdown, this button does not
apply in the case of a redirect action though. However, the button can
still be activated by selecting a different end action first and
switching to the redirect action afterwards, in which case it will
incorrectly hide the countdown.
task-2638366
closesodoo/odoo#81557
X-original-commit: 7f6ebee33e8a82d7ccdf155c3a543898b187389c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The countdown snippet has an end action that can be configured to show a
message when the countdown reaches zero. A button in the editor toggles
a preview of this message. However, a bug currently makes the preview
disappear whenever the snippet's widget is restarted... which occurs by
simply hovering some other options.
To solve the problem, the preview visibility is now controlled by a
separate css class s_countdown_enable_preview overriding d-none. This
way, the preview visibility no longer interacts with the widget's logic
and is no longer affected by the widget restarting.
task-2638366
X-original-commit: c37354d457f5b868673b4f974e401f4c635062d2
Part-of: odoo/odoo#81557
Co-authored-by: qsm-odoo <qsm@odoo.com>
It is not always immediately clear to the end user that changing the
pricelist on a partner will not change the pricelist for any open carts
related to this partner. To clarify, this commit introduces a warning
message, indicating that the end user should change the pricelists of
these open carts manually if this is the desired effect.
Any open carts that already have the same pricelist as the new partner
pricelist are excluded from the search and will not trigger the warning
message.
task-2635067
closesodoo/odoo#77298
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
A bug currently makes the carousel snippet collapse/disappear when its
active contents are removed. This happens because after the removal,
the carousel no longer has an active item.
The solution that was chosen was to not allow the removal of slides
unless using the dedicated option which is there for that. This solution
has the advantage to also allow users to create empty slides (using a
background image for example) by simply removing the columns inside.
Note: Newly created carousels will include the oe_unremovable class on
their slides. As such they will no longer depend on isEmptyAndRemovable
checking them for having a carousel-item class on the parent.
task-2506165
closesodoo/odoo#79892
X-original-commit: 0cf36a227e7b90fb64b1bc8024de813894d10d14
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When visiting a page with enable_editor set to true, the web editor
will be automatically started. However, while the editor is loading,
the end user can still click other buttons in the navbar.
For example, some changes in the web editor require a save and reload
of the current page being edited. After saving, the same page will be
reloaded with enable_editor.
This commit blocks any clicks while the editor is being loaded.
task-2607755
closesodoo/odoo#78721
X-original-commit: 89bdfcd16828e1432900ea46118fd6ddadf96f2d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The idea of a text edit step is considered clearly communicated to the
end user from the moment the trigger is clicked ( as opposed to the
step waiting for actual input from the end user). This way an end user
can finish the tour faster without actually having prepared custom text
content yet.
task-2580338
closesodoo/odoo#77720
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Some themes replace the website.template_header_default template in the
website layout. This poses a problem when changing to another theme
afterwards because of the interaction between the website templates and
the _reset_default_config method:
1) Since version 15.0 the nav tag inside the header templates was
abstracted into a separate template (website.navbar) and added to each
header layout through t-call.
2) The _reset_default_config deactivates or reactivates views that were
enabled or disabled by the currently active theme. However, when doing
so, the default header is activated before the custom header is
deactivated.
As a consequence, after toggling the default header, there are
temporarily two header extensions in the website.layout template. They
both replace the //header//nav element. Because of the abstraction of
the nav element into a separate template by the header extensions, only
the first replacement will work.
task-2662497
closesodoo/odoo#77917
X-original-commit: b83a2110fd3035cc8466c4fa74f6530be5d00597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A bug currently prevents opening the editor from a translated version
of the homepage, for example /nl_BE (it works for other paths though).
Before this commit the url computed by _goToMasterPage was:
/website/lang/default?r=/nl_BE?enable_editor=1&rde=2
which will first redirect to the default language and then again to the
translated version. The bug was introduced by commit
119d9437e0 which chose an url without a
trailing slash as the canonical one for the homepage.
However, the bug can already be reproduced in 13.0 since commit
269aa59411 if the user manually
navigates to /nl_BE instead of /nl_BE/. No flows are redirecting to the
url without trailing slash in our codebase before 14.4, so the problem
is rarely seen.
When clicking on the "Edit in master" button, _goToMasterPage now
correctly removes the language code and redirects to the master
version, solving the problem.
task-2622270
closesodoo/odoo#76837
X-original-commit: 141c15d5dae137df11a73146ff4c991add7a2ff3
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Several changes distinguish product attributes better from variant
attributes. The variant creation mode is added on the template form for
attribute lines with more than one value. Specification attributes are
no longer listed as variant attributes in the product variant form and
tree views.
task-2466988
closesodoo/odoo#72559
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Tom De Caluw <tdc@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Coupons and promotion programs can now be shared by creating a link that can
directly be used by the customer.
Using the link, the system will try to apply the coupon/promotion to the
customer's order.
If this can't be done, the error will be shown to the user, for instance
"A minimum amount of 1000$ is required to get the free ipad".
That coupon/promotion will then be stored in session and the system will try
automatically reapply it when something is added to the cart.
task-2489749
closesodoo/odoo#69053
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Co-authored-by: Tom De Caluwé <tdc@odoo.com>
The onClickDeleteProduct handler in the cart widget triggers a value
change in the input field containing the quantity of the sale order
line. This only works if there is such an input field, however these
were removed for non sellable lines (including reward lines) in commit
ae7e1f64f8. Simply restoring the input
field (even if it stays hidden) resolves the problem.
closesodoo/odoo#74222
X-original-commit: 73a33877384ac1b2b4b3d818b6a2d6840984f488
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When a task is created from the website form, if the user is logged in, add it
as the partner on the task.
task-2366706
closesodoo/odoo#71794
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Tom De Caluwé