To reproduce:
- Go on the website page of a product with optional products.
- Disable the Select Quantity customize show.
- Click add to cart.
This will open the optional product modal, where the quantity will be displayed.
However changing that quantity will have no effect, especially the price will
not update accordingly.
The real issue is that the quantity should not be displayed there if Select
Quantity is disabled, but this has never worked before, so this is outside the
scope of this fix.
Anyway, since the quantity is present there, we would at least expect it to
correctly recompute the price, which worked fine when the modal was introduced,
but has been broken since 51e51055bf
opw-2005317
closesodoo/odoo#33992
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set an analytic account on an employee contract
- Set credit and debit accounts on the salary rules
- Create a payslip, confirm
The journal items created do not use the analytic account set on the
contract.
If no analytic account is set on the salary rule, we fall back on the
contract account.
opw-2006090
closesodoo/odoo#34095
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
During a Google Calendar sync,
exclusive instance of a recurrent event to which you are not the owner and
without an update datetime shouldn't be considered.
See developers.google.com/calendar/v3/reference/events/update
where cancelled status event might have empty fields.
> A cancelled status represents two different states
> depending on the event type:
> Cancelled exceptions of an uncancelled recurring event indicate
> that this instance should no longer be presented to the user.
> Clients should store these events for the lifetime of the parent recurring event.
> Cancelled exceptions are only guaranteed to have values for the id,
> recurringEventId and originalStartTime fields populated. The other fields might be empty.
As you are not the owner, the event shouldn't be deleted from Odoo
as the actual event owner might still attend the meeting.
It should just remove the user who is syncing his calendar from the attendees,
but as the sync currently doesn't support syncing event without an update datetime
from Google, we just choose to ignore the sync of this event.
The attendee will be removed/marked as not attending when the owner of the event
will sync his calendar.
opw-1966309
closesodoo/odoo#34075
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
- Set the products tracked by lot
- Set 1 route with steps that allow to begin next one after a minimum
amount processed.
- Plan and begin the manufacturing process.
- Process partially step 1, but fully step 2
- Finish step 1
The error 'You can not change the finished work order.' is raised.
This is because we try to set the default final lot on a WO which is
done.
This is only used to suggest the right lot number, so we can safely skip
the step if the WO is done or canceled.
opw-2002044
closesodoo/odoo#34072
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When sending a message (e.g. in a CRM lead or SO),
a failure_type and failure_reason are displayed, even when the message
is successfully sent.
This is because these fields are not updated when the email_status
is changed to "sent". We reset these fields to '' when the message is sent.
OPW-2003290
closesodoo/odoo#34082
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
What's the deal with SQL queries?
The query in _check_category_reference_uniqueness returns:
category_id | uom_count
-------------+-----------
(0 rows)
but if we removed AND U.active = 't', we would have had:
category_id | uom_count
-------------+-----------
8 | 0
(1 row)
As a result, the check on uom_data['uom_count'] == 0 could simply never be true.
opw 1959679
closesodoo/odoo#32788
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Make a SO for some products with weight and a delivery set.
Put some products in a pack. It returns a wizard to choose the package type.
This wizard also allows to input the shipping weight.
It always defaulted to 0, instead of the sum of the weight of the products.
Due to ff7df19bd3, default_stock_quant_package_id is in context so
_default_shipping_weight would try to use stock_quant_package.shipping_weight,
which is always set to 0 at that point.
Note that furthermore, the active_id might not be a picking (e.g. a SO).
Therefore we always make the computation, with the default_picking_id in context
opw 2006566
closesodoo/odoo#33930
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
From now, the color option 2 ('Mixed color & B/W') is not available anymore. So set the option to 1 ('Color').
Task-ID: 2008913
closesodoo/odoo#34052
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
This tour is useless in backend.
This patch will be required in saas~12.2 as `web_editor.base` (used in
the tour) is only available in frontend.
closesodoo/odoo#34041
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Create a mailing campaign
- Create a mailing 1, set the subject to "Test 1"
- Create a mailing 2, set the subject to "Test 2"
The subject of mailing 1 is set to "Test 2".
When checking the code, this behavior seems the one expected. The
`_rec_name` of a mass mailing is the `subject_id`:
https://github.com/odoo/odoo/blob/7ef4ba03c4f8dce42f5a56b64d2374373d13aa8d/addons/mass_mailing/models/mass_mailing.py#L437
Moreover, there is an onchange to set the subject in line with the
subject of the campaign:
https://github.com/odoo/odoo/blob/7ef4ba03c4f8dce42f5a56b64d2374373d13aa8d/addons/mass_mailing/models/mass_mailing.py#L608
However this behavior is not present up to v11, and only appears in v12.
Surprisingly, this is due to an unrelated improvement which adds the
field in the view (in debug mode): 5b0bcaef3e.
Up to v11, the onchange exists, but since the fields are not in the
view, it has no effect. However, in v12 the fields are in the view so
the onchange has an effect.
Since this was the behavior up to v11, and that the behavior is fixed
in f50fbc6d16, we keep it consistent in v12 as
well.
opw-2007764
closesodoo/odoo#34028
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Have a translation linked to a record unreadable because of a record rule
(e.g. a product that is not shared between companies).
Display the translations list view; if one such translation is in the view,
it will raise an access error.
When computing the source value, _compute_source will fail to read the record,
and raise an access error.
This will make it impossible to access untranslated terms.
Instead we guard this error.
Since it is displayed in the view, we display an informative message.
Note that since we make this error go away, we also fix the check method.
Only the superuser bypasses the record rules; so if we made the check on write
with _is_admin, it means than a user in group_erp_manager cannot read a record
but can edit its translations.
opw 2000817
closesodoo/odoo#33989
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
avoid to get journal_entry_ids, to avoid pushing those ids in cache and
having them read uselessly when accessing an account.move.line
recordset.
Use search and search_read instead of ORM __get__
closesodoo/odoo#33192
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
=======================================================================
Note on this commit:
This reintroduces what was reverted in 83b52e3a97 with an extra
fix in the call of `_prepare_reconciliation_move_line`. The second
parameter of the method call should be the amount in the company
currency since it used as debit or credit value.
A test is added.
opw-1997794
closesodoo/odoo#33515
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
When creating a repair order in mobile view, it is not possible to add
any Parts or Operations since required fields are not set.
We make the corresponding form views consistent with the tree views.
opw-2005905
closesodoo/odoo#34016
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33943
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
In a still-to-determnie situation, a cyclic dependency with
`associate_member` is observed, preventing the installation of the
module.
We remove the dependency, and trigger a recompute on the parent members.
opw-2005325
closesodoo/odoo#33977
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Goto App Attendance > Manage Attendances > Kiosk Mode
- Select Employee (redirect to Kanban view)
- Refresh the browser
The page reloads and Kiosk Mode is left (Menu is visible, Dashboard can
be accessed).
Since the action is only used in 'Kiosk Mode', we can set it as
fullscreen.
opw-2006789
closesodoo/odoo#33969
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
With the demo data:
- Go to Inventory
- On the 'Delivery Order' Kanban card of YourCompany, click on 'Back Orders'
More pickings are displayed than the expected count.
This is because the domain of the filter is not in line with the domain
of `_compute_picking_count`.
closesodoo/odoo#33953
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this task, when creating the related field from the studio, it is by
default stored. When we change the field name in 'ir.model.fields' using ORM's
write method, it also renames the column in the table associated with the
field's model.
This is the expected behavior. But when someone tries to change the 'name' of a
non stored field, the column is not available in the associated model, and so
trying to rename the column results into traceback. This issue was probably
there for a while but came into light with the task 1985710. More info can
be found on the chatter of the task.
This commit fixes the issue by adding an extra check before renaming the table
column. The query will be executed only when the field is stored and thus
exists in the table.
closesodoo/odoo#33944
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit makes the sale line field on task editable and clickable
only for salesperson. As task can be read by any employee (depending on
project visibility), a non salesman user can see the 'name_get' of the
sale line, but get an access error when clicking on it.
This fix duplicate the field and only display the correct version
(editable or readonly) according to current user access rights.
Task-1999673
closesodoo/odoo#33320
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
The content of these fields can't be updated, there's no reason to
even show them. Just remove them from the default / auto-generated
view for client actions.
Task 1772242
closesodoo/odoo#29179
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When a project user (without any sales acces rights) want to create a task in
a billable project (linked to a sales order / sales order line), he will face
some access right issues :
1/ the system want to set the default customer on the task, by taking the one
from the sale order line linked to the project in which the task is created. This
raises an error as the task creator has no right to read the project'sale line.
2/ after that, the "sales order" field is computed on the task. This raises the
same error as we need acces through sale line to determine the sales order of the
task.
This commit fixes thoses problem by adding a `sudo` and by adding the "sales order"
field only for sales person.
opw-1999673
In settings, we added the possibility to edit service products per type
(time-based, fixed, or milestone). An action was trigger and a default filter
was applied. This filter was removed with c1f7987f49, making the 3 settings
links displaying all products.
This commit restore the filters. In order to keep the UI silmplification,
those 3 filters are only displayed (in search view) for this specific flow.
So, we keep the general search view simple.
opw-1987352
Steps to reproduce the bug:
- Create a product template A with variant color: black and white.
- Create attribute : size : 16gb and 32 gb
- Create a bom with template A.
- Add a bom line L with product B
- Save the bom ,edit it and select an attribute value for L
Bug:
All attribute values of the database (color: white, color: black, size: 16 gb, size 32 gb)
were displayed.
opw:2006988
closesodoo/odoo#33949
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Log as admin user in company C
- Go to Leaves module and click on Managers > Allocations
- Create a leave.allocation with type = Compensatory Days, duration = 7 days
mode = By Company and Company = C
- Approve the allocation
- Create a leave request LR for all the company C and approve it
- Log as demo user (only user access right for Leaves)
- Go to Leaves > My Leaves and click on "Leaves requests"
Bug:
A traceback was raised
opw:2005813
closesodoo/odoo#33899
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
For each asset depreciation lines we verify that there are not linked
to a move. This verification was done for each line separately.
Moreover, during the creation of the journal entries, we were writing
on the 'line_ids'. In this case, accessing the move of a line
was invalidating the cache. This fix ensure that this operation is
done out of the loop and the cache is then not invalidated at each
step.
See opw-2000305
closesodoo/odoo#33908
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since test_pylint was moved into the test_lint module in commit
b27077bb, this could break Odoo instances where a module has test_pylint in its dependency.
With this commit, the test_pylint module is coming back as an empty
module.
closesodoo/odoo#33871
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
When uploading a file to a binary file, then clicking on the
"clear" button, then reuploading the same file...
Before this commit:
The actual input of the field was only changed on user input.
This means that the "clear" action didn't reset the actual value
of the input, and the browser's default behaviour when getting
the same path twice is not to change anything. In the use case,
you couldn't upload the same file until you uploaded another one.
After this commit:
The "clear" action now also clears the value, allowing reuploading
the same file over again.
closesodoo/odoo#33843
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
when we select places warehouses where route can be applied, then unselect that warehouses, warehouses values on m2m tag are not deleted.
because of wrong value empty list on onchange. so remove all records of warehouses if warehouse option was not selected.
closesodoo/odoo#33883
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, user would be redirect to / instead of /my after signup.
That error was detected with task-1829827 which has a tour ensuring user is
correctly redirected to /my after signup on the checkout summary after payment.
Since 0229ef4c4a, the `web_login()` super call order has been changed when
called from the `/web/signup` route.
See the commit for more details but basically, before the fix, it went only
through:
1. web.web_login
2. portal._login_redirect
Where now, it goes through:
1. website.web_login
2. auth_signup.web_login
3. web.web_login
4.portal._login_redirect
Thus, portal._login_redirect is not returning `/my` as redirect anymore.
Indeed, website.web_login will ignore its super() and force redirect to `/`
With this commit, website's user are redirected to /my as expected.
Side effect: website's user will also be redirected to /my on login instead of
`/`, which is also prefered.
closesodoo/odoo#33865
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When we add a document with the "Select a Media" modal, if we reopen the
modal then click on "Save" without modfiying anything, the element is
broken since we do not have the data saying it is a document and the
code try to display it as image.
With this changeset, we keep the information that the attachment is a
document and when saving it works as expected.
opw-2004064
closes#33844
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Add two PO with references 'XY' and 'Z' to a vendor bill.
The reference is computed as 'XY, Z' (with ', ' as separator).
Add a PO with reference 'X', the reference becomes 'X' instead of 'XY, Z, X'.
There are two variables that may not be defined (vendor_ref and self.reference),
and specifically the case where a reference is the prefix of another one is not
correctly dealt with.
opw 2005825
closesodoo/odoo#33841
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
For recurrent events, many fields are set to define the recurrency;
these fields are invisible unless (recurrency', '=', True).
However there are fields that depend on fields to define the recurrency,
which are required in some cases.
However in case where recurrency is later set to False, no onchange cleans up
the intermediary values (this is taken care of in the create),
but the 'required' on the non-relevant fields might prevent from saving.
We fix these cases by adding the recurrency in the list of requirements.
opw 2002181
closesodoo/odoo#32698
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- Create product A:
Reordering rule of 5 units
Set a vendor V
- Create a SO with 1 unit of A
- Create a PO with 1 unit of A for vendor V
- Run the scheduler => the PO contains 6 units
- Run the scheduler => the PO contains 12 units
The PO should not be updated the second time the scheduler is run.
It occurs because the `orderpoint_id` is not set on the PO line, while
the `_quantity_in_progress` method searches for PO lines with the
orderpoint set.
opw-2000962
closesodoo/odoo#33798
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In a web editor, add some text, select the text, add a link and
immediately discard the link modal. Traceback.
The traceback is a execute `setEnd` on `Range`, that error is thrown
because editable DIV doesn't save old range
Odoo wrap code does some text node split in order to attach the link
just on the selected text. If it correctly re-set the underlying
structure, it does not update the $(editable) structure used to restore
ranges.
After this commit, editable div will use newly created range for the element
for ex:
-> content: test
-> selected content "test"
when click on link dialog:
ec: test , eo: 4, sc: test, so: 0
selected content -> start 0, end 4 -> "test" like this
after clicking on discard:
ec: null text element, eo: 4, sc: null text element, so: 0
selected content -> ec and sc both are null, so it will throw an error
while setting cursor position
after applying fix when click on discard:
ec: test, eo: 4, sc: test, so: 0
selected content -> start 0, end 4 -> "test"
task - 1955863
closesodoo/odoo#33692
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit:
- When you create a compute field, from the model view, dependence field
was not required when creating a compute field.
- When removing the compute code, the dependence field stays marked as
required.
fine-tuning : f01c195288
opw-2003784
closesodoo/odoo#33760
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Create a journal J1 of a given type T with no currency.
Create a journal J2 of type T with a currency Y, default currency of company C.
Invoices of type T are created with journal J1 by default.
However, if the currency Y is explicitly set in the context, it will be created
with journal J2, even in company C. In that case J2 will be selected,
because the currency is explicitly set in context.
Now suppose we have a journal J3 of type T with a currency Y', different from
the currency of company C.
Give a lower sequence index to J3 than to J1.
Create an invoice with no currency in context.
Then J3 will be selected despite not being on the correct currency, because
no currency condition has been put in the domain.
We solve these two bugs by always adding the clause in the domain,
and adding that the currency can not be set in the case of the company currency.
opw 2002748
closesodoo/odoo#33795
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Sébastien Theys