This commit changes the display name for the model event.type from
"Event Category" to "Event Template"
This change was needed before introducing the new model event.tag.category
which will be used to group tags (event.tag)
This commit introduces two new models: event.tag.category & event.tag
The tags will be grouped by category and will be used to filter events.
In the front-end, if the user activates the "filter by categories", each
event.tag.category will generate a new dropdown of related tags.
Clicking on one of these tags will add a new "tag badge" above the events
(same way as in eLearning).
LINKS:
TaskID:2162438
PR: #43856
Before this commit the documentation had quite some samples with 'customer', '=', True. Since in V13 this field on the res.partner model no longer exists we've removed it.
closesodoo/odoo#48453
X-original-commit: 2215d803aa35cdd13ab7f989c807bc7f575aaa8e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Confirms and plans the manufacturing order created for table (MTO) in
demo data to have already a work order.
task-2199747
closesodoo/odoo#46464
Related: odoo/enterprise#8922
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Sets the currency of supplier info (purchase price) in demo data on USD.
The reason is the default company currency is EUR, so the supplier info
created use the company currency by default.
But once account is installed, the company currency is switched for USD.
As multi currency is inactive by default, the user can't see the product
purchase prices aren't in the same currency than all the other prices.
task-1970460
Adds quantities in starting inventory and adds a "Starting Inventory"
for the Chicago Warehouse. The purpose is to avoid to have negative
values in demo data.
Task #1970460
Rename warehouse of compagnies as following:
- YourCompany -> San Francisco
(WH) (WH)
- My Company (Chicago) -> Chicago 1
(MyCo) (CHIC1)
- Chicago Warehouse -> Chicago 2
(Chic) (CHIC2)
Also, can pass a default code through the context when create a new
company to set the `code` value when creating the default warehouse for
the newly created company.
Task #1970460
Before this commit, some tracked product quantities didn't have a SN/LN.
To avoid some issue at the use, it's better all demo data fulfill
requirements like that.
Task #1970460
Demo data product's quantities are no more put in sublocation as by
default, multilocation aren't active.
Also, adapts `test_location_usage` because as we moved quantities from
sublocations to the main stock location, the stock warehouse will have
reserved quantity due to a backorder created by demo data.
In this test, we try to change location as a scrap location, what we
can't do if this location has some reserved quantities.
Task #1970460
<h2>Description of the issue/feature this PR addresses</h2>
Update UX for blacklist management of "mass mailing" and "mass mailing sms" by:
- Making phone and email blacklisting text / UX more consistent
- Making it easier to remove a phone/email from blacklist
- Improve GDPR compliance by adding in a "Reason for unblacklisting" via a wizard for traceability
<h2>Current behavior before PR:</h2>
A blacklisted phone number or email address can only be removed from their respective blacklist by going to the corresponding blacklist view [in mass_mailing_(sms)] and manually archiving the entry. All users could see that an email was blacklisted via an fa-ban icon added next to their corresponding field in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via extension). Some UI inconsistencies between the Phone Blacklist and Email Blacklist implementation exist.
<h2>Desired behavior after PR is merged:</h2>
Add additional fa-ban icons next to blacklisted phone numbers and make all instances of these icons clickable to remove their corresponding field value from blacklist using a wizard. When submitting a value to be unblacklisted, a "Reason for unblacklisting" is possible to help with GDPR compliance. Additionally use same wizard as a "Unblacklist" button within form view in phone/email blacklists.
Task ID: 2117635
Upgrade PR: https://github.com/odoo/upgrade/pull/939closesodoo/odoo#45315
Related: odoo/upgrade#939
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously a blacklisted phone number or email address could only be
removed from their respective blacklist by going to the corresponding
blacklist view [in mass_mailing_(sms)] and manually
archiving/deactiviting the entry. All users could see that an email was
blacklisted via an fa-ban icon added next to their corresponding field
in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via
extension).
This commit adds additional fa-ban icons next to blacklisted phone
numbers and makes all instances of these icons clickable to remove them
from their corresponding blacklist using a wizard. There are several
limitations to this implementation including:
1. If both a mobile and phone number field appear within a crm lead
instance, then only the mobile field will indicate if it is blacklisted
(due to current implementation of PhoneMixin which only checks 1 phone
value against the blacklist and "sms" which returns mobile numbers first).
I.e. if a phone field value is blacklisted, but a value is typed into the
mobile field, then the phone field will never indicate that it is blacklisted.
2. If someone clicks on a unblacklisting icon after changing the
corresponding field value without clicking off the field input, then the
latest typed in value will be the one submitted for unblacklisting,
which may not actually be blacklisted (due to "is_blacklisted" flag
being a computed field and it not having a chance to re-compute to hide
the button).
3. If someone changes values in the blacklist, then someone who already
has a form open will not see icon disappear until something triggers a
re-compute of the "phone_sanitized_blacklisted" flag (this was already the
case with the icon, but now a user may try to unblacklist a value that is
already unblacklisted.)
4. Since the icon needs to be visible by everyone to indicate whether or
not a phone/email is blacklisted, users without corresponding unblacklist
permissions will be able to click on the icon. When they click on it, they
will be informed they do not have permission to unblacklist. A wizard was
determined to be the best way to implement this unblacklisting for the
following reasons:
- A "Unblacklisting Reason" is needed and will not be stored as a field.
- A field widget is unable to do this due to security settings +
inability to refresh view after unblacklisting with a
"Unblacklisting Reason" without wiping unsaved changes.
Additionally, to better align with GDPR, the corresponding form view for
the phone/email blacklist has been updated to use the same wizard to
track "Reason for unblacklisting". Unfortunately there is no
straightforward way to prevent direct "Archive" action, so users are
still able to bypass unblacklisting without being asked for a "reason
for unblacklisting".
Supports task: 2117635
Upgrade PR: odoo/upgrade#939
COM PR: odoo/odoo#45315
In 13.0, as of 369c20a9 there is some style that will show an event with
bigger font-size and spacing in calendar day view.
In this commit, if an event is short (less than 30 pixels, so less than
45 minutes) we will decrease the spacing to have the same as in week
view and see the event title more easily.
opw-2216654
closes#48391closesodoo/odoo#48409
X-original-commit: a4d170ad9e73d1d63404532b161911df020b5c36
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
After d3ddcc613f l10n_it_edi started to
fail its tests because not adapted, porting the code from the same commit
fix the issue
opw-2214185
closesodoo/odoo#48397
X-original-commit: 33e80333b84d71ae0f61d4ab0e3aa7fdfcdf0f78
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When user apply half day leave in Leaves, the approver should be able to check
whether it's morning or afternoon on the approval page.
closesodoo/odoo#48429
X-original-commit: 3d3de2bf991bf4a10566599d3bb9011e4c09d21f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Minor UX tweaks for more consistent and correct wording, visualization,
and editing ability for mass_mailing and mass_mailing_sms. Specifically:
- Fix all "This email is blacklisted for mass mailing" => ".. mass
mailings" typos
- Make phone blacklist not editable (to align w/ email blacklist)
- Add "Archived" ribbon to phone and email blacklist
- Update menu items and actions
- "Phone Blacklist" => "Blacklisted Phone Numbers"
- "Blacklist" => "BLacklisted Email Addresses"
Supports task: 2117635
Simply create an SO with more than 1 Qty and deliver. An untaxed amount
is shown on the SO.
Check in Sales > Reporting > Sales > Pivot view, the Untaxed amount
Invoiced and Untaxed amount to invoice Measures. They show the right
amount.
Make a partial return from the original SO and validate.
Reduce the quantity on the sale order line.
The sales report is not updated with the right untaxed amount to
invoice. This occur because when the sale order line have an increased
qty_ordered a chain of event is triggered which included the
recomputation of the untaxed_amount_to_invoice which does not occur on
decrese.
Adding the product_uom_qty to recompute triggers fix the issue
opw-2213996
closesodoo/odoo#48282
X-original-commit: f8a5366ea650c1a2ac4ad3a42da7da4a34758d60
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This happened:
- The user clicks on a parallax snippet
- For each option, call onFocus then updateUI:
- The BG position is first, so update its UI
- The parallax option is last, onFocus changes the BG position target
... this is broken since the BG position option was updated before the
parallax one was able to change its target. So the BG position was
updated by checking the background type of the snippet instead of its
internal parallax <span/> element.
This was working in 13.0 as changing the target automatically re-updated
the related option UI, now this is left to the dev to update the UI
afterwards or not.
In this case the fix is simple: the onFocus of all options should be
called, before calling the updateUI of all options. This actually
allows to make the code cleaner.
closesodoo/odoo#48428
X-original-commit: 912e849207709b31aa11b7a2bec9ed8dd8b43203
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
It is possible to define required fields from the Authorize.net backend
without which no customer profile can be created. These fields include
data that Odoo sometimes does not have at all (fax number, anyone?);
however including the phone number is a meaningful option.
Before this commit, if the 'phone number' was required by the
Authorize.net configuration and was correctly set in Odoo, this still
did not work because we did not include the phone number with the
customer profile creation request payload.
We do now.
opw-2215332
closesodoo/odoo#48420
X-original-commit: 034c04efa4ccecd40f657eae97ef2b04934d570c
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce the bug:
- Let's consider a product P
- Let's consider that a draft SO has been created for P with analytic account AA
- P can be sold (sale_ok=True) and Re-invoicing policy = 'At cost'
- Untick the option 'Can be sold' on P
- Create an expense E for P with the analytic account AA
- Submit E and try to post the entries
Bug:
A UserError was raised saying that SO with analytic account AA must validated but
P is no more salable.
opw:2217773
closesodoo/odoo#48408
X-original-commit: 3db629cbcde9c4c3bbe2874c18e01dd31abe092d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The 'vendor bills' stat button on purchase order, once clicked, will
have a specific behavior depending on the invoice count :
0 : open a new invoice with pre filled fields (not saved yet)
1 : open the form view of the invoice
2+: open the list view of the invoices.
Before this commit, the invoice count was computed with an environment on
the current user. That means a record rule could make the invoice count
lower than the real count and so give an unwanted behavior. Ex: create a
new invoice even if there is already one created because the user cannot
see the other people's invoices.
After this commit, the action_view_invoice with make an explicit read()
in database to fill the cache with all the purchase order's invoices and
make sure the count is the real one.
Task : 2206969
closesodoo/odoo#48274
X-original-commit: e3101d92187946b2bd539e05956e4e83cd9c9097
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit ensure the user have to minimum rights to post invoices
The 'Post' button was already hidden but the post() method is public
Task : 2206969
X-original-commit: 28ae3fb5366d61d3f5f9067cda962b047105199e
Before this patch, the purchase users get an access violation error
at the invoice creation from a purchase order. This was due to
some missing ACL between v12 and v13.
Task : 2206969
X-original-commit: 4c4fb33e4bbc78a85ad309baf5df906cf16566ea
When the value is the same for all records, the write can be done in
batch, this can lead to a "slight" performance improvement, depending on
write overrides, and how the value was computed for each line.
Correction of the position of the buttons when editing bg-image
position with a parallax effect other than "fixed".
task-46147
closesodoo/odoo#48419
X-original-commit: 0919b11c9a78a97345b42bf0fe0f1f9939c2b214
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- before this commit the product was set to EXP_GEN
but nothing if EXP_GEN is not in db anymore
- now it will pick the first "expensable" product if EXP_GEN doesn't exist.
closesodoo/odoo#47678
X-original-commit: ee35c662768c6f27dff88e9c4597695c17b3b67b
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Thomas Carlier <Explicitapps@users.noreply.github.com>
Handle missing barcode for 'pick components' and 'store after
manufacturing' picking types
closesodoo/odoo#47201
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Currently when the warehouse is created the picking type are created
with a fixed barcode that contains the warehouse code. Later, a
warehouse's code modification will not impact the barcode on the
picking type. However when a company is created the warehouse is
also created with a default code. It's easier to modify all the
barcodes when the code is modified rather than update picking type
one by one. We expect users to setup warehouse configuation before
starting to customise its components so it should not be problematic
but it implies that a late configuration could impact small
configuration on locations and picking types.
Usecase to reproduce:
- Create Warehouse with code A -> Picking type sequence start with A/
- Set the warehouse's code to B -> Picking type sequence remains A/
- Set the warehouse's code to C -> Picking type sequence become B/
It happens because _update_name_and_code is called before the write and
it updates the picking_type's sequence with warehouse current name and
code.
Before this commit, trying to use Odoo as a library without initializing
the logging features would result in a crash because `Logger.runbot()`
is monkey-patched inside the function `init_logger()`, which is de facto
necessary for using Odoo as a lib.
With this commit, we do the monkey-patch at the module-level so whenever
the `netsvc` package is imported the patch is applied, which should be
well before the loading of the registry starts.
closesodoo/odoo#48396
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
In gallery snippet in carousel mode, fix the fact that the height of
the controls are bigger that the others squares and fix also the wrong
position of the indicators.
task-2162952
closesodoo/odoo#48380
X-original-commit: 9752596abfcae6b0bbf79ac675fe9e304a068a21
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As the container class now changes with the width option. We cannot use
this class in the js or css files anymore.
task-2162952
closesodoo/odoo#48377
X-original-commit: 1cf2ee35c2d85d87b27d5bd72c414e12fcbaf123
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, There would be a crash if the user tries to remove `website_company_id` from Website configuration as It is used in Backend.
With this commit, we make `website_company_id` required if the Website is set.
Fixes#47967closesodoo/odoo#48175
X-original-commit: 940cc76ef3f301df91b60353e48cbaa5217bea93
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
While you edit an account move line
you only want to see the account
that belong to the company of the move
The record rules on account.account
lets the user see the account
of all the company selected.
It too much when you want to select an account
on a move.
Solution:
Add a domain in the account.move form view
closesodoo/odoo#46197
X-original-commit: e0aeb878eed266810862ffb2efc7c03f51389c8f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps to reproduce the bug:
- Let's consider an attribute A with two values V1 and V2
- Let's consider a product P with V1 and V2 as attributes
- Duplicate A
Bug:
P was associated with 4 attributes V1, V1, V2 and V2
opw:2219540
closesodoo/odoo#48342
X-original-commit: 1c44aeb7d1734cd7a6dbdb80971f98553c67003b
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When we print a report for multiple records, we call wkhtmltopdf one
time and to save each document separately, we will split the PDF based
on its outline if it is available.
The outline is generated by wkhtmltopdf based on headings
(H1,H2,H3,H4,H5,H6,H7,H8,H9 elements) for example this document:
```
<h1>hello</h1>
<h2>world</h2>
<h1>!</h1>
```
has this abbreviated outline structure:
```
/Outlines: {
'/First': {
'/Title': 'hello'
'/First': {
'/Title': 'world'
},
'/Next': {
'/Title': '!'
}
}
}
```
But the current heuristic did not take into account level of headings,
so if the document had a lower-level headings this could break the
multi-printing of these reports.
So for the example above, the document would be cut in 3 when in reality
we only want to cut it twice over the top level heading (`<h1/>` here).
An existing issue in Odoo is in l10n_in_sale, `<h6/>` element are added
to the report invoice line so instead of only one `<h2/>` heading
containing the invoice name per document, there was an additional
heading per invoice line which broke the heuristic.
note: we also add an assertion to ensure first heading is on first page.
note: allowing several top-level heading on same page has been
implemented so reports that did not work in 11.0 but worked in 12.0 and
over (thanks to 573e57773) still work after this change.
opw-2188767
closes#48099closesodoo/odoo#48374
X-original-commit: 63c2478cc9fb21afb83d31b04ff6c6090ee492ab
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 12.0 9de1bc0e aria-label translation was added for python views, but:
- aria-label attribute are not exported
- aria-label are not translated for JS view rendering
So by default, aria-label would only be translated for python views that
had the same aria-label term in a translatable element (eg. "title"
attribute).
opw-2222504
closes#48255closesodoo/odoo#48275
X-original-commit: 6b6b11ea2f8391f1f195bd1650531f77b6bed729
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When you create a invoice from a sale_order
the account was taken from the journal and
it should comes from the product
or the product_categories and in last resort the journal
and finally fiscal position should have been apply.
It was not the case anymore,
because setting the partner_id prior the account_id
trigger the default_get on the account_id which
in that case take the wrong value
closesodoo/odoo#47267
Solution: set first the account_id then the partner_id
X-original-commit: 857564367691f3f11572f718499c9d22c823c421
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Some menus contain items that are selected/checked when they're
activated, e.g. when a filter is applied, the menu item corresponding to
that filter is checked. However, that information of what items are
checked and what don't, is not reported correctly using aria attributes.
To solve the above, the following is performed:
- Attribute `aria-checked` is set accordingly, usually using the same
logic as the clas `selected`
- Attribute `role` is set to `menuitemcheckbox` or `menuitemradio`
instead of `menuitem`, so `aria-checked` is applicable
This applies on the following cases:
- Standard topbar's menus: Filter, Group by and Favorites
- The company switcher widget
closesodoo/odoo#48301
X-original-commit: 64c0b47c0e8e8fdd3fa9b1bc13f2b49b6f49f4e1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Purpose of this commit is to let computed stored editable fields being
copied if their field class allows it.
Indeed the value of those fields is computed based on some triggers but
can also be updated manually by users. When copying a record, it makes
sense to consider that this value is what the user expects and allow its
copy, if the original field allows it. Either it was computed, and
copied value will be correct without having to call computation again
(well, provided all dependencies have been copied, too), or it was
updated and the copied value will be the one the user entered.
Without this fix, an edited field is not copied, and will be recomputed,
which may look like an inconsistent value.
Task ID 2209163
closesodoo/odoo#48383
X-original-commit: 4b274d3b4101fbae154a572cdf40d23838899773
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Currently, when updating a review on a course, the feedback field is not
updated on the rating model. Therefore, the backend view for rating is
always displaying the first feedback posted
Task ID 2184038
closesodoo/odoo#48382
X-original-commit: f2d04753be9f1feb75e575b0598b3520caa4744d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Finetuning of
https://github.com/odoo/odoo/commit/b30e280b2d676f16873ac0fd1279c4870d994dec
:
self.user_id is always an empty recordset in a default function call,
use self.env.user instead, it is the default value for user_id.
The _init_column override is needed to ensure the new property field on
res_users isn't read at module installation, because its ir.model.fields
doesn't exist already, leading to a wrong sql query in ir_property.
closesodoo/odoo#48378
X-original-commit: 6c6bd018c761535f973781319090116d7eea60ad
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
qmo-odoo