PURPOSE
Create event registrations in batch. It will allow to customize group-creation
of registrations, notably with automated rules for crm / event synchronization.
SPECIFICATIONS
Improve registration editor to create registrations in batch. Also be less
dependent from context in its code, currently a bit weird.
Move creation of registrations based on line from _action_confirm to
action_confirm. Indeed it adds complexity and we are unsure it really helps
having two methods.
Update based on lines now create registrations in batch instead of one by one.
LINKS
Task ID 2258685
Prepare Task ID 2166679 (create leads from registrations)
PR odoo/odoo#51341
Co-Authored-By: Jeremy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Create event registrations in batch. It will allow to customize group-creation
of registrations, notably with automated rules for crm / event synchronization.
SPECIFICATIONS
Instead of creating registrations one by one when processing registration
form details, simply batch-ize their creation.
Instead of creating registrations one by one when adding a new line in cart
simply let website_event handle its job, or the confirmation action of a
sale order that already populates registrations.
Creating registrations when adding a cart line has no real use as we have
no specific information to create that registration. It is better to let
the flow finish and create additional registrations in batch once SO is
confirmed.
LINKS
Task ID 2258685
Prepare Task ID 2166679 (create leads from registrations)
PR odoo/odoo#51341
Co-Authored-By: Jeremy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
In this commit we add some tests related to sale order / event registrations
synchronization, notably
* registrations automatically created when _update_registrations of an SO
line is called, for example at SO confirmation;
* using the registration editor;
LINKS
Task ID 2258685
Prepare Task ID 2166679 (create leads from registrations)
PR odoo/odoo#51341
In fb051d3420 there was some changes on drag and drop of chatter
windows, but this would break the drag and drop of summernote because it
wait for document.drop event for hiding the drop zone.
opw-2259522
closes#51448closesodoo/odoo#51478
X-original-commit: 4aaf5b1f562f4cd30e05b020741eb936f6e20a20
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps to reproduce the bug:
- Go to inventory > settings > enable multiple warehouses
- Let's consider the default warehouse W
- Create a new warehouses NW
- Enable debug mode
- Go to sales > create a new quotation
- Go to the other information tab > change default warehouse W to the newly created warehouse NW
- Click on the bug > go to set defaults > warehouse=NW > save default
- Refresh the page > Go to sales > create a new quotation
- Go to other information tab > observe the warehouse
Bug:
The warehouse was W instead of NW
opw:2254084
closesodoo/odoo#51237
X-original-commit: 80c0821c0e902a68f15a839ff7d2f6beece43dc3
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Issue
- Install Contacts
- Create a contact: Company A
- Add a contact to that company: John
- Add a private address for John
- Save
- Change John's company
- Go back
- Look for the private address
The display_name contains the old
company name
Cause
The private address display_name is
not recomputed when the contact's
company changes.
Solution
Recompute child_ids display_name
when the company changes.
OPW-2253785
closesodoo/odoo#51450
X-original-commit: b112c8921eec60c63cead37c74946d06b499eb6a
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
When generating a payment link through the payment link wizard, the
company was previously not included. This could cause accounting issues
if the acquirer displayed to the customer were not part of the same
company as the underlying document that generated the link.
This commit add a new computed field 'company_id' on the wizard model
that gets computed based on the underlying model; this field will be
included in links generated by the wizard to limit the acquirers
displayed to those of the that company, preventing extra acocunting
steps (interco reconciliation).
opw-2254011
closesodoo/odoo#51441
X-original-commit: a6fcd7e0cfec8d4c62620a53b5fa806561e239af
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Purpose
=======
By using the user's related company to create a employee, we prevent
creating several employees for the same users on the basic flow.
But this is exactly the way we want people to use the system.
Example: Jojo is working in Belgium, has a belgian employee liked
to a belgian user in the system.
Now Jojo is about to work during 1 year in another company, based in
the USA. Jojo wants another employee, to manage the HR things
properly (payroll, ...), but he doesn't want to have 2 users, he
prefer to manage all its notifications in the same place.
We create another employee for Jojo, in the US company.
So instead of creating the employee in the user's company (Belgian),
as it would raise an error for the second employee, we should use the
contextual company instead, allowing to create the second employee
smoothly.
closesodoo/odoo#51435
X-original-commit: 0318f0acc5e98950c274c90a86a94d4588d2966d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the `Create Employee` button was not visible if user is linked to employee in any other company as the domain was based on `employee_count`. (Which represents Employee belongs to all companies)
With this commit, we check for `employee_id` which makes sure if the user has linked Employee for currently activated company.
Followup on 95564bcd2c
X-original-commit: cb9ac24caea53615e2808a36e850939a1ccaa041
- Install Inventory, base_automation
- Create an automated action on stock.quant, trigger on Update, code
raise Warning('My Warning')
- Create a transfer on a stockable product with e.g. 10 quantity on hand
e.g. Initial demand is 9
⁻ Mark as todo and Check Availability: on the transfer the reserved
quantity is not updated, but on the stock.quant it is updated to 9.
You can check availability again and nothing will happen on the
transfer, the stock.quant "Reserved" will be updated each time though.
You can update the quantity on hand to 0, and you will get
products with Reserved Quantity when Quantity in Hand is 0, and no
MO/Transfer or any other activity holding the reservation.
Adding the rollback when exception is raised
opw-2245109
closesodoo/odoo#51429
X-original-commit: 3f9ac9d3bb507eafe3c074ae817641b9d9dc1c87
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate routing
- Go to Inventory > Deliveries > New Planned Transfer
- Add a line
=> the 'Demand' field is editable
- Save
- Edit
=> the 'Demand' field is not editable anymore
The field should be editable as long as the picking is draft.
It seems working at creation because the fields `show_operations` and
`is_locked` are not yet computed yet. It happens because `picking_id` is
not in the tree view.
We change the read-only condition: if `is_initial_demand_editable` is
`True`, the field is editable.
opw-2257498
closesodoo/odoo#51428
X-original-commit: 51d4d95b186777a740cf98803148df593a71f0b9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of the task is to remove the needaction message counter from
kanban view due to below reason:
- The user has access to unread messages on records from the discuss
item in the systray.
- It is irrelevant for user handling notifications through their mail
client
- It is only less UI item to worry about on the kanban views (as
features increase, we need to be careful not to clutter the views)
- The user can still use the message_needaction filter to get records
with unread messages
So in this commit we removed the need action counter from all the
kanban view.
closes odoo/odoo#51299
Taskid: 2257624
Closes: #51299
Related: odoo/enterprise#10613
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit makes easier to select records in list views, by
extending the clickable area to the whole cell, instead of the
inside of the checkbox.
closesodoo/odoo#51156
Task: 2247387
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
[FIX] account: reconciliation models: don't mix currencies when checking the candidates for applicability of a model
Before that, similiar amount of different currencies could be matched together, regardless of the exchange rate. We now entirely forbid this case from the reconciliation models.
closesodoo/odoo#51153
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
As part of the kanban view cleaning done the below improvement
- When there is no global click on the kanban card, prevent the
'focus shadow' on card so remove the show on kanban record it
will only apply for global click class and quick create.
- On the dashboard opening a dropdown should close any other dropdown.
closes odoo/odoo#50536
Taskid: 2206372
Closes: #50536
Related: odoo/enterprise#10341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
=========================
The goal of this task is to set up some kind of guidelines to make
kanban views consistent.
It is fine having different kanban views, but if a UI element is shared
among several kanban views, it should behave/look the same so the user
knows what to expect.
Kanban views can be split into two types:
==> 'documents' kanbans, such as res.partner, crm.lead, etc.
- those records are created/edited often, numerous
- 'opening' the card means accessing the record
==> 'dashboard' kanbans,such as stock.picking.type,account.journal, etc.
- those records are not created/edited often, there are much less numerous
- usually presented as dashboard, where 'opening' the card means
accessing a set of related 'documents' (clicking on a account.journal
to access account.move, or stock.picking.type to access stock.picking)
- configuration of the 'card record' is done through a dropdown to
access configuration
Here are some guidelines for consistency. Bear in mind that those are
not rules, but guidelines for consistency that we'd like to keep in
mind when designing.
==> 'documents' kanbans
- the record is accessed through global click
- the user avatar is at the bottom right
- the activity widget is at the bottom left (in last position if
there are other elements)
==> 'dashboard' kanbans
- the record is accessed through a 'Configuration' option in the card dropdown
- there is no global click, and therefore no focus shadow
- the dropdown icon (o_kanban_manage_toggle_button) is always visible,
with icon fa-ellipsis-v
- the listview counterpart should be presented as a dedicated
configuration menu, and shouldn't be in the 'dashboard action'
- links in the body of the card are structured as follows: link with
<count>+label, then any additional aggregated metrics (not link) to the right
example https://drive.google.com/file/d/1ZP6HDHTtC7cQ6rDWgqLoPs6U8JCeNVkW/view?usp=sharing
==> global guidelines
- the title font color is #212529, with 500 weight
- the subtitle font color is #666666, with 400 weight
- the font size is 1.083rem
- text overflow is handled through linebreak, not ellipsis
- numerical values are aligned to the right
- the kanban state widget is at the bottom right
SPECIFICATION
=================
AS per guidelines Improved follwing kanban/dashbaord view
- hr_job
- hr_department
- hr_work_entry
- hr_appraisal
- fleet_vehicle
- product_template
- sale_subscription_template
- crm_team
- res_partner
- event
- stock_picking_type
- mrp_eco_type
- maintenance_team
- quality_alert_team
- account_journal
Added the department menu on employee with default kanban view
Added sequence in hr_work_entry list view
TaskID: 2206372
Related Enterprise PR: https://github.com/odoo/enterprise/pull/10341Closes: #50536
- Employees > Configuration > Planning Types and ensure the activity
type "To Do" is set to scheduled date several days after previous
activity (default should be 5 days);
- Check that onboarding Plan has at least 2 activities with activity
type "To Do";
- Click launch plan.
Before this commit, the activity type configuration is ignored and all
activities are due tomorrow.
Now, the activities are due taking into account the activity type
configuration.
opw-2255586
closesodoo/odoo#51423
X-original-commit: c159479d7f714f2ec871cc4b965de3f961160789
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When we build a new box we make a update && upgrade of the raspbian image.
But it upgrade "firmware-brcm80211" from version "1:20190114+rpt4" to "1:20190114+rpt5"
With this update and when Odoo run on the box the "wifi access point" can't be activated
With this commit we unabled the update of this package and keep the "1:20190114+rpt5"
closesodoo/odoo#51409
X-original-commit: 5071867d7733d91e77ecf222a78a5993aca44781
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Add Total Receivable and Total Payable to contacts list view.
Create Vendor Bill for a partner with $0 Receivable and Payable - the
Payable amount is updated in the list view.
Create an invoice for this partner - the Total Payable is changed to $0,
and the Total Receivable is updated in the list view.
Create a Vendor Bill for a partner having a Receivable amount - the
Payable is not updated.
This occured after commit 9920f20e4c
In a situation in which the lines retrieved from the db are arranged
like
|pid| type | val |
|---|-----------|-----|
| 10| payable| 500|
| 14| receivable| 200|
| 14| payable| 300|
line 3 will cancel line 2 because partner credit will be set to false
after the debit update.
Fixing by checking that the same partner has not been processed yet
opw-2250989
closesodoo/odoo#51351
X-original-commit: 0274d61a11c6f5220d6af37a38adafb3e5276224
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Issue
- Install website
- Go to Website->Configuration->Pages
- Group By "View"
- Open and edit "Home" view of "My Website 2"
- Remove "Website" value and save
- It should list 2 same views for same url and no website
under one of the "Home" views
- Go to Configurations->Settings
- Create a new website
Traceback is thrown.
Cause
When fetching default homepage,
it retrieve more then one pages and then try
to assign it as homepage to new website.
Solution
Limit query to one to get only one homepage.
opw-2252208
closesodoo/odoo#51280
X-original-commit: 0698f3b0ccddf77a6c0c02812bb823da2d21b265
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Purpose
=======
The following task implemented new widgets/features in the listview for better UI.
https://www.odoo.com/web#id=2195254&action=327&model=project.task&view_type=form&cids=1&menu_id=4720
The goal of the current task is to use those to upgrade our listviews
Specification
=============
Below are change requests on various listviews.
Remove decoration-bf="message_needaction==True" from every listview in every module.
PRODUCT - stock.view_stock_product_template_tree (product template)
remove all decorations from <tree>
set the following decorations on 'virtual_available' and 'qty_available'
decoration-danger="virtual_available<0"
decoration-warning="virtual_available==0"
also set decoration-bf on 'virtual_available'
apply the same modifications on stock.view_stock_product_tree for product variants
SUBSCRIPTION - sale_subscription.sale_subscription_view_list
remove all decorations from <tree>
'stage_id' field
set <field name="stage_id" widget="badge" decoration-info="stage_category == 'draft'" decoration-success="stage_category == 'progress'"/>
'recurring_next_date' field
set <field name="recurring_next_date" string="Next Invoice" widget="remaining_days" attrs="{'invisible': [('stage_category', '!=', 'progress')]}"/>
set decoration-bf on 'code' and 'recurring_total_incl'
move 'percentage_satisfaction' before 'recurring_total_incl'
set widget="many2one_avatar_user" on 'user_id'
add <field name="activity_ids" widget="list_activity"/> after 'user_id'
ELEARNING - website_slides.slide_channel_view_tree
set widget="many2one_avatar_user" on 'user_id'
'enroll' field
set <field name="enroll" widget="badge" decoration-success="enroll == 'public'" decoration-info="enroll == 'invite'" decoration-warning="enroll == 'payment'"/>
POS - point_of_sale.view_pos_order_tree
remove all decorations from <tree>
'state' field
make visible and move it at the end of the view
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-success="state not in ('draft','cancel')"/>
set decoration-bf on 'name'
APPRAISAL - hr_appraisal.view_hr_appraisal_tree
'state' field
set <field name="state" widget="badge" decoration-info="state in ('new','pending')" decoration-success="state == 'done'"/>
'date_close' field
set <field name="date_close" widget="remaining_days" attrs="{'invisible': ['|',('state','=','done'),('state','=','cancel')]}"/>
PAYMENT - account.view_account_payment_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-success="state == 'posted'"/>
move 'company_id' before 'amount'
CONTRACT - hr_contract.hr_contract_view_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-warning="state == 'close'" decoration-success="state == 'open'"/>
set widget="many2one_avatar_employee" on 'employee_id'
PAYSLIPS - hr_payroll.view_hr_payslip_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-warning="state == 'verify'" decoration-success="state in ('done','paid')"/>
set decoration-bf on 'number' and 'net_wage'
move 'company_id' before 'basic_wage'
set widget="many2one_avatar_employee" on 'employee_id'
SURVEY - survey.survey_tree
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-success="state == 'open'"/>
APPLICATION - hr_recruitment.crm_case_tree_view_job
set widget="date' on 'create_date'
set widget="priority' on 'priority'
set widget="many2one_avatar_user" on 'user_id'
TIME OFF - hr_holidays.hr_leave_view_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-warning="state in ('confirm','validate1')" decoration-success="state == 'validate'"/>
apply the same changes in hr_holidays.hr_leave_allocation_view_tree
closesodoo/odoo#51305
Taskid: 2256589
Related: odoo/enterprise#10614
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Bug
===
Go to CRM, in the lead list view and select a lead without
phone number. Then, click on the action "Send SMS Text Message".
Then, enter in debug mode and go to the SMS form view. The
number will be "0" instead of being empty.
Task-2244195
closesodoo/odoo#51389
X-original-commit: 8805c16bfb1bfb001e674d9a2755ad0e98fcb834
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add the Total Value in the Inventory Valuation tree view.
opw-2254718
closesodoo/odoo#51385
X-original-commit: c3dd38de2d60a40b61f364f1daa004f67b3d5137
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
=======
The noun time off is uncountable. The plural form of time off is also time off.
closesodoo/odoo#51370
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this commit is to improve tracking of opened traces. Notably
a token is added to ensure we do not mess with traces and have unique
tracking URLs.
MIGRATION REMARK
Emails sent before the migration will not be marked as opened anymore after
migration. We recommend to avoid sending statistically important mass mailings
about one week before migrating database. Indeed statistics show that most of
open emails happen within the first week after being sent.
Task 2223146
closesodoo/odoo#49139
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
SPECIFICATIONS: WIZARD CLEANING
Remove email_from and author_id fieles defined on invite wizard. Those are
not used in this wizard (not available in view) and default value is to use
current user. We can simplify this wizard model by removing them.
LINKS
Task ID : 2229048
PR : #49040
Related: odoo/upgrade#1198
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Clean up of the sms form view to match
what is shown in the composer.
Task-2244195
closesodoo/odoo#50465
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In portal an user can say he is interested by a lead and take it. He can also
post a comment. However this comment was not escaped, leading to possible
html injection.
As this comment is used to post a message no real issue occurs. It is sanitized
and behaves like every html content used in message_post. However we do not
want to support html here and therefore escape the content given to message
post.
Task ID 2228921
closesodoo/odoo#50537
X-original-commit: df5345618c4abbe8766a012b08ed90f1706c919a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The SSF had pretty much punted on nested o2m as that's... not usually
a concern because few people are insane enough to put o2ms in their
o2ms in their views. And also because even if somebody did, sometimes
nothing would break because it turns out to be pretty difficult to
actually get into *using* those things.
MRP managed to do it though, and repro-ing required copying over parts
of mrp.production and then understanding why it didn't fail:
* obviously needs an o2m (f1) which contains an o2m (f2), in the
view (an invisible tree inside a visible tree)
* needs an onchange which somehow updates the sub-o2m
* needs to actually trigger an onchange on the root form for f1,
meaning f1 must be a dependency of a compute field or something (here
I just marked every damn field as on_change as the optimisation of
"don't call onchange when there's no need to" doesn't matter)
Also needs to be working on an existing record with existing
lines *and sublines* as the issue occurs with records to update.
The issue here is that `_onchange_values` would clean up f1 e.g. send
nothing for unmodified entries, and only send modified fields
otherwise, but it would only do so for the toplevel, meaning the
sub-level would not go through this step, and could send UPDATE
commands with an `id` field (set to the original value but
still). This would then proceed to blow up while loading the record,
as id fields are not writeable.
The fix is to perform `_onchange_values` recursively. Do that using a
separate helper in order to avoid blowing up on override and whatnot,
or faffling about with weird branching to get the "default" values in
case they're not provided, the root function can get all the relevant
bits and call the helper with them, then the helper does that setup
internally and calls itself directly.
An other issue I stumbled upon when investigating is a similar problem
on *save*, due to an implementation detail of the SSF: UPDATE commands
are fetched lazily.
`_values_to_save` took care of "hydrating" all update commands (and
validating and filtering them) of modified o2m fields, but as it would
not do so recursively a modified f2 would not get properly hydrated
and filtered, and could try to write `None` onto existing records.
closesodoo/odoo#51350
X-original-commit: 3dfb4cfad849936748cc6a5b8f712e100461a86f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Stop using the colorpicker dialog in the colorpalette widget.
Integrate the colorpicker widget in the colorpalette widget. Of course,
the colorpicker behaviors are adapted so that no useless rerendering
of the colorpalette is made on each value change.
The 'reset color' button is now a button like the other colors, no need
for a 'color_reset' event anymore. It is removed and replaced with a
'color_picked' event with color being an empty string. The clear button
now also work on hover.
Also, the topbar colorpalette for text and text background colors now
has the exact same behaviour as the background colorpalette: adding
color preview on hover.
The colorpalette now also closes on 'enter' keypress.
Part of https://github.com/odoo/odoo/pull/46088
task-2195313
closesodoo/odoo#46088
Related: odoo/enterprise#8696
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website, web
Move the colorpicker dialog logic into a colorpicker *widget*, which the
colorpicker dialog will now instantiate.
Part of https://github.com/odoo/odoo/pull/46088
task-2195313
The ColorpickerDialog will become a widget, this commit is only about
renaming the related XML file.
Part of https://github.com/odoo/odoo/pull/46088
task-2195313
The ColorpickerDialog will become a widget, this commit is only about
renaming the related file.
Part of https://github.com/odoo/odoo/pull/46088
task-2195313
The model account.setup.bank.manual.config (menu "Add a Brank
Account") was with the group account.group_account_user ("Show Full
Accounting Features").
Since 65530dfd6a, transient models have ACL and are not accessible
if the user does not belong in the group.
The account.setup.bank.manual.config model is triggered via the server
action account.action_new_bank_setting instead of a classical
menu. It's also displayed in an onboarding step of account.
Because of this, the group must be relaxed (and not just adding a
group of a view/action)
In saas-13.2, 65530dfd6a made simply the wizard appears in readonly
but in saas-13.4, since 56a8c9e431, trying to display a model on
which we do not have access produces and access rights error.
closesodoo/odoo#51330
X-original-commit: a4a2b8198d5d2d368e279929a5cdbcca0376d8ef
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The label of the journal items generated for a payment is the
communication. However, this field is not required leading to
journal items with an empty label.
This doesn't lead to a good usability when opening the reports or
when trying to edit manually the journal entry because the label
is required on the form view.
closesodoo/odoo#51275
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Improve ranking display
Improve backend view
Fix share popup displayed on invalid post
Fix ranking search
Fix Upvote allow when already downvote
Allow to edit FAQ (karma out of accordion)
Add list view mode on forum index
Add last_post / Number of post on forum index
...
task-2201708
closesodoo/odoo#46634
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit add a breadcrumb in the badge frontend view to redirect
to the last page the user was.
It highlights the user profile line in ranking view (profile/users).
It add this line at the top of every pages except for the one where
it already was.
Part of https://github.com/odoo/odoo/pull/46634
task-2201708
