Steps to reproduce:
1- Install Manufacturing module
2- Create 2 or more new WOs and make sure that their corresponding MOs is not planned
3- Go to Operations > Work orders
4- Mark all of those WOs and write a start date to apply on all of them
5- Check Planning > Planning by Workcenter 'you will not find the scheduled WOs'
Current behavior before PR:
When you try to mark more than one record in Work orders and set start date for all of them at the same time it will not be set therefore it will not be visible in Planning calendar. This is happening because if you are setting the start date for the first time it will call the function that sets the start date first before calculating the finish date so it will not pass the condition where it checks if both dates have values.
Desired behavior after PR is merged:
Now we are checking just the start date if it has value or not and to raise the same user error if the customer tries to delete the finish date we are checking this on change of the finish date from a value to null.
opw-3596100
closesodoo/odoo#151272
X-original-commit: 70394e616e5d75ee33ed048dbd7210c1926c63be
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Dependencies and other manifest attributes are not set for data modules.
Note: it's easier to reproduce issue in 17 since we have data module available
on runbot.
steps to reproduce (in 17.0):
- install an industry (ex: bar_and_lounge)
- uninstall a dependency of that module (ex: mrp)
before this commit:
- bar_and_lounge is not uninstalled if you uninstall mrp
after this commit:
- data model dependencies are handled the same way as 'regular' modules
opw-3660052
closesodoo/odoo#151256
X-original-commit: 12256bbc5981b06d7b77c133cc8f282ac03afba9
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Steps:
- In mobile open project
- Project.project form view
- Share project
- Invite people, the 'email' is displayed twice in the kanban view
Issue:
- In mobile when project share invite people, the 'email' is displayed
twice in the kanban view
Cause:
- This will be coming because of the context for show_email
Fix:
- By removing of context show_email it will be working fine.
task-3550702
closesodoo/odoo#150528
X-original-commit: b7fe981d0984bf265a970b0b132dec2172f42bf8
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
If partner to invoice is from "Zona Franca - IVA Liberado"
then the exportation invoice then the AFIP concept to
use should be code 4. "Others"
closesodoo/odoo#150051
X-original-commit: 8ef4b332d46d78daa5c8c91d8b1110468316d583
Signed-off-by: Josse Colpaert <jco@odoo.com>
Recently, a new option 'always_range' has been added to the datetime
field (task 3628069, commit bc98aad). This option forces the display
of the arrow between the two dates from the start. Before that, you
would add a first date, click a button to add a second date and then
only would the arrow appear.
The oversight here is when the field is empty AND readonly. In that
case, you have an visible arrow next to the label but you can't do
anything with the field anyway. So better not to show it.
This commit makes sure to not display the arrow in this case.
task 3690523
closesodoo/odoo#149912
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit the button to add documents from an URL is labeled
"Add Document" which is confusing given it is displayed besides an
"Upload Document" button.
This commit renames the "Add Document" button into "Add URL" to make its
purpose more obvious.
task-3493618
closesodoo/odoo#149406
X-original-commit: 860cbe0fcddc7b7a6f1ca383161ab439ba68fd72
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
With this commit, the button "duplicate" when you selected some attendances is not shown anymore.
task : 3646395
closesodoo/odoo#147276
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Uganda uses the label TIN on reports and invoices, which stands for
Taxpayer Identification Number. This commit adds this label to the base
module.
task-3340378
closesodoo/odoo#131877
Signed-off-by: Josse Colpaert <jco@odoo.com>
Problem
---------
There is currently no localization for Uganda.
Objective
---------
Add the base localization for Uganda:
- Chart of accounts
- Taxes
- Fiscal positions
- Default settings
- Tax reports
Solution
---------
Create a new localization and set up all basic required information:
- tax and tax groups, CoA and fiscal positions are defined in CSVs.
Details have been obtained in documents (for details about those
documents, refer to the task).
- demo data is generated (it uses a random address)
- default accounts and value are set up for the company
- Profit and loss report and balance sheet use the generic template
- Tax report has been made following the template provided by the URA
task-3340378
Part-of: odoo/odoo#131877
Since 17.0 , calls to _get_combination_info on the
/shop/cart page were removed to avoid recomputing
values already stored on the cart, speeding up
the page loading.
See 824fc94bbc
Nevertheless, this highlighted the difference
in pricelist discount computation between sale
and website_sale.
In sale, the discount is computed while considering
the base price of the pricelist, whereas for
website_sale, the base price was always the sales price.
To make sure the crossed price displayed is the sales
price as before on /shop/cart, we override the default
sale behavior to force the sales price to be considered
as price before the pricelist discount.
closesodoo/odoo#151321
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
With this change, we can set other conditions easily.
Also, it allows us to check if it can be payed without actually executing the pay function,
because sometimes we don't want to change the screen but we want to check if the order can
be processed for payment.
For example, we could disable the Pay Button from the Product Screen
closesodoo/odoo#150914
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
When a user adds a tip and removes it by hitting multiple backspaces, a
traceback occurs. The value passed as the tip was supposed to be an
empty string if no tip is applied, but it received a null value, causing a
traceback.
After this commit:
The tip value is checked to be a truthy value. If it is not a truthy value,
then an empty string is passed, resolving the traceback.
task-3692849
closesodoo/odoo#150586
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
On N elements resource.calendar.leave and M elements resource.resource recordsets,
the __get__ calls to 4 leave fields were done M time per loop, aka 4*N*M times.
This commit reduces the number of call to 4*N times, reducing the method executing
time for grid_unavailability from 9 seconds to +- 4.5 on odoo.com while displaying
all timesheets on Month view.
closesodoo/odoo#150408
Related: odoo/enterprise#54830
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, the `_search_is_timeoff_task` search method for the
`is_timeoff_task` field could return the same task id many times in the right
part of the leaf inside the domain returned by the method.
This commit makes sure the list of ids in the right part of the leaf in the
domain returned by the search method will be each time different task ids.
Part-of: odoo/odoo#150408
To reproduce:
- Go in admin user
- activate Audit Trail in the settings
- Log out
- Connect as demo
- Go to the audit trail report
- Activate the filter Update Only
=> Access right error
The demo user doesn't have the right access
for the domain of the filter.
We should hide this filter for these users
closesodoo/odoo#149783
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Steps to reproduce:
- open bom
- open product `Table`
- set the quantity of all subproduct to `0`
- Open overview
Issue:
the table top has 1 in qty
Cause:
For a bom subproduct, if there is no qty set (0/False), we automatically set the qty defined on the bom
opw-3677052
closesodoo/odoo#151141
X-original-commit: 4db4fe4466292ca2041bf04434ababfbc10cd9dd
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Steps to reproduce:
- Create a product and set it tracked by lot and expirable
- Create a lot for this product that is already expired
- Create a MO using this product as component and confirm it
- Go the Shop floor and force the use of the expired lot for this
component
- Click on 'Close Production', a traceback will appear
Issue:
Since the action is defined directly in the python code, we don't have
some extra fields that are usually computed on a `ir.actions.act_window`
record, such as the `views` field.
Yet, on the js side, the action service requires that field to properly
work, so we add it in the action definition.
closesodoo/odoo#151084
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The import feature of matching numbers was done manually in all imports,
but the generic import was missing.
For instance, with this file:
```csv
name,line_ids/account_id,line_ids/debit,line_ids/credit,line_ids/matching_number
test 2,400000,,121,1
,500000,121
test 1,400000,121,,1
,451000,,21
,700000,,100
```
The system wouldn't understand that this is an imported number.
closesodoo/odoo#150848
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Steps to reproduce:
1) Create SO with customizable product (example “Customizable Desk”)
2) Let default values in product configurator
3) Save SO
4) Go to product template, and in the Attribute remove all value
options, only leaving the custom value
5) Try to open the product in configurator in the saved SO
Reason:
archived combination is not loaded
After this commit:
When requested combination is archived, load it
opw-3513685
closesodoo/odoo#150653
X-original-commit: fc8fb4277c477161ab9e6538689a85591a440885
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
Steps to reproduce:
1) Create product with an attribute that has several values and with an
attribute with 'create_mode = 'no_variant' and one value.
2) Create SO with this product, save
3) Open product configurator again and see the traceback
Reason: selected_attribute_value_id is not set.
After this commit: the attribure value is defined in get_values of
product configurator.
opw-3513685
X-original-commit: 8cf7d706f86e830670fb3c8fd799e6cacefe122c
Part-of: odoo/odoo#150653
Steps to reproduce(locally):
1) Create SO with the product that has a custom value attribute
2) Leave the custom field empty
3) Save SO and open product configurator again
4) Observe TypeError traceback
Reason: customValue is supposed to be string but if value is not set,
it remains False which cause a type error.
After this commit: allow customValue be false
X-original-commit: 4ce49fd7a07439beaccfbf8160ca85130696bfe8
Part-of: odoo/odoo#150653
Steps:
- Install subscription and razorpay app.
- Configure razorpay provider with tokenizable
razorpay account.
- Enable allow tokenize field.
- create subscription with more then 100k and
less then 500k amount.
- Try to pay that subscription with razorpay.
Issue:
- Throwing limit exceed warning even though amount
is less then 500k which can create token and paid
normally.
Cause:
- We forgot to check minimum of method max amount and
amount * 5 to send proper mandate max amount while
creating token and because of that paying more then
100k via subscription raise error even to it should
processed normally.
Fix:
- Check minimum of `method max amount` and `amount * 5`
to send proper mandate max amount so it'll not raise
error while paying amount in between 100k to 500k.
closesodoo/odoo#150410
Related: odoo/enterprise#55009
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit:
Clicking on invalid link results in a blank and bizarre notification because
we are accessing wrong parameter in wysiwyg.js.
After this commit:
After correcting parameters clicking on an invalid link triggers a notification
displaying an invalid URL message.
task-3563345
closesodoo/odoo#139301
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
This fixes names of VAT accounts in Slovak localization package as it uses the same names for sale and purchase accounts.
closesodoo/odoo#151244
X-original-commit: f7c6a1a525b9e4ba83aebf0dc10a681c4b3d1d66
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
This commit solves a crash which can happen when a popover points to an
element inside an iframe that has been removed from the DOM. In those
cases, the element's ownerDocument does not have a defaultView.
closesodoo/odoo#151235
X-original-commit: 1ccebdbd2fcc6875173b02a31d89f3c2e9ffbfec
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Versions
--------
15.0+
Steps
-----
1. Go to Purchase;
2. create a Vendor Pricelist;
3. select a Product, a Product Variant & a Unit Price;
4. empty the Product field & save;
5. create a RFQ;
6. add the Product Variant from the Vendor Pricelist.
Issue
-----
The product's price remains 0.
Cause
-----
The `seller_ids` field in `product.template` creates one-to-many
relation with `product.supplierinfo`'s `product_tmpl_id` field. While it
is possible to select a specific product variant and have the product
field empty, this renders the Vendor Pricelist unavailable for Purchase
Orders.
Solution
--------
Add a `_sanitize_vals` method to `product.supplierinfo` to be used on
create/write, which ensures that if there's a `product_id`, the record's
`product_tmpl_id` is consistent with it. This allows for record imports
to be usable & consistent when only a variant is specified.
Also backport a modified `onchange` method added in
5537090f1c. Originally it only reset
`product_id` if `product_tmpl_id` was changed to a different non-falsy
value. Modified, it also resets `product_id` if `product_tmpl_id` is
changed to a falsy value, as it would otherwise just re-add the removed
value on create/write after this commit.
opw-3664524
closesodoo/odoo#151210
X-original-commit: 572122335a04126385115d892b027371bbabbe7e
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Adds the tax report, associated tax grids along with new taxes,
required in order to generate a tax report as well as a SLS/P report
Task id # 3211351 and 3468278
closesodoo/odoo#150619
Related: odoo/enterprise#54908
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit:
We used the .textsize method, which returned the height and width of the
icon. However, in the latest version of Pillow, this method was deprecated,
resulting in errors in the log.
After this commit:
We have transitioned to using the textbbox method, which returns the
coordinates of the top, left, bottom, and right of the text's bounding box.
From these coordinates, we calculate the height and width of the text.
task-3502373
closesodoo/odoo#140613
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Prior to this commit, some visual style of the SelectMenu component had
not been adapted since the latest Odoo redesign (named Milk). This made
some parts of the menu inappropriate with the current padding of the input,
and the border would not fit anymore, since the input is no longer linked
to the menu.
Also, the search input no longer had a pointer: text associated, but a
pointer instead, which seems wrong as the user can type in it.
Finally, some element were not visible correctly in dark mode.
This commit improves the overall look of the SelectMenu component when being
used with this design.
closesodoo/odoo#151276
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
This commit fixes the behavior of the SelectMenu component when an option
is being used with an empty string or a null value.
Let's suppose we have the following choices:
{ label: 'Empty', value: '' },
{ label: 'Full', value: 'full' }
Before this fix, when selecting 'Empty', the value would be selected in the
menu, but the toggler would still be empty, as if no value was selected.
Now, any value corresponding to a choice value can be selected.
A test has been added for each value supported (null and empty strings).
Part-of: odoo/odoo#151276
When importing an xml, impose a minimum length on the VAT to consider
the value.
Some xml contains VAT = "BE" (without numbers...). In this case, we
search on the partners with matching VAT, and end up selecting a random
belgium partner.
Now, we only search the VAT if len(VAT) > 5. In addition, in a UBL xml
where multiple tags can contain a VAT (PartyTaxScheme/CompanyID and
PartyLegalEntity/CompanyID), we retain the first value which have the
minimum length.
opw-3675350
closesodoo/odoo#151206
X-original-commit: 54849dc423b808cc17e9241bdc72b9547b964bec
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
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>
Youssef Bashandy