- nothing tracked
The "register components" button shouldn't appear, the receipt looks normal.
- finished products tracked
The "register components" button shouldn't appear, the receipt looks normal.
- finished products not tracked and components tracked
The "register components" button appear and the burger redirects to "Produce" wizard. The user should record all the productions before being able to access SML through the burger wizard. He cannot force any SML for subcontracted products with tracked components before having recorded all the productions.
- finished products and components tracked
The "register components" button appear and the burger redirects to "Produce" wizard. The user should record all the productions before being able to access SML through the burger wizard. He cannot force any SML for subcontracted products with tracked components before having recorded all the productions.
Due to subcontracting. Some documents are hidden from the users since
they are there to ease technicaly. However they are linked to useful
documents and we want to avoid to log an activity on them.
Usecase to reproduce:
- Validate a purchase_order with a user without group inventory user or manufacturing user.
AccessError on operation read for BoM. A purchase user should be able
to validate an order independently of the documents that will be
generate.
Allow to do a dropshipping with a subcontractor.
If the product uses the routes drophipping and have
a subcontracting BoM. Then a PO for the subcontractors
will genrate a need in the subcontracting location for
the required components.
A module is needed because the picking_type_id for dropshipping
do not have a warehouse_id. The warehouse_id is needed in order to
know from which warehouse the subcontracting components should be
deliver.
Test the flow when a product is set as resupply on subcontract
and not MTO, it should be trigger by a reordering rule and not
by a subcontracting receipt.
When a move is created from a location A to a location B and not
via a rule but it wants to apply the rule logic in order to know
if a move is MTS or MTO then _adjust_procure_method is called.
It will check if a rule between A and B for the selected product/
category/warehouse and if it exists it will apply the rule procure
method to the move. If not it will check if the route MTO is ticked,
and will set the move as MTO even if no rule exist. It could be
miss understanding by the user that have moves MTO without matching
rule. It would be easier to have a single proccess with rule.
Add a test for the following usecase:
- Subcontracted product and components tracked by lot.
- Create a receipt
- Use the register components button in order to prefill quantity
- Correct the final lot on details operation form
If the components have the route resupply subcontractor on order then the
delivery order triggered by the receipt do not have the origin nor the
subcontractor partner. This commit update the procurement group in
order to add those information and propagate it.
due to commit 108ee65af2a88d61526dc047043138bddc3f9b63#diff-99ad190cf09687f6efdebc1f7636062c
picking type for subcontracting order use field use_create_components_lots
instead of classic picking type.
Replace the type subcontractor on the partner.
Instead replace it by a property for a subcontracting location.
The purpose is to have a simplier configuration. The user would
just need to add the partner on the BoM in order to start a
subcontracting process.
Create two moves with a product MTO and the same SO.
Confirm them. It will generate a new picking without origin.
However the purpose of removing origin on picking is to avoid
an endless enumaration of all documents but if they only have
one origin it should be display.
In this case, the origin was ignored because moves.mapped('origins')
result in a list of ['doc_origin','doc_origin'] and have a length
of 2 because .mapped do not return a distinct set on fields different
than Many2one, one2Many and M2M.
Currently, the subcontract picking present multiple difficulties:
- The user has to introduce multiple time the lot produced.
In register components button and then create a new move line with
the show details operation button.
- Same problem with the correction system. The user has to modify the
lot in details operation and then go on the subcontract production and
unlock and edit it.
In order to facilitate those behavior. A move line will be automaticaly
created during the register components process. Also the subcontract
moves for components will be available in the detail operations tab.
Usecase to reproduce:
- Create a receipt of 1 units of a subcontracted product
- Receive 2
- Validate the receipt
-> An extra move for subcontractor of 1 has been validated but a
new move of 2 still in waiting availability and can not be
validated.
It happens due to action_done that will validate existing subcontract
order (with the initial quantity). Then the move is validated and an
extra move is created and merged in the first one. This new merged
move of 2 is then confirmed and validated. That will recreate a
subcontract order of 2 that will not be validated since it was validated
in the picking action_done at the start.
This commit will modify:
- action_done on move in order to validate the subcontract order after
the move validation and the new subcontract order creation too.
- action_confirm in order to create the subcontract order with the
additional quantity and then merge it to the existing moves.
Usecase to reproduce:
- BoM -> 1 component for 1 final product
- Create a MO with a quanity of 5
- Update the quantity to 6
-> The move finished has an initial demand of 4
Stat button "Attendees" of an event now redirects to Kanban view
of attendees (previously redirected to List view).
Task-ID 1935268
closesodoo/odoo#31621
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Removing these margins makes swipe on 'o_mail_preview'
nicer in enterprise without having blank spaces.
Note that these rules should be in enterprise.
Task ID : 1895453
This allow us to reuse this logic in enterprise when you swipe.
Note that we could have directly called the handler but the name
wasn't appropriate. So we preferred to extract some code in a
well named function.
Task ID : 1895453
As the available Austrian Localization was very basic and migrated for
years without any contribution or consolidation, a complete refactoring
was contributed by WT-IO-IT GmbH to move forward.
closesodoo/odoo#35642
Signed-off-by: Josse Colpaert <jco@openerp.com>
Both the name and the tag_name need to be set as translatable.
As the tag_name is seen by the user for the configuration.
Unlike the financial reports that are linked to multiple countries,
the tax report is linked to just one country. This way it makes sense
to only make it translatable in multilang.
Task: 2042430
closesodoo/odoo#35436
Signed-off-by: Josse Colpaert <jco@openerp.com>
The selection values of a selection field are now stored in database in the
model ir.model.fields.selection
This will allow to have a modular approche on selections and each selection
is now linked to the module that declared it.
Previously to this change, the selections were linked to the field, meaning
uninstalling a module had no impact on the selections stored on database.
With this change, the selections will now be translated in the correct module
(having an external id) and the records having a used selection will now be
reset to null.
closesodoo/odoo#30228
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
The deletion of some records can create inconsistencies in the
point_of_sale.
It can create inconsistencies when a session is open, for example if you
delete a partner that can be set on a pos order. You'll also got
problems if you remove an employee and this employee can be used in an
open session.
We also avoid to get point_of_sale config inconsistencies, by deleting
models required by it. If you delete a picking type used in a pos
config or a sequence.
To avoid all this consistencies, we have restricted the deletion of some
records in specific cases.
TASK-ID: 1879971
closesodoo/odoo#35793
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
in this commit, we have set the correct attribute(field's name) to fix
the traceback while we adding a new section on a course using website
task-2053822
closesodoo/odoo#35786
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The CSS for receipts to be printed was not loaded correctly in the POS.
The format of the receipt was wrong and the printing failed.
closesodoo/odoo#35768
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
The goal of this commit is to provide better readability on kanban cards.
It will:
- move deadline to the bottom of the card
- add a line-break between project and customer
- display task deadline not in italic
related task 2009563
closesodoo/odoo#34599
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
For some fields (especially employees) it is nice to see a picture of the model on the gantt row in order to quicly identify which record is concerned. This is obvious for employees where we display their avatar picture but might be handy for other models as well. This commit introduces this functionality.
In order to activate it you should declare a avatars attribute on the gantt arch.
It is a python dict which keys are the fields name for which a thumbnail should be displayed (ie: 'employee_id') and the values are the fields on that model that hold the image (ie: 'image_small).
If none is defined or the row isn't currently grouped by this field, nothing is displayed.
NB: it is expected that the field name (key) is a relational field to another model which has a *image* field.
related task 2009563, 2000719, 2024216
Aliasing the fields in the select clause of the task report allow to do joins latter when inheriting from this object without getting ambiguous fields errors.
related task 2009563
This commit move some code to be able to override
Bootstrap popover in web_enterprise for mobile.
Task ID: 2052506
closesodoo/odoo#35727
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This merge adds the website_visitor model that will be used
to track website visitor activity (page viewed, number of visits and
more general info about the visitor (country, lang, etc..)
This model will, in later commit, be used to send chat requests
and push notification from the operators (or backend users)
directly to the visitor.
To keep a detailed history of the visitor page views,
we add a website.visitor.page model that makes the link
between visitor and website.page but that keeps the visit date.
So that we can see if a visitor went mulitple times
on the same page and when. It's useful to see his last page views.
If a website_visitor submit a contact form (and becomes a lead),
the website_visitor is linked to the crm.lead.
If a website_visitor logs in,
the website_visitor is linked to the user's res.partner.
This also allows a livechat operator to send a chat request to a
connected and available website_visitor.
See sub commits for more detailed informations about functional flows
and technical changes/decisions.
Task : https://www.odoo.com/web?#id=2028059&action=327&model=project.task&view_type=form&menu_id=4720
Linked to enterprise PR odoo/enterprise#4834closesodoo/odoo#34624
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since introduction of website_visitor,
we don't need to identifiy the lead with a lead_id cookie.
The visitor is identified and if a lead is created with the
contact form, the lead is created and linked to the visitor.
To avoid losing data, each time a visitor send a contact form,
it creates a new lead. All those leads are linked between them
via the website_visitor.
As the website_visitor already has the lang set on itself,
there is no reason to keep the lang_id of crm_lead at enterprise
side. So that lang_id on crm.lead has been moved to community.
This commit is directly linked to another one in enterprise
See https://github.com/odoo/enterprise/pull/4834 to get more details.
Task ID : 2028059
PR #34624
This commit allows a livechat operator to send a chat request to a
connected and available website_visitor.
A visitor is considered as connected if his last tracked website.page request
was within the last 5 minutes.
A visitor is available if he doesn't have an active livechat conversation
(mail_channel with type = livechat).
- If another operator sent him a chat request
- Or if the visitor asked himself to speak with an operator
(via the normal and existing flow)
A livechat conversation is active while the visitor haven't left the conversation.
An operator cannot leave a livechat conversation, only the visitor can.
The flow to send a chat request:
- On the visitor view (tree or form), operator click on 'send chat request'
(button or livechat icon)
- A empty conversation with the visitor pops up at operator side.
- While the operator didn't send a message, the visitor won't see the conversation.
- The operator can type a message to the user
- If the operator close the chat without sending any messages,
the chat request AND the mail_channel are both deleted.
In this case, the visitor is then available to send him a new chat request.
- If the operator send a message, at the visitor's next action
(page navigation on pages that allows livechat, based on livechat rules),
the conversation will pop up at visitor side, using the livechat button widget.
The visitor won't be able to request a livechat conversation with an operator until
he leaves the chat requested by the operator.
- Once the visitor leaves (with or without rating) the conversation :
- the operator is notified that the visitor has left the conversation
- the chat request is deleted to keep the chat request table clean and minimal
- the livechat conversation if set to inactive.
- The visitor is now available again to send him a chat request.
This feature uses the already existing livechat_session cookie mechanism,
so no further code modification was needed to make this work.
It's directly integrated is existing livechat flow.
The chat_request model is only useful to quickly check if a visitor has a chat request
and to send the livechat conversation info to the visitor via the livechat_session cookie.
This commit also add a website_visitor banner info on discuss view :
To be able to quickly see all the relevant information of a website visitor
while talking with in discuss view, a fixed banner have been added.
Only the discuss view will benefit from this because detached chatter window
is to small to display such banner.
Task ID: 34624
PR #2028059
What was going on here is that when the operator start the discussion with the visitor
and the visitor navigates to a new page, the livechat button widget checks the
cookie and see there is already a active conversation.
It loads the mail_channel and write all the history of the conversation.
So the first message is writting a first time.
Then, it handles the notifications. As the visitor did not receive the
first message notification yet, the first message notification comes up
and the widget handle it. Adding the message a second time.
To avoid this, we just stop the notification handling
if the message is already present in the conversation.
Task ID: 2028059
PR #34624
If a website_visitor submit a contact form (and becomes a lead),
the website_visitor is linked to the crm.lead.
the website visitor name is than adapted to match the name of
the first crm.lead linked to the visitor, ONLY if the visitor doesn't
already have a res.partner.
A visitor can have multiple crm.lead as he can send multiple
contact form and create multiple leads.
Task ID: 34624
PR #2028059
This commit adds the website_visitor model that will be used
to track website visitor activity (page viewed, number of visits and
more general info about the visitor (country, lang, etc..)
This model will, in later commit, be used to send chat requests
and push notification from the operators (or backend users)
directly to the visitor.
- A website_visitor is created once the visitor is requesting
a website.page that is tracked.
- A website_visitor is considered as connected if his last tracked
website_page request is within the last 5 minutes.
- The number of visits for a website_visitor is incremented
if his last tracked website_page request was at least 8 hours ago.
- A website_visitor is only handled by the system. Users cannot
create, edit or delete a website_visitor.
- A unique website_visitor is created per website.
That means that the same real person can triggers multiple visitor
creation if visits multiple websites.
This is because, for livechat purpose on later commit, for example,
the chat request can be created on the correct livecaht channel
(linked to the correct website)
- The visitor is recognized via his cookie (visitor_id). So if the visitor
flush his cookies, a new visitor will be created the next time he will
request a tracked website_page.
- Link user's res.partner to website.visitor.
If a website_visitor log in
(a visitor that has visitor_id in his cookie),
the website_visitor is linked to the res.partner.
The website visitor name is than adapted to match the name of
the first res.partner linked to the visitor.
A visitor can have multiple partners as the same session
can be used by multiple person (one PC for a team for example).
To keep a detailed history of the visitor page views,
we add a website.visitor.page model that makes the link
between visitor and website.page but that keeps the visit date.
So that we can see if a visitor went mulitple times
on the same page and when. It's usefull to see his last page views.
Task ID : 2028059
PR #34624
When create a return from a delivery order, the field `to_return` must
be True, so the delivered quantity of the sale order will be updated by
default. But it wasn't the case before this commit !
Thus, adds a test to be aware in the case something goes wrong again.
Task #2050183closesodoo/odoo#35733
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Arnold Moyaux