Add message post with attachment test on record of another company than the
user company but for which the user has readonly access on. The goal is to
justify the sudo added in mail_thread:
- in '_message_post_process_attachments' method to create attachment linked
to the record (the creation of attachment linked to a record verify the
right to write to the record, so in readonly we need a sudo);
- in '_message_set_main_attachment_id' method to link the main attachment to
the record. Here we write directly on the record for which we only have
readonly access, so a sudo is needed. Here the attachment is already linked
to the model and we only "tag" it has main attachment (see odoo/odoo#30659)
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@8486c7ee05
Part-of: odoo/odoo#114511
Purpose of this commit is to add tests to post in record user cannot access
especially in multi company environment.
Main observations
* ACLs are checked when fetching record_name, then when fetching reply_to
information, adding a bit of ACLs noise in the process;
* check_access_rule of mail.message is called when creating the message
(which is the real protection);
* posting on a document user cannot see is possible when they have been
notified of a parent message. Use case is: answer a ping, even on a
document non readable, should always be doable. However it currently
crashes notably due to attachments check, who always require the read
access on the related document even if the message is authorized;
In this commit we also move other tests about multi_company in the right
file (and add a test flag) in order to have all of them in the same place
easing debug and testing.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@5656f4d20d
Part-of: odoo/odoo#114511
Purpose is to add some tests about email layout support in both comment and
email mode, as well as language support in those two modes. They are added
in a test targeting a complete template usage, testing globally the results
(outgoing notifications or emails, buttons, language, recipients, ...).
Posting in multi-languages environment with notification layout is also
tested. Finally a test about reply-to is moved into its own subtest to
avoid polluting core template tests. Other low level details should already
sufficiently tested. Normally.
Main observations
* translations are quite broken in mass mode (either batch comment either
mass mailing). Indeed translations are fetched based on <mail.compose.
message> body and subject fields, which are probably not translated
as they are linked to a transient model. Real translations are stored
at <mail.template> level when users translate their templates;
* layout translation is partly supported in comment mode, due to a small
context-based hack. However access buttons are not translated and some
use case (like using a 'res_domain') are not supported;
* mass_mail mode does not support layouting at all;
* when posting manually ('message_post') current users' language determines
the language of notification email layout e.g. a user using Odoo in French
will send a french layout to all followers, whatever their language and
whatever the language of the post (which is not known as user input);
Most of those use cases will be fixed soon.
Also update some query counters while passing by.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#114511
Allow to return <mail.mail> records and found outgoing emails when using
asserts. It eases doing checks in some specific tests e.g. checking
notification layout usage in emails. Indeed this is quite low level and
does not really deserves its own assert tooling methods.
Update tool method generating attachment data to ease name tweak when required
in tests.
Also update query counters, and fix a test not running locally.
Task-3046371 (Mail: Better Language Support in Composer)
X-original-commit: odoo/odoo@b32d937b37
Part-of: odoo/odoo#114511
Steps to reproduce
==================
- Make sure the "Work Orders" setting is enabled
- Manufacturing > Products > Bills of Materials > New
- Select a random product
- In the Operations tab, add a line
- Type something in the Operation field
- Set the workcenter to Assembly line 1
- Save and close
- Click on the "Show Instructions" action button
```
Traceback (most recent call last):
File "/home/hubert/src/16.0/odoo/odoo/models.py", line 5108, in ensure_one
_id, = self._ids
^^^^
ValueError: not enough values to unpack (expected 1, got 0)
```
Cause of the issue
==================
The action is called without in id because the record is not yet created
Solution
========
The button should display a warning in x2manys when the record is virtual.
This was actually the case before Odoo 16 but there was an option on the
button `options='{"warn": true}'`. With this commit, it will be the
default behavior.
We also remove this option from the xml since it isn't used.
sentry-3950549982
closesodoo/odoo#114505
X-original-commit: 9fc0424a4450923aa8582bdb6766e1b19cb68546
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this PR when uninstalling hr_contract, expense was uninstall automatically because of the depends, the purpose of this task is to remove the depends.
closesodoo/odoo#114120
Task-id: 3203717
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this commit, when loading the pos with pos_loyalty, even if limited product was activated, all the products were loaded to make sure that we could apply rewards.
Now, we don't load all the products but we only load the rewards by default.
closesodoo/odoo#114021
X-original-commit: 60e7cdee62cf6b19ce0b26f2c7cbe708f74a806e
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
In the model, we trigger events RELATIONAL_MODEL:NEED_LOCAL_CHANGES,
RELATIONAL_MODEL:WILL_SAVE_URGENTLY and RELATIONAL_MODEL:FIELD_IS_DIRTY
on env.bus. That means that if we have two instances of the model in //
(e.g. two views, or two Record components, or a mix...), their fields would listen and react to events
triggered for another model. Trigger those events on the model instead,
as it is an EventBus.
Because the events are directly triggered on the model, we can remove
"RELATIONAL_MODEL:".
Part of task: 3179751
closesodoo/odoo#113880
Related: odoo/enterprise#37727
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The current smartbutton is Employee(s) and it redirects to kanban view by default, no matter how many
employees a user / partner has. 9 out of 10 times a user / partner only has one linked employee, this
change renames the label to 'Employee' and redirects to the form view if there is only one employee
if there are more, the previous action is called
linked upgrade: odoo/upgrade#4363
this closesodoo/odoo#111439
Signed-off-by: Kevin Baptiste <kba@odoo.com>
PURPOSE:
Companies want to have a better integration, we need to focus on the On/Offboarding process,
to find automation and something to show to our customers.
In this commit, we add the "Fleet Manager" in the responsible list of the activities
generated from a plan.
Case 1:
If employee is not linked with fleet, `Employee XXX is not linked to a vehicle`
this warning will be appeared.
Case 2:
If employee linked with fleet but doesn't fleet manager set on fleet,
`Employee's vehicle XXX is not linked to a fleet manager.` this warning will be appeared.
task-3081261
closesodoo/odoo#108892
Signed-off-by: Kevin Baptiste <kba@odoo.com>
document_ftp, website_instantclick, pad, pad_project, note_pad, pos_cache is not currently existing in the addons, removing the non existing modules from the BLACKLIST dictionary.
closesodoo/odoo#107213
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
- In Journals/Bills/Advanced activate "Lock post entries with hash"
- Create a purchase tax of 17%
- Create a bill with a product of a cost of 30 and apply the "17%" tax
- Post it
- Export the data inalterability check report
Issue:
"Corrupted data"
Cause:
In python we have a reprentation issue
```
>>> 30*0.17
5.1000000000000005
```
We define the hash string during the `_compute_string_to_hash` at the
move creation. The issue is, at that time, the move_line tax debit
is not rounded.
Therefore, when we print the report, we take the `move.line_id.
debit` from the db which is rounded and equal to '5.10' and compare
it to '5.1000000000000005' which gives a different hash
Solution:
Implementing a V3 version that uses `repr` for monetary fields.
opw-3072693
closesodoo/odoo#114567
X-original-commit: cfd71892aabf1510273b28032ff8f2d4cfd4d1f7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
To reproduce the issue:
(Also need: account_accountant,purchase)
1. Setup a product P
- Storable
- Category:
- FIFO + Auto
2. Process a PO with 1 x P at $10
3. Process a PO with 1 x P at $50
4. Create and confirm a SO with 1 x P
- Because of FIFO, the value of the delivered product is $10
5. Process the delivery
6. Post the invoice
7. Add credit note
- Credit Method: Full refund and new draft invoice
8. Post the second invoice
Error: The cogs are based on the second received product ($50), they
should rather be based on the delivered one
When computing the anglo-saxon unit price of the product, we consume
the outgoing SVLs, and we consider the already-invoiced quantity.
Here is the issue: we pretend that this quantity is 1, because of
the first invoice, but this should be balanced with the quantity of
the credit note
OPW-3109789
closesodoo/odoo#114564
X-original-commit: e46d68562c1ec55b7838f6854c1d26f56bec9bc6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this commit:
If a payulatam payment is received from the confirmation
page (so, with the webhook). If the value have some decimals
it might be rounded in the wrong way.
As such, the generated signature to compare with is wrong
and the payment validation cancelled
After this commit
If we cross compare the signature generation documentation:
https://developers.payulatam.com/latam/en/docs/integrations/webcheckout-integration/response-page.html#signature-validationhttps://developers.payulatam.com/latam/en/docs/integrations/webcheckout-integration/confirmation-page.html#signature-validation
We notice that the `new_value` computation is slightly different
depending on the return.
The one we currently use for both method is the "return"
one which is computed differently from the "confirm" one.
With this change of code a "confirmation" page payment
will be validated as intended.
I also changed the log level from warning to exception
so that the traceback and exception message is logged.
Before this commit there was just a generic warning message
opw-3018628
closesodoo/odoo#114552
X-original-commit: ee30c21eb5189b2cfcfd6d249985c947f759eaa2
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
Since commit 17a24020ac, StateSelectionField
displays its label in all views. This was an error. It should only
display its label in list views.
closesodoo/odoo#114538
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce the issue:
1. Create a product:
- Type: Storable
- Category:
- Costing Method: AVCO
2. IN 1000 @ 0.17
3. IN 800 @ 0.23
4. OUT 1000
5. OUT 800
6. Open the inventory valuation of the product
Error: the total value is $-6.00, it should be zero
Once all products received, the standard price is $0.20. Its value
has been rounded because the real value is
`(1000 * .17 + 800 * .23) / 1800 = 0,196666667`
The standard price will create a difference when using the products,
because:
`(1800 * .20 = 360) != (1000 * .17 + 800 * .23 = 354)`
That's the reason why a feature tries to compensate such rounding
errors. So, step 4, when preparing the values of the out-SVL, we
check if there is a rounding error, and we find a difference of $6,
which is correct. However, the difference is above the treshold, so
we will not consider it as a rounding error:
https://github.com/odoo/odoo/blob/3ff51daa93a1d670b8f67f79418d4dd48e94875f/addons/stock_account/models/product.py#L197-L200
Here is the issue: the threshold is based on the outgoing quantity
(1000) while the value difference is based on the whole quantity
(1800). This difference should also be proportional to the outgoing
quantity.
Note: The fix will still not work with a small quantity. The only and
best solution is to change the type of the SVL unit cost into a
float.
OPW-3101374
X-original-commit: 35d8b4c2a223970520961bf8bfc574bb309af090
Part-of: odoo/odoo#114525
Co-authored-by: Adrien Widart (awt) <awt@odoo.com>
Since [this commit], it's possible to change the connectors style in
edit mode, unfortunately the code to determine if the connectors should
be visible or not was not compatible with small width screens. As a
result, when a user edited his site on a small screen, he saved hidden
connectors even for visitors with larger screens (while the connectors
should be visible). This commit allows the user to manage the connectors
correctly without taking into account the screen size at the time of
editing.
Steps to reproduce the fixed bug:
- Drop a steps block.
- Reduce your screen width to < 992px or Switch to mobile view from 16.0
- Activate an option of the block.
- Save.
=> The connectors are not visible anymore in desktop view/large screens.
[this commit]: https://github.com/odoo/odoo/commit/aba31e9f2d8a44ce1586403f2a621a6caeed57b4
task-2687506
closesodoo/odoo#114447
X-original-commit: https://github.com/odoo/odoo/commit/6f507a315a64529627c8805d5947ffe4a7f6f509
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
*:point_of_sale,pos_restaurant,web
A new module pos_preparation_display has been added to Odoo enterprise.
This PR is intended to add the requirements necessary for it to work
properly.
The changes are mainly related to the kitchen printer functions, as
the pos_preparation_display module reuses these flows in order to
receivethe orders to be prepared.
closesodoo/odoo#109024
Related: odoo/enterprise#35392
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Those items are no longer used since the legacy form views have
been deleted from the codebase.
closesodoo/odoo#114394
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Allow to perform multiple reconciliation at once in order to:
- ...batch the creation of records as much as possible.
Creating an account.partial.reconcile force the orm to search for amls in order to invalidate the reconciliation fields like amount_residual/amount_residual_currency.
- ...reduce the number of flush inside the orm and batch the compute.
Each call to reconcile is looking for the payment's state of invoices before/after the reconciliation.
This step is costly because this will flush all the reconciliation data and then call the computes to get the fresh value of payment_state.
- ...modify more easily the way the lines are matched together.
Before this commit, the lines were split into two batches sorted by some criteria including the currency: debit and credit.
Then, we were matching them together sequentially.
Now, we make the same things except we do that first for each batch of amls sharing the same currency in order to reduce the number of cross-currencies reconciliation.
- ...allow the orm to prefetch all the partials in the reconciliation chain all at once.
The full reconcile needs to be creating on the full reconciliation graph starting on the current amls so we need to travel the matched_debit_ids/matched_credit_ids in order to find all the involved amls.
Fetching all this data at once is also reducing the number of queries made by the orm.
Let's take an example:
Suppose 10 amls: a1, a2, ..., a10
Suppose 10 amls: b1, b2, ..., b10
You want to reconcile respectively a1 with b1, ... , a10 with b10.
Before this commit, each reconciliation was done as follow:
- Check the payment_state of invoice (on 2 amls)
- Create a partial reconcile (single record)
- Create a full reconcile (single record)
- Compute the reconciliation data to compute payment_state (on 2 amls)
All of that, 10 times sequentially.
With the new '_reconcile_plan' method, we are able to give a list of recordset [a1 + b1, ..., a10 + b10]:
- Check the payment_state of invoice (on 20 amls)
- Create a partial reconcile (10 records)
- Create a full reconcile (10 records)
- Compute the reconciliation data to compute payment_state (on 20 amls)
For a reconciliation using 2000 records (a1, ..., a1000 & b1, ..., b1000), the time to reconcile it was about +-34 seconds. Now, it's about +- 3 seconds.
closesodoo/odoo#113680
Related: odoo/enterprise#37543
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce:
- Install "Sales" module (for test purpose)
- Change company name to `בונז " ור מונד` (notice the double quotes)
- Go to "Settings > Users & Companies > Users"
- Select any user and then click on "send an invitation email" button
- Go to inbox and check the email
Issue:
No email received (at least not in main inbox).
Cause:
The email is not received in main inbox (Gmail or Outlook might flag
them since email from is not well parsed) because the `email from`
value is not escaped properly (by escaping the double quotes).
Solution:
Instead of using the company name (that is not escaped) and email to
build the `email from` value, use the company email_formatted value
instead (and fallback on user mail if not available).
opw-3097910
closesodoo/odoo#114534
X-original-commit: 0c4cb5e3cc2758cb27e94ecbbcfaa734ba5a50eb
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
- Go to Contact-Configuration-Countries
- Remove the code of a country
- Create a new contact
- Select the country from which you deleted the code
- Put any vat number starting with country code you deleted
Issue:
Traceback
Cause:
in `_run_vat_test` we want to `country.code.lower()` -> country code does not exist
Solution:
Prevent the user to delete a country code by making the field required.
sentry-3923412146
closesodoo/odoo#113207
Signed-off-by: William André (wan) <wan@odoo.com>
The test TestWithholdingAndPensionFundTaxes::test_pension_fund_taxes_export
was expecting the xml to contain a tag `<RiferimentoAmministrazione>` while
this tag is optional if there is no description set, which is the case here.
We thus removed this tag from the expected xml.
closesodoo/odoo#113236
Related: odoo/upgrade#4359
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Taxes have a `description` field that has been hijacked to
represent tax label on invoices. We want the description field
to be used for its original purpose, thus created a dedicated field
`invoice_label` in which we transferred `description` content.
We also make description translatable.
This is part of the Tax Taxonomy 2 rework.
Task: 3052677
Part-of: odoo/odoo#113236
This commit allows the user to choose which quants to reserve from stock
and the quantity to reserve from each quant, making reservation much more
flexible from the picking form.
In addition, the `reserved_uom_qty` of stock.move.line
is now editable in views to allow for users to change the qty reserved
by existing move lines. When editing the reserved qty, if quantity is not available,
it will reserve only what is available..
closesodoo/odoo#106006
Taskid: 3090913
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit adds a check to avoid forcing a write on the sml
even if the putway location is the same on the sml, which
avoids unnecessary additional costly _gather() calls during the quant updates in the write
Taskid: 3090913
Part-of: odoo/odoo#106006
This commit fixes a couple of issues linked to relational fields:
- When previewing a file with relational fields/ids, they were not
correctly mapped to their respective fields in the selects, the fields
were also not correctly mapped in the arguments given for the import.
- The select label was also only showing the name of the last sub-field
while it should show the full path ("External ID" vs "Company / External
ID").
- Some errors were not correctly displayed: wrong field name, not in a
column when it should be.
Task ID: 3210337
opw-3203704 + opw-3192403
closesodoo/odoo#114490
X-original-commit: 871690afdc2ce4da2770a144cc4fc5ed038e6f73
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit: if a different `web.base.url` is set with
`web.base.url.freeze`, during the first synchronization of Google
calendar it will show a mismatch URL error. The problem is that we
send the `redirect_uri` based on the `web.base.url` in the
`_get_authorize_uri` function.
The solution is to use the request root URL instead.
opw-3175539
closesodoo/odoo#114482
X-original-commit: 8f94f2ec864bdb54e3deb9b853a2720c5c92f592
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this commit, we will remove:
- groupedBy because the api is weird, we don't want to handle type abbreviations.
- getAggregableRecords because it is only used in one place.
In this commit, we will also convert canQuickCreate to utils and we will
move it to kanban because it is the only view that uses it.
Part of Task: 3179751
closesodoo/odoo#114459
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
ValueError "Invalid field slide.slide.partner.survey_scoring_success in leaf
('survey_scoring_success', '=', True)" .
it occurs because the domain field in gamification.goal.definition is not updated
when we uninstall the model.
we add the uninstall_hook in website_slides_survey where we replace the domain.
sentry-3779856181
closesodoo/odoo#114353
X-original-commit: abc662e3b190c58794eaf62ed7850439f9ebfd50
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If an user tries sending a invoice using an invoice address and a
delivery address through snailmail, it would result in a traceback.
This is due to the invoice address record not having a name.
closesodoo/odoo#114227
X-original-commit: eceb23b1835b3d039759eb7431950f221ac1fb6e
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The main goal of this commit is to simplify, uniformize and remove
unused props. The props removed are : options, attrs and className.
The readonly prop is uniformized with the one in the fields api. It will
now allow the use of readonly as modifiers on the widgets, as it's
already the case on fields.
This commit also uniformize the parseWidgetNode with the parseFieldNode,
the widget doesn't receive on props the rawNode anymore but a widgetInfo
as is the case for the fields.
Part-of task-id 3179751
closesodoo/odoo#114188
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
__Description of the issue this PR addresses:__
The first character of a Tax ID from Albania is a letter representing the decade in which it has been issued. The letter M represents the current decade. (This pdf explains in details how it is formated: https://www.oecd.org/tax/automatic-exchange/crs-implementation-and-assistance/tax-identification-numbers/Albania-TIN.pdf).
Currently the way Albanian Tax IDs are validated is through the python library [`python-stdnum`](https://pypi.org/project/python-stdnum/).
However, the regex that is used to validate them has not been updated since 2017. (I made a PR in its repo https://github.com/arthurdejong/python-stdnum/pull/402 to fix that).
The code from this commit is inspired by the one from that library, but the regex includes the letter M.
__Current behavior before PR:__
(`base_vat` must be installed)
By going to Settings > Users & Companies > [A company]:
- Set the country to Albania
- Set VAT/Tax ID to “M12345678T”.
=> Error message
closesodoo/odoo#114488
X-original-commit: f0b6e4ccd8f7402a5d70b9d60d91e463073e5bde
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Step to reproduce:
Edit documents layout in general setting to add logo and background
select multiple documents (more than 5) e.g. Inventory> delivery slips
print all documents.
Bug:
background and logo missing on the last documents because the pages
were printed before the browser had time to render them
Fix:
wkhtml2pdf has a default delay of 200 ms (--javascript-delay)
increasing the value will allow large document to load
opw-2951594
closesodoo/odoo#114512
X-original-commit: ac2df93eb3f08696189d010bdfa4187e02a94576
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
- Install `Contacts` module
- Create 3 contacts with the same name
- Archive one of the contacts
- Go to list view
- Edit search filter to display archived and non archived contacts
- Select the 3 created contacts
- Open `Action` menu and click on `Merge`
Issues:
- Archived partner is set by default as destination partner.
- Archived partner is not displayed in the list of partners to merge.
Cause:
- The default destination partner set is the last record of the record
set returned by `_get_ordered_partner` (where `Archived` partners
are the last ones in the record set).
- The field `partner_ids` does not allow archived records.
Solution:
- Sort the partners to have the archived ones on top (since we took
the last one).
- Set `active_test` to False in the context of the partner_ids field.
opw-3205577
closesodoo/odoo#114508
X-original-commit: 8d0cec6844b248d3787bd7d6b8868d930d25e38c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set the check number to 2147483648 and validate
- Create a new payment with the check method
- Click on Print a check
Issue:
Error is raised
Cause:
As for https://github.com/odoo/odoo/pull/112832 there is a second check in order to increment the check number
opw-3140973
closesodoo/odoo#114496
X-original-commit: 531147bb5fad6372c3742bc061f78687f7f11e5b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Before this commit:
- When a color index is greater than 55, the CSS class applied does not
have a matching style.
Only 56 CSS classes have a matching style: from 0 to 55.
To reproduce:
- Go to Calendar, edit an event and add an attendee having an id greater
than 55. When displayed, the event does not have a proper color.
It has the default FullCalendar color instead.
After this commit:
- The colors will cycle through 55 colors, from color 1 to color 55.
(Color 0 being the value for "no color", which is some kind of gray)
closesodoo/odoo#114491
X-original-commit: eda4e12202a1bf6459009b41313f9af4b4dc326b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Steps to reproduce the bug:
- Go to the website and edit a page.
- Make sure there is enough content to be able to scroll the page.
- Go to the "Theme" tab and disable the "Show Header" option.
- Click on the footer and enable the "Scroll Top Button".
- Click on "Save".
=> Clicking on the "Scroll To Top" button does nothing.
The "Scroll To Top" button is an anchor with its `href` set to `#top`.
By disabling the "Show Header" option, the header is removed from the
DOM and there is no existing element with `id=top` anymore. To fix
this, the `scrollTo` function has been patched in order to be able to
receive selectors as arguments. In the '#top' and '#bottom' case, those
positions are known and always the same (either at the top of the
document or the bottom of it) so there is no need to have the header or
the footer present in the DOM in order to be able to scroll up to those
positions.
Now that the `scrollTo` function is able to scroll to the top or the
bottom of the page even without header or footer, those two positions
can always be suggested as internal link anchors during link edition.
opw-3133464
closesodoo/odoo#114472
X-original-commit: 6ae5d73332d5413495cc25e28cba86f8be18b570
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
RATIONALE
Currently email layout choice is done in code and is not controllable through
any user interface. In this commit we prepare improvements in template
management by allowing to choose the email layout directly from a given
mail template. As number of layouts is going to grow better be able to
choose the right one.
SPECIFICATIONS
Add a field on template to propagate email layout choice directly on
template and propagate it to the composer, then post/notify process.
We can now choose directly on a template which notification layout should be
used in conjunction with this template. Composer model already holds a field
'email_layout_xmlid', used in various places in code to give a specific
layout to use when sending notifications emails e.g. SO email layout. This
can now be specified directly from the template itself. It allows to
customize the look and feel of notifications without having to do it
explicitly in a given code flow.
Computation is coming either from template, either reset. When having a
template with a value set, set it on composer. When removing the template
reset it.
Currently no standard template uses it as this task targets mainly a code
cleaning that began with the composer code cleaning. It targets the near
freeze to have the base code updated once, then functional templates will
make use of it (hopefully).
Note that currently notification layout is still not supported at composer
level for mailings. It is simply ignored when generating outgoing mail
records. This will be improved soon.
Global followup of odoo/odoo#107356 / Task-2088884 (Mail: Use editable
computed stored fields in composer).
Prepares code for Task-3046371 (Mail: Better Language Support in Composer)
see odoo/odoo#106177 .
Task-3186426 (Mail: Support notification layout in template / email composer)
closesodoo/odoo#114462
Related: odoo/upgrade#4404
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We have a lot of hits without any forum_origin which will raise an
error 500 because this parameter is required. But because this params is
not into the controller but received as a get parameter, it will match
the controller and return an error 500 instead of a beautiful 404.
Some controller like 'open_partner' redirect to this url without the
parameter forum_origin too, leading in a 500 in all cases.
Better for uX to have this param, but not critical to display the page.
The only negative impact will be to have a 'Back' button that return to
this new default value '/forum'.
closesodoo/odoo#114461
X-original-commit: 991d1c430f2c9bb0d2b2d7ac8f75338eafd2aced
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Pierre-Yves Dufays