Several improvements in order to improve user interface are done here.
[IMP] purchase: Prevent create PO&RFQ in calendar
It was possible to create PO's and RFQ's from the calendar view.
The Product Owner wanted to prevent the users from doing so.
[IMP] purchase: Add tooltip to Receipt Date
[FIX] purchase: Align report & stat button data on product form
The use of Last 365 days time_range in the purchase analysis was automatically
excluding today's purchases wich was confusing users as the stat button info
was taking those into account.
Different behaviours were implemented for product template and product product
in the filters that were used which makes no sense.
Use of context_today() instead of datetime.now() in order to take the user's
timezone into account.
[IMP] purchase: Use relevant dates for RFQ's and PO's in calendar view
The date used in order to display RFQs and POs in the calendar was date_planned
which is not mandatory and so not always filled. It has been decided to use the
order_date for the RFQ's and date_approve for PO's.
[IMP] purchase_requisition: Making Agreement selection type more explicit
[IMP] purchase: Show UOM menu only if installed
[IMP] purchase: Add product variant in settings
[IMP] purchase: Remove Favorites predefined filters
[IMP] purchase: Rephrase PO action helper
[IMP] purchase: Allow open/edit Agreement Type
[IMP] purchase: Rephrase RFQ action helper
[IMP] purchase: Remove PO's and RFQ's name from fields in calendar
The Product Owner originally wanted to have a link on the PO name field
that was shown in the calendat popover. As the Edit button already allows
to edit the PO's or RFQ's from the popover it was decided to simply remove
the field (as it was already displayed at the top of the popover)
[IMP] purchase: Open the right view when click on Reporting top menu
Task ID #2196688Closes#47810
Related: odoo/enterprise#9294
Related: odoo/upgrade#961
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit abef168389 adds the fields
'product_description_variant' on mrp.production and purchase.requisition
models. This text is taken from the product variant.
This commit make them invisible in case they are empty.
closesodoo/odoo#47716
Related: odoo/upgrade#948
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose of this task is to prevent users from setting portal users on
internal documents by mistake, and preventing noise and performance
issues resulting from loading all the portal users in those fields.
This commit fixes internal many2x fields to res.users which are now
restricted to internal users by setting domain (share=false) on form view.
closesodoo/odoo#47553
Taskid: 2172779
Related: https://github.com/odoo/enterprise/pull/9204
Related: odoo/enterprise#9204
Closes: #47553
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
Followup on c058562d73
Before this commit, Domain for `purchase_ok` on the field `product_id` was applied on the field level which was Replaced by multi-company domain on views.
With this commit, we combine both domains to Display only `Can be Purchased` products.
closesodoo/odoo#47778
X-original-commit: 842b8a383b7868a89cbd3d81b0065cce37606db4
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
_prepapre_tender_values in only call from purchase_requisition_stock.
It's not needed to have 2 functions, everything should be in
purchase_requisition_stock.
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If a view is present multiple times in the same module, the "last
instance" is going to win (by replacing any previous instance's arch
with its own).
Most cases of duplications are probably views which got moved then
either not removed (from the original location) or revived (through a
forward-port), the first instance can just be removed entirely.
For the few which seemed to be more than just trivial mistakes, merge
the two views instead.
closesodoo/odoo#44463
Related: odoo/enterprise#8107
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
- install contacts and purchase
- go to purchase > configuration > settings > activate "purchase agreements"
- go to general settings and activate multi-currency
- go to contacts > select a contact > edit > sale & purchase > change the currency
- go to purchase > purchase agreements > create
- change the agreement to a blanket order > add your modified contact as the vendor
Previous behavior:
the currency is not updated
Current behavior:
the currency is updated on vendor change
opw-2177431
closesodoo/odoo#43877
X-original-commit: 764135630949eb01cb2b3a4a19d6ec5b1bd39400
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
1/ When the new database is created without demo data, the admin has a
'silhouette' as a default picture. When a new user is created without
picture given by the current user, the new user will have a 'silhouette'
as a default profile picture.
2/ web: image for fa-user-slash. This image will be used when a record is
unassigned.
3/ web, *: Change placeholder by default when record is unassigned.
We want to have a fa-user-slash icon when a record is unassigned instead
of 'placeholder.png'. A method is created in the BaseModel to have a
generic method to change easily the placeholder for other models.
4/ Adapt kanban test to keep the same behaviour. Attention the behaviour is
a bit different. Because, now the default image is given by the server to
change easily the default image when a record doesn't have an image.
Thus, we don't say if it's the default placeholder, but we can say it's
not the same image of the record (in this test, the record, it's the
partner).
5/ misc: display 'Unassigned' in the hover on kanban cards if record is unassigned
closesodoo/odoo#41356
Taskid: 2060206
Related: odoo/enterprise#7758
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: jdoutreloux <jud@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Previously, when grouped by state, user was able to drag
and drop kanban boxes to alter the state of an unbuild, a
purchase requistion or work order. However the state should
be readlonly and could only be modify via public methods on
those objects. Those methods do additional required stuff than
just modifying the state.
task-2087309
closesodoo/odoo#40759
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Use correct company to get fiscal positions and properties
Ensure company used to fetch fiscal positions is always the correct one
when coming from a company restricted model (company_id required, or
related.required).
NB: if the company_id isn't defined, with_company doesn't change the
environment.
purchase: get_fiscal_position doesn't consider company_id ctxt key
others: properties were accessed with potentially the wrong company.
Usecase to reproduce:
- Create a purchase requistion with type Call For Tender
- Update a line and set the price to zero.
UserError 'You cannot confirm the blanket order without price.' raised.
It happens because the write don't process the same check than create
and don't check if the purchase_requistion is a blanket order or a call
for tender. It also doens't check the current state of the
purchase_requisition.
closesodoo/odoo#39980
Task: 2120211
X-original-commit: 7d69f01477a2d5dd93974737978d7af11cfc8b6d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Use correct company to get fiscal positions and properties
Ensure company used to fetch fiscal positions is always the correct one
when coming from a company restricted model (company_id required, or
related.required).
purchase: get_fiscal_position doesn't consider company_id ctxt key
others: properties were accessed with potentially the wrong company.
* use an editable tree to edit the supplier info
* keep the original forms because they're used in the "vendor pricelist"
menuitem
* updated tour
* change the position of requisition_id
Task-2029380
closesodoo/odoo#35972
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
*: account
crm
event
fleet
hr_expense
hr_holidays
hr_recruitment
mail
maintenance
mrp
note
project
purchase_requisition
repair
stock_landed_costs
stock_picking_batch
survey
website_event_track
This commit is making sure that the exception activities filters are
only defined where it make sense (i.e. where the system can actually
create an exception activity).
We have therefore removed 'exception activities' filters where the
system won't be creating any.
Task-2056425
closes odoo/odoo#36027
Closes: #36027
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Pre-filter lines based on known products.
Closes#36854
opw-2074824
closesodoo/odoo#37383
X-commit: bd3997b79a075a24afce749474fc32b43ac8c03f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When a blanket order is opened, a supplier info is created and should be
used in priority over a regular supplier info with the same values.
That's what rev [0] tried to do but there was some mistakes: the
`purchase_requisition_id` field added in the order is ignored since it
isn't stored and the test didn't failed because the created blanket has
a lower price unit than the regular supplier info, meaning it is used in
priority. Setting the same price unit (50) result in the new purchase
order line merged in the first one.
Do not re-implement the same order.
Adapt the test now that we know the order didn't work (see rev[1]). The
user has to manually set a higher priority to the supplier info
generated by the purchase requisition.
[0] e85838d358
[1] 2ac4f2ee0fclosesodoo/odoo#36840
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When .with_context() is called with a dictionary as 1st positional
argument, it will replace context (and not modify the referenced keys)
It may create bugs when losing the content of the context (e.g. remove
partner's language)
This is a cherry-pick to saas-12.5 of odoo/odoo#36164 of the logistic
part as discussed
closesodoo/odoo#36690
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Slovenian language, as many others languages, is not present in the
beta/master projects in Transifex.
For some reason, Transiflex removed all current translations, this was
already fixed in 12, but as there are not automatic forward-port for
translations, this is a manual forward-port.
opw-2060055
closesodoo/odoo#36374
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Denis Ledoux