Synchronize only timezone value from event type if set. Otherwise keep the
existing one or fallback on user defined one.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 10094beec786ef0ea6e32e621d4e026fedeba19a
We consider that changing category should always update value of those fields
to avoid having oddly-configured events. Indeed if you choose a new event
category most of its configuration should be propagated to the event.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: f7e747886caebf37d60037a3e0e760f95bd0fb68
PURPOSE
Fix various issues spotted in 13.3 when testing event. Notably
computation of 2many fields coming from template.
SPECIFICATIONS
When updating template on an event, one2many fields should be better managed.
Previous heuristic was
* if event type uses o2m configuration (use_ticket / _schedule / _question)
and has lines
* erase existing lines;
* create new lines based on old one;
This has the drawback of loosing information of what is sent (mail) or
sold (tickets) or answered( questions). Another drawback is that only
types having line are synchronized. This means that if updating several
times the event type you could end up with an XMas configuration with
lines coming from different event types, depending on their o2m configuration.
We choose a better heuristic that should solve this issue
* every time we change type, independently of its use_* field that is used
mainly for UX on the type itself:
* erase existing lines that have not been used yet (no mail sent, no
ticket linked to registrations, no answer linked to registrations)
* create new lines based on old one; if type has no lines, event will
have its old empty line erased as well;
It means that we try to synchronize more the type to the event while keeping
configuration line already used in some registrations.
Also provide some other fixes like deletion restrictions or better domain
for UX purpose. See sub commits for more details.
LINKS
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 645f70cad033083e82a3ef9102c694c331badef9
Co-authored-by: Sebastien Mottet <oms@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Purpose of this commit is to add some tests related to event_type to event
configuration. Indeed changing a type on an event may change its sub models
(mails, tickets, questions). Asserting current behavior is necessary before
tweaking behavior considered as to be improved.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 6fb42e70164bab05681b11f1e76e320db0266445
Spotted when working on event fixes.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: f5440420b07baf32e9a6b9f84fead4f140fb921a
current expression implies that any payment of a quote from the portal (/my/quotes) will try to save a token whenever the user says they want the customer to pay online, which seems bizarre. Normally you'd only want that for quotes with subscription products, and there is an override of that method in sale_subscription for that specific case.
closesodoo/odoo#53024
X-original-commit: 47f7230cd38c4e5a2f644a04f87fa0b5a844f73b
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce the bug:
- Let's consider a storable product P with automatic inventory valuation and re-invoicing policy at cost
- Create a SO with P, generate an invoice I and validate I
Bug:
A new line was added in the SO (related to the anglo saxon move line)
PS: In 12.0, no line was added on the SO when I was validated.
opw:2247915
closesodoo/odoo#53011
X-original-commit: c5cd7329529cfa27d1f65217bd54042642711048
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Create flexible BOM for product P
- Create a MO for 5 units
- Produce 3 units
- Post the inventory
- Cancel the MO
The MO remains 'In Progress'.
In case of a flexible BOM, the quantity produced is compared to the
quantity to produce to know whether the MO should be done. In this
specific case, however, the MO should be closed.
It's not possible to rely on the move states in this case, so we
force the MO state.
opw-2270279
closesodoo/odoo#53010
X-original-commit: c99fe9dc5b5054d8d92b7283ad9f27f150de410b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- install crm
- go to crm > configuration > settings > activate leads
- go to a contact > click the "opportunity" smart button >
create an opportunity > select the newly created opportunity > click
the "meetings" smart button
Previous behavior:
meetings are filtered with 'search_default_opportunity_id' set to active_id.
active_id is referring to the partner_id in this case. this leads to
a cache miss error.
Current behavior:
meetings are filtered by the right opportunity (current id).
opw-2272325
closesodoo/odoo#53013
X-original-commit: b9abc757da3034209b083c4ba862edd3865f7637
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
ACLs on the wizard lines should match that of the wizard, otherwise
ERP managers can see the action but get an error as soon as they open
the wizard.
Since ERP managers have write access on arbitrary users, that's
probably the right group to use.
Task 2275134
closesodoo/odoo#53007
X-original-commit: 657d44f08c402bc0547b7cbb01c2d447e641d062
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
Ease manufacturing order edition in allowing to edit in the tree view.
Consider that one manufacturing order = 1LN/SN and create back-orders
in case several of them should be produced in the same MO.
Ease definition of operations and their different steps by allowing to
do it in the same BoM screen.
joint work Simon Lejeune <sle@openerp.com>
joint work Arnold Moyaux <arm@odoo.com>
joint work William Henrotin <whe@odoo.com>
joint work =?UTF-8?q?R=C3=A9my=20Voet=20=28ryv=29?= <ryv@odoo.com>
joint work yhu-odoo <yhu@odoo.com>
joint work "Tiffany Chang (tic)" <tic@odoo.com>
task-2241471
closesodoo/odoo#52949
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Activate multicurrency and use a 1.5 rate on USD to EUR (to ease
calculations)
- Create two customer invoices in EUR (company is in USD) for two
different partners (e.g. partner1 and partner2) with only one line and
an amount of 100 EUR (removed the tax as well so that payment term line
is 150 USD on receivable account)
- On the "Invoices Matching Rule" reconciliation model:
1. Set Amount Matching to 90%
2. Define any account for the counterpart
3. Remove "Same Currency Matching"
4. Ensure "Partner Is Set & Matches" is marked
- Then create a new bank statement with two lines as follows:
1. dummy label, partner1, 140 USD
2. dummy label, partner2, 100 USD
- When clicking on reconcile,
1. the line for partner1 is not matched
2. the line for partner2 is matched
This occur because the amount from the invoice is not correctly
converted in company currency before making the check with the bank
statement amounts
opw-2261134
closesodoo/odoo#52529
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Bunch of last minute fixes including:
- serial handling in tablet view
- expected durations and backorders
- button unplan unlinks the leave but the computed aren't recomputed
then we need to manually set the date_planned_start/finished
then we need to not propagate them on the related document
(move/production) because they are required
- operation company_id wrongly set
task-2241471
Removed abstract workorder
Removed the integration of expiry wizard in tablet view since it should
be moved in enterprise in the tablet view implementation (not possible
to set consumed lot on workorders on community anymore)
Refactor _set_quantity_done to use ORM command in order to not return a
dict with vals to_create/to_write
task-2241471
- The Scheduled Date can't be change if the MO have some planned WO.
(WO defines the scheduled date of the MO)
- Now the Scheduled Date 'date_planned_start' is set by default
with the deadline date if there is or now if there isn't (same than before).
- For MO, 'plan_date_finished' is now invisible. But keep the field
because it is used to set the date_expected of finished moves.
- Change the plan behaviour: Plan depending of the scheduled date if
this one is bigger than now, else try to plan as soon as possible.
task-2241471
Instead using production name + name of WO as name in the
leave record, use the display name of WO to reprensent uniquely
the leave (even this record is not really reprensent in views).
task-2241471
Previously, when we upate the "Quantity to Produce" on a MO, we update
the components to consume according to the BOM we use. After this
commit, we now update the components according their current number set
on the MO.
For example, if we have a MO to use x component A to produce y product
B. When we update the number y to z, the number of A we want to consume
will be updated from x to x / y * z, regardless of the setting on the
BOM. If multiple components are used, all components will be updated
according to this rule.
Task: 2241471
This commit updates 4 features related to a MO being locked/unlocked.
1. Manufacturing orders are by default unlocked. A new configuration
setting has been added so users can set the default to be locked.
This setting only applies to new manufacturing orders after the setting
has been changed.
2. A MO now shows the same button options regardless if it is
locked/unlocked ('scrap', 'cancel', 'unreserve')
3. Workers can always change "Consumed Quantities"/"Produced" when
clicking on a component/finished product line unless state=Done and MO
is_locked. This includes adding new components/finished products.
4. Workers can now change "To Consume" quantity when clicking on a
component line, unlocked, and not in states 'Done' or 'Cancel'.
This is part of specification 6-Lock/Unlock of overall Editing in MO
form and backorders task.
Task: 2241471
On a move line tracked by serial number. Moving two pieces for
a serial number trigger a warning explaining that the quantity
should be 1 or 0. However modify the unit of measure from unit to
dozen is not a problem.
task-2241471
Currently the related on the property use the company in the context and
not on the current object. It implies that a raw move created on the MO
form view will have the wrong destination location and trigger the
check company error.
Use a compute instead of related.
task-2241471
Now, by default, a Bill of Material have a flexible
consumption instead of strict consumption. Also
add new consumption choice: a flexible consumption
but with a warning when the bom isn't respected.
Also, now, the strict (a new warning option) consumption
is checked only when we try to mark as done the MO.
task-2241471
Following v13, newId records are instances of NewID and are ignored from
any `read_group` call. This breaks an important feature: when encoding a
stock move line (thus, in an onchange context), the `quantity_done` field
of stock move should be recomputed.
task-2241471
Allow to "backorder" a production, meaning create another manufacturing
order with the quantity remaining to produce. We also use the
reservation of the first order on the next ones by using
`post_inventory` on the first one and moving the newly created stock
moves to the backorder.
We introduce a wizard similar to the one in stock.
Backorders have a sub-sequence.
Backorders are linked together through the procurement group.
We allow creating a backorder even if workorders are running by closing
them, the backorder will call `button_plan` and create its own.
task-2241471
Set the operations directly on the Bill of Material.
Duplicate the demo data where a routing was shared.
Adapt the tests.
Remove the following feature:
- set the same routing on parent and kit child bom
- when planning, if the component of the kit have the same operation
than a component of the parent bom, merge these operations
task-2241471
- Activate multicurrency and use a 1.5 rate on USD to EUR (to ease
calculations)
- Create two customer invoices in EUR (company is in USD) for two
different partners (e.g. partner1 and partner2) with only one line and
an amount of 100 EUR (removed the tax as well so that payment term line
is 150 USD on receivable account)
- On the "Invoices Matching Rule" reconciliation model:
1. Set Amount Matching to 90%
2. Define any account for the counterpart
3. Remove "Same Currency Matching"
4. Ensure "Partner Is Set & Matches" is marked
- Then create a new bank statement with two lines as follows:
1. dummy label, partner1, 140 USD
2. dummy label, partner2, 100 USD
- When clicking on reconcile,
1. the line for partner1 is not matched (although it respects the 90%
param)
So 'Match amount' is still effective, while it is not shown in the view.
This should not occur. Removing the invisiblity conditions to avoid
the inconsistency.
opw-2261134
Add internal project to ease the onboarding
Move timer to enterprise
taskID: 2217930
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#52585
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Done in commuity so that other modules can inherit from it, but only
used in enterprise's l10n_au_reports for now.
closesodoo/odoo#49581
Related: odoo/enterprise#9907
Signed-off-by: Josse Colpaert <jco@openerp.com>
Add new taxes and fiscal positions managing the new taxes.
The taxes set on the services are replaced by the taxes setting the
right tags on the move lines in case of suppliers that should appear in
the TPAR.
In case the ABN was not quoted, a special tax with a negative line
computes the tax withheld should be used.
Help search taxes more easily by adding an applicability field stating
that the tax should be used only on goods or on services. If not set,
can be used anywhere.
Thibault Delavallée