For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
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>
-> This commit add/change the name of the page corresponding to the string
attribute because To be able to detect a field, Knowledge needs to be able to
read its page name.
For more reference: Task-3501211
Task-3524474
closesodoo/odoo#137428
Related: odoo/enterprise#48315
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Unwittingly broken by the removal of `__implements__` in
a6d601dc4e, these lints don't run
correctly with the old pylint, allowing new errors to creep in since.
closesodoo/odoo#139605
X-original-commit: 99cec73f585c8759142a707b06934d9c23aa5478
Related: odoo/enterprise#49473
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Remove autoconfirm logic and simplify the flow of event
registrations. Now a registration is by default considered
as confirmed.
The draft state is kept for registrations with
a payment pending.
These registrations are no longer counted
as expected attendees for the seats computation.
To match the behavior of events, we also add a seats_expected
computed field on event tickets.
The registration status is now based on the sale order state.
So the payment_status field is renamed sale_status.
We consider now that a registration linked to a SO in a sale
state should be confirmed and reserved.
A sale order is in the `sale` state when manually confirmed
or when the transactions done match the amount_total of the
sale order.
We also rename the seats_expected field into seats_taken to
better match the process. It was a bit weird to have expected
in the name when the registration attended were counted into it.
UPG PR: odoo/upgrade#4836
task-3061849
Part-of: odoo/odoo#126431
RATIONALE
Merge two phone-related field on registration as they overlap. Having only
one is sufficient for contact-oriented model like registration.
SPECIFICATIONS
Registration model currently holds two phone field, phone and mobile. This
leads to having records with sometimes phone, sometimes mobile being filled.
This makes phone flows not easy: we have to define fallbacks (use phone or
mobile), data is not always synchronized, ... in the end what event users
need is one phone field to be able to communicate with attendees. Having
only one field is sufficient and simplifies the model.
Keep only one phone field, instead of two. Merge phone and mobile into a single
one, keeping phone as first value when having both available e.g. when
synchronizing with the partner.
Task-3366899
Part-of: odoo/odoo#128232
Co-authored-by: "Jeremy Hennecart" <jeh@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
Before this commit, the record.update function did not allow x2m fields
to be updated. Thanks to this commit, you can update an x2m by passing
a list of commands that will be applied to the x2m's static list.
This makes it possible to update several fields, including x2m fields,
while triggering only one onchange to the server.
closesodoo/odoo#129507
Related: odoo/enterprise#44532
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
The whole contextual price of products relies on multiple context keys:
* uom
* pricelist
* quantity
* date
The related logic has already been partly removed/deprecated on products,
but the computation of discounts for events/event booths are still relying
on that logic, though imperfectly.
This commit makes sure this hacky logic (relying on those contextual keys)
is as clear and reliable as possible.
We factorize and harmonize the remaining use cases, with a dedicated constant
and specific methods, making sure:
* currency conversion
* price & discount computations
are coherent, while clearly explaining that it should not be used for
any new feature/logic/code.
We also restrict context updates as much as possible (there won't be
any discount when the pricelist is configured to hide the discount from the customer)
closesodoo/odoo#123848
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit allows us to add the events on sales order templates, and then
configure them in the sales order quotations. Users will get an error when
trying to confirm a quotation if events are not configured, and they will
be able to configure said events by clicking on them.
Task-2988003
closesodoo/odoo#116974
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When we are selling a booth from the sale application, and have a
pricelist set on the order with a discount_policy "with_discount", it
needs to compute the price_reduce of the booth catgeroy to get the
unit_price of the sale_order_line.
As the price_reduce depends on the pricelist in the context, we need to
give the pricelist in context to get the correct price. This only
happen from the backend, because when we come from the frontend
(website) the _get_contextual_pricelist() takes the current pricelist
from the website.
So we are now taking the pricelist from the sale order and pass it in
the context when we need the price_reduce, which is the same behaviour
as the one in 'event_sale' for event ticket.
closesodoo/odoo#119893
X-original-commit: c3ec492390b27485934daabdc8e6d2771f01d933
Signed-off-by: Masereel Pierre <pim@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the accounting module had a setting on the selection of taxes used by the sales, purchase, website_sale, ... modules. In addition, the website_sale module had the same setting related to the accounting one.
This PR isolates the tax selection parameter in the website_sale module, and instead of using the tax selection, the accounting module will use rounding method (round per line, round globally).
Selecting one of the two will change the display of all account_move or other view using the tax selection setting.
Display changes:
In round per line, a column tax excluded will always be displayed while a column tax included will be in optional hide.
On the other hand, in the round globally, only the tax excluded columns will be available.
closesodoo/odoo#99209
Task-id: 2954332
Related: odoo/upgrade#3826
Related: odoo/enterprise#30853
Signed-off-by: William André (wan) <wan@odoo.com>
Current behavior:
In a sale order: a wizard pops up to complete the link with the event
and attendee when we add an event product (same issue with event booth).
In quotation template: the wizard doesn't pop up when we add an event as
optional product.
When we create a sales order with the quotation template, the event
is added as product but the wizard still does not pop up, and therefore,
the SO is not linked to the event.
After this commit:
Don't allow adding event (or event booth) as optional product to a
quotation template.
A same fix was already done on products (not optional) here:
https://github.com/odoo/odoo/pull/100499
opw-3081853
closesodoo/odoo#113730
X-original-commit: a6bc38598f695ead9d9816b6858823b28b4ba95d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Harmonize _get_display_price between event_sale &
event_booth_sale.
Do not rely on contextual stuff when information is
available without using contextual data.
closesodoo/odoo#110833
Related: odoo/upgrade#4256
Related: odoo/enterprise#36210
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Harmonize currency conversion of unit prices:
* Make sure no rounding is applied during the conversion
(it'll be managed by the price_unit decimal precision
and the currency rounding will only be applied by the
monetary fields later in the computations).
* consistent parameters for the conversion (date,
company, currency).
* code simplification
* consistent behavior when the SO has no currency specified
...
Part-of: odoo/odoo#110833
Steps to reproduce:
- Create a price list with different currency and discount with "show price and discount to the customer"
- On the website select this pricelist and register for the event.
Issue:
The price in the cart is shown in the main currency
Solution:
[website_event_sale] There is an initial issue which when it calls '_compute_price_reduce'. We compare, 'product.lst_price' (in product.currency) and 'product.price' (which has been converted to the pricelist.currency).
In order to compare apples with apples, a conversion is applied to have the 'product.lst_price' in the same currency.
After that, we have kind of a coherent behaviour in the sense that 'ticket.price_reduce' is in the same currency as 'ticket.price'.
Thereafter, a conversion is applied (if the pricelist.currency is different) to get the expected amount.
The same reasoning is applied to [website_event_booth_sale].
Note: 'list_price' has been changed to 'lst_price' in Booth to have the same logic between Event and Booth
opw-2766997
X-original-commit: ced49554dd7cca73a1da440607d545bad64e7af0
Part-of: odoo/odoo#107768
Odoo Translation Bot