On mobile devices, by default Odoo will uses a kanban view instead of a
list view if avaiable.
In the case of "Point of Sale > Reporting > Sale Details", we can select
the list of point of sale configs. It works fine on desktop, but on
mobile we had the kanban view that does not allow to remove selected
configs (and there is "New Session", "Resume" and so on buttons that
make little to no sense).
With this changeset we force in the case usage of the list view.
opw-2040954
closes#35104
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
On the users' view, groups are shown grouped by application (module category).
Deleting a module category should, therefore, regenerate the view.
closesodoo/odoo#35181
Signed-off-by: Christophe Simonis <chs@odoo.com>
Fine-tuning of commit 5621ae3d6b.
While it focused on fixing the 'mass_mail' mode,
it forgot to keep the correct behaviour for the case where only one mail is sent.
In the latter case, it is typical to overwrite the template values, especially
for the body, before sending the mail.
In that case, applying the onchange on the templates overwrites the user input.
Note that in the case where the template is undefined it would set the composer
values to empty ones; while standard use would not allow in mass mail to both
send content and have no template, it could be done via a customisation.
opw 2041631
closesodoo/odoo#35164
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, for the following view tree:
P (active)
|
I (inactive)
|
II (active)
When calling `get_related_views()` on 'P', it would wrongly return 'II'.
It shouldn't, since its parent 'I' is inactive.
Step to reproduce:
- Go to /shop
- Enable ecommerce categories
- Enable Collapsible Cateogories
- Disable ecommerce categories
- Collapsible categories is still shown even if its parent got archived
closesodoo/odoo#35154
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Error due to other module (e.g. purchase_stock, mrp) that will
define their own rules in order to merge or not moves together.
Usecase:
- Install purchase_stock
- Create a product MTO + buy with a vendor
- Create a SO of 1 unit
- On the PO receive 2 units
- On the delivery deliver 2 units
It will create an empty delivery and put the entire move in
a back order.
First issue the extra move is created as a MTO if it's copied from an
MTO move. So il will trigger all the pull rule. We won't it because it's
an extra quantity and the rules should be only trigger by the original
document (SO/MO).
Also an extra move in a picking do the hypothesis that the original move and
the extra move will always be merged together. But in the previous
usecase, the module purchase add the condition that 'created_purchase_line_id'
and 'purchase_line_id' should be the same in order to merge move.
'created_purchase_line_id' is also copy=False, so the move and the
extra move will not be merged. create_extra_move only returns the extra
move and _action_done only process the moves returned by _create_extra_move.
It result by an original move not merged and not processed by _action_done,
it will be automaticaly set in a back order and the extra move is
processed.
In order to fix it, check if the move and the original move will be
merged. If not, returns both moves.
opw-2008113
Close#34005closesodoo/odoo#34411
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Create a company C with currency = USD
- Create a vendor V with a supplier currency = EUR
- Create a PO for V with one line, the default currency is EUR
- Save
Bug:
The currency of the PO was USD when saving because the field currency is
in readonly when the state is draft.
opw:2035640
closesodoo/odoo#35144
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- When reports print with long string in footer will spoil layout. This issue will
fix that.
Task ID: 1960423 Closes at #33271closesodoo/odoo#35097
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This commits avoid to call recompute when you write on the rank without
touch the karma_min value.
On write on karma_min, we have 2 cases:
- Rank order are the same, just need to recompute the rank for the user
that could be impacted. Eg. if karma_min changes from 45 to 50, we need
to recheck for all user between 45 and 50 their new rank.
- Rank order are not the same, we need to recompute for all users.
(could be still improved if needed)
When you recompute the rank on a list of users, depending of the number of
users (bulk if more than 3 * number of rank) we check for each user what is
the new rank, or for each rank whats is the new users.
task-internal
No way to edit a rank on the prod server. Lock sql -> crash server
closesodoo/odoo#34835
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Open a pivot view, make a search for some field
Click on a pivot cell to display the list view of elements matching the group's domain
Go back to the pivot using breadcrumbs
Before this commit, the original search domain was not kept across those actions
After this commit, it is kept
This difference is due to the fact that before 12.2, the whole action had an env, containing the search domain
in 12.2 and afterwards, things are not done this way anymore
OPW 2030555
OPW 2030983
closesodoo/odoo#35096
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the navigation menu was not clickable because of higher
z-index of the slides fullscreen menu. This commit fixes that by correctly
setting z-index, using the standard variable to avoid custom values.
task-2036877
closesodoo/odoo#35107
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Create an activity in a chatter, mark it as done, click inside the
textarea, the popover is automatically closed.
The `click` trigger both opens and closes the popover on click.
opw-2028399
closesodoo/odoo#34982
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Have a partner
Partner (A1)
/ \
Shipping Addr (A2) Invoice Addr (A3)
Give portal access to A1
Make a webshop order with A1
Make it possible for the front end user to edit his billing address (by having forgotten "country" on A1)
Note that the address being choosen as Billing is A1, NOT A3
Save
In the backend check the order. The customer is A1
The shipping address is A2
Before this commit though, the invoice address is A3, which is plain wrong
usability-wise since at no point in the flow the front end user chose that address
After this commit, the billing address stays A1, and A3 is just ignored
This goes with the spirit of https://github.com/odoo/odoo/commit/6e69de67071f2618e00856a74716d861b7f47391
Also, something smarter is possible if we let the user choose the billing address
just like we let him choose the shipping address
OPW 2034976
closesodoo/odoo#35105
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Create an invoice for a customer, send him an email from the chatter, in
the mail template set a specific "Reply to" and send the email. The
"Reply-To" template mail header is ignore and the one generated by
`mail_thread._notify_get_reply_to` is used.
See also 1c57d5e and 7b0806b
opw-2041640
closesodoo/odoo#35127
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Steps to reproduce:
1) Make sure you don't have any piece of the product you're about to
sell on hand.
2) Create two sale order, each with 10 pieces of the product and
validate them
3) Do a RFQ and buy 15 pieces.
4) On the earliest sale order, check the availability, it should
autofill the desired quantity with 10
5) Do the same on the second, it autofills 5.
6) On the later delivery, scrap one.
=> The product is scrapped from the early picking.
Sort the candidates so the current picking is on top, this ensure the
current picking is the first scraped.
opw-2036381
closesodoo/odoo#35021
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Create a product template Pt with attibutes A1, A2,
respectively with values Va1_1, Va1_2, and Va2.
This should make 2 variants, V1 and V2.
Sell some of these variants.
Then they can't be deleted since they are linked to orders/invoices/...
Now delete attribute A2. We know that:
Warning: adding or deleting attributes will delete and recreate existing
variants and lead to the loss of their possible customizations.
In fact, old variants are only archived instead of deleted:
for variant in variants_to_unlink: ... variant.write({'active': False})
as a fallback.
Now add again the attribute A2 to Pt.
It creates a new variant with the correct attributes.
Since the product is not active and has valid attributes and attribute values,
it is reactivated.
As a result we get the same variant twice.
Here we can simply add a check: if there is already an existing variant with
the same values, we can skip this activation.
We add a tiny little test to make sure that we have correct number of variants.
It's basically unreadable but somewhat commented.
fix coauthored with @rco-odoo
opw 2029985
closesodoo/odoo#35013
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Set up the POS config to use a default pricelist that is archived.
Open a new POS session.
The constraints are checked, and an exception is raised:
"The default pricelist must be included in the available pricelists."
However, if the session is already opened, the check is not done at resume.
If the pricelist is archived, the session fails to load entirely:
after loading phase, the screen turns black and nothing happens.
Since the constraints are really useful to load the POS, we trigger an explicit
check of all constraints (there are a lot more than our example) when opening
the POS.
opw 2033453
closesodoo/odoo#35077
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Before this commit, the unit price of the quote template line were
hidden.
Now, the unit price are shown. This is necessary because the unit price
is used if :
- the template is selected before the customer (price_list) is selected.
- the price_list is "Show public price & discount to the customer"
This commit revert 9416483465
opw-2039071
closesodoo/odoo#35069
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This section of log mentionned two profilers making think they were the
same.
The odoo/tools/misc.py `profile` logs a method calls inside a file that
can be used to generate a graph of method calls.
The odoo/tools/profiler.py `profile` logs a method lines calls, queries
and time spend inside the log.
fixes#31278
opw-2038941
closes#35074
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, at custom filter 'Contents' option is there for filtering by
activity description. For more usability only rename is needed. By this commit
'contents' is changed to 'Activity Description'. User can filter records by
activity description.
task - 2008515
closesodoo/odoo#35070
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
The mobile apps icons were always showing even during a search in the
settings.
closesodoo/odoo#35325
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Update manifest and make website_slides an application separated from
website embedded menus.
Implement new menu structure
* Courses
* Courses
List view: Course Name, # Views, # Attendees, # Ratings, Revenues,
Reviews
* Contents
* Reviews: kanban view of channel reviews
* Certifications: kanban view of surveys of type certificate
* Forum
* Forums: add columns to list view: Posts (questions count), Views
(sum of views of each post), Answers (sum of child_count on each post),
Favorites (sum of favourite_count on each post)
* Posts: add columns to list view: Views / Answers / Favourites
* Reporting
* Courses: list view on slide.channel model, ordered by # views.
List view: Course Name, # Views, # Attendees, # Ratings, Revenues;
* Contents: graph view on slide.slide model
Area Graph: X month
Y measure: # Views (others measures: Attendees, ...)
Group by: course (color)
* Revenues: graph view on sale.report model showing revenues of eLearning
courses.
Area chart, X: monthn Y: €, Color: course
* Certifications: list view on surveys of type certificate
Columns: Title, Survey Stage, Registered People, Certified People, Attempts
Success Rate (certified/attempts), Average Results
* Reviews: see kanban of latest reviews;
* Quiz: list view on slide.question model.
List view: Add # Quizz Trials, # Quizz Passed, Avg Attempts
* Forum: graph view on forum.post model
Area chart: # Posts created by months, color=forum
* Configuration
* Settings
* Allow Forum on Courses (installs website_slides_forum)
* Allow Certifications (installs website_slides_survey)
* Allow Selling Courses (installs website_sale_slides)
* Course Tags
* See channel.tags.group with label Course Tags, form view allow to
configure group tags
* https://drive.google.com/a/odoo.com/file/d/1G0g2UnG5cZG55EXQ5icbgwe7T2eSZskT/view?usp=drivesdk
* On click: open :https://drive.google.com/a/odoo.com/file/d/1I_PW3aZAbrslXadiYqmVF-_6dGXx8knd/view?usp=drivesdk
* Content Tags
Add course (slide.channel) kanban view. Each tile should contain
* Title of the course
* Tags below the title
* Primary button "New Lesson"
* Statistics :
* Attendees
* Running (progress != 100%)
* (if one content is certificate) Certified or Finished
* See : https://drive.google.com/a/odoo.com/file/d/13K8FmkbwmBG4JQ5gH3Q5T8OlWPs3blcu/view?usp=drivesdk
* With FP remarks https://drive.google.com/a/odoo.com/file/d/1mb7LUT0VUNs5fMcKB9c0Bfaqk2-XFFuu/view?usp=drivesdk
* Add "Sales 150.00$" below "Watch Time" if type "on payment". Same
info than the smart/stat button on the course itself. Click on the amount
sends to Reporting Revenues (same than on the stat btn)
Add review (rating.rating) kanban view. Each tile should contain
* Kanban view, full width, no default group by
* Order by date (most recent on top)
* See: https://drive.google.com/a/odoo.com/file/d/1IYE1QBIJa26BLugRiafyBop-srkYwndC/view?usp=drivesdk
* add a tag for unpublished comments
* Add the pic of the user above the stars
* Click on card, send to front-end and able to (un)publish the comment
* Kind of what's on the front-end: https://drive.g
Improve course form view: add a revenue stat button displaying the total
of sale order linked to the course's product.
Integrate a button on slide.channel form view allowing to perform a mass
mailing on course attendees. Do a flow similar to event.
Remove "Our Documentation" dummy default existing data. It makes no sense
to have void data. Instead just add a small explanation text in eLearning
front-end telling the user to create its first course if he has rights to
do so.
In order to better show the new backend add some demo data for missing
numbers, notably
* sales: add confirmed sale orders in order to have revenues value;
* forum: add some posts and answers;
* quiz: update slide.slide.partner demo data to hold quiz attempts count
LINKS
Task 1978729
PR #35061
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Partially reverts d781d6f6ea504dcc89f412b94774df6bd08c78aa
Indeed modified tour has to go through various list view actions and is
likely to crash because of some complicated triggers to write. Let us have
the recovery action back to form view. Anyway it makes no harm to have it
available in action menu.
LINKS
Task 1978729
PR #35061
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Remove "Our Documentation" dummy default existing data. It makes no sense
to have void data. Instead just add a small explanation text in eLearning
front-end telling the user to create its first course if he has rights to
do so.
In order to better show the new backend add some demo data for missing
numbers, notably
* sales: add confirmed sale orders in order to have revenues value;
* forum: add some posts and answers;
* quiz: update slide.slide.partner demo data to hold quiz attempts count;
LINKS
Task 1978729
PR #35061
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Add menu entry inside Courses
* Certifications: kanban view of surveys of type certificate
Add menu entry inside Reporting
* Certifications: list view on surveys of type certificate
Columns: Title, Survey Stage, Registered People, Certified People, Attempts
Success Rate (certified/attempts), Average Results
LINKS
Task 1978729
PR #35061
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Improve course form view: add a revenue stat button displaying the total
of sale order linked to the course's product.
Add in slide.channel kanban card
* Add "Sales 150.00$" below "Watch Time" if type "on payment". Same
info than the smart/stat button on the course itself. Click on the amount
sends to Reporting Revenues (same than on the stat btn)
Add menu entry inside Reporting
* Revenues: graph view on sale.report model showing revenues of eLearning
courses.
Area chart, X: month Y: €, Color: course
LINKS
Task 1978729
PR #35061
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Add menu after Courses
* Forum
* Forums: add columns to list view: Posts (questions count), Views
(sum of views of each post), Answers (sum of child_count on each post),
Favorites (sum of favourite_count on each post)
* Posts: add columns to list view: Views / Answers / Favourites
Add menu entry inside Reporting
* Forum: graph view on forum.post model
Area chart: # Posts created by months, color=forum
LINKS
Task 1978729
PR #35061
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Integrate a button on slide.channel form view allowing to perform a mass
mailing on course attendees. Do a flow similar to event.
Add menu entry in menu of slide.channel kanban card after invite
* Mail Attendees (same as on the course card and depend of the setting)
Add menu entry inside Settings
* Settings: add an option to install module mass_mailing_slide
LINKS
Task 1978729
PR #35061
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Currently each change in mailing model resets the mailing domain. Idea behind
that behavior is that domain for a given model will probably not be valid for
another model because of fields being model specific.
However this breaks when creating mailing with default values for mailing
model. Indeed even valid domains are reset to a default void / opt-out-ed
value due to current onchange implementation.
This commit fixes that behavior by resetting only invalid domain i.e.
that crashes when performing a search on target model.
LINKS
Task 1978729
PR #35061
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Add course (slide.channel) kanban view. Each tile should contain
* Title of the course (make it big, o_primary)
* Tags below the title
* Primary button "New Lesson"
* Statistics :
* Attendees
* Running (progress != 100%)
* (if one content is certificate) Certified or Finished
* See
* v1: https://drive.google.com/a/odoo.com/file/d/13K8FmkbwmBG4JQ5gH3Q5T8OlWPs3blcu/view?usp=drivesdk
With FP remarks https://drive.google.com/a/odoo.com/file/d/1mb7LUT0VUNs5fMcKB9c0Bfaqk2-XFFuu/view?usp=drivesdk
* remove globe, type and visibility of course, lessen padding between rating
views and watch time;
* for rating, instead of 8.00 => 5 reviews (4.5/5);
* replace "View Lesson" / "Invite" by "View Course" => Send to the front-end
* In the menu of the card, add:
* Invite (same behavior than before, when it was a primary btn)
* click on x Contents: land on the contents, group by category with sequence
* re-order of the 3 infos/Stats at the bottom of the card: 1. Content,
2. Attendee, 3. Certified
* + number: font-weight: 500 + font-size 1.2em
* + labels: remove text-uppercase, + text-color: #666666
* + the "whole box" is clickable
LINKS
Task 1978729
PR #35061
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Add a kanban view for slide.slide model
* See https://drive.google.com/a/odoo.com/file/d/1WKj13-C_UCOwh4dN-FRmU9Pp6BsZ_HvT/view?usp=drivesdk
LINKS
Task 1978729
PR #35061
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Add in menu Courses, a new entry Reviews
* Kanban view, full width, no default group by
* Order by date (most recent on top)
* See: https://drive.google.com/a/odoo.com/file/d/1IYE1QBIJa26BLugRiafyBop-srkYwndC/view?usp=drivesdk
* add a tag for unpublished comments
* Add the pic of the user above the stars
* Click on card, send to front-end and able to (un)publish the comment
* Kind of what's on the front-end: https://drive.google.com/a/odoo.com/file/d/1e9aQSWvUM2QOynRT08XSUzIjFiGnjsv8/view?usp=drivesdk
LINKS
Task 1978729
PR #35061
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Update manifest and make website_slides an application separated from
website embedded menus.
Implement new menu structure
* Courses
* Courses
List view: Course Name, # Views, # Attendees, # Ratings, Revenues,
Reviews
* Contents
* Reporting
* Courses: list view on slide.channel model, ordered by # views.
* add a graph view (group by content)
* Contents: graph view on slide.slide model
Area Graph: X month
Y measure: # Views (others measures: Attendees, ...)
Group by: course (color)
* Reviews: see kanban of latest reviews;
* Quiz: list view on slide.question model.
List view: Add # Quizz Trials, # Quizz Passed, Avg Attempts
* Configuration
* Settings
* Allow Forum on Courses (installs website_slides_forum)
* Allow Certifications (installs website_slides_survey)
* Allow Selling Courses (installs website_sale_slides)
* Course Tags
* See channel.tags.group with label Course Tags, form view allow to
configure group tags
* https://drive.google.com/a/odoo.com/file/d/1G0g2UnG5cZG55EXQ5icbgwe7T2eSZskT/view?usp=drivesdk
* On click: open :https://drive.google.com/a/odoo.com/file/d/1I_PW3aZAbrslXadiYqmVF-_6dGXx8knd/view?usp=drivesdk
* Content Tags
This structure will gain new items in sub-modules, notably bridge with
form and website_sale. Those will be implemented in next commits.
LINKS
Task 1978729
PR #35061
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
When adding multiple notes, it was keeping the date of the previous
note in memory. This commit ensures the date is reset each time we click
on "Add a note"
closesodoo/odoo#35374
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Since commit `a3d98dae68b97aeb7c36ca93c31f067535cbe8fd` the calendar is
no longer opening when clicking on the calendar icon in the activities when
adding a note.
before this commit, the title of the page is not correct in fullscreen mode
after this commit, set the lesson name as the page title in the fullscreen mode
and changed the title of the page as per click on lesson name
task-2040899
closesodoo/odoo#35161
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The `website_published` field from the website's mixins is basically a readonly
from `is_published` field.
On read, this field will simply read `is_published` and check if the record's
website_id is accessible (only for the multi mixin).
On write, it will always write on `is_published`.
Whenever possible, any access (read/search) on published state should be done on `website_published`.
Any write should be done on `is_published`.
This PR improves a few things:
- A lot of code was writting on website_published which was just then writting
on is_published. Writting directly on is_published makes more sense.
- Some backend fields would still reference `website_published` instead of
`is_published` which would just go through the related for no reason.
Plus, using `is_published` will make the field tooltip more accurate as we
are not in a website context ('Visible on current website' to 'Is Published')
- Filter and search on tree view were still using the `website_published`
related field, which is just a readonly when we are not in a frontend
context.
- Some create and write function would have security check on
`website_published` value but that was wrong as the user could bypass that by
simply writting on `is_published`. For the write method, check `is_published`
is more accurate as it will cover both case since `website_published` will
then call the write method on `is_published`
- Some models would create their own `website_published` field rather than using the
`website.published.mixin` mixin which should be used instead.
That was done to be able to override the default value of the boolean.
This commit simply adds the possibility to override the default value of the
mixin field.
- Fix wrong publish security check that were only checking `website_published` in vals.
closesodoo/odoo#35189
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Commit 916968058d introduced a mechanism to check rights when writing or
creating on `website_published` field.
Problem is, `website_published` is just kind of a related to `is_published`
which really stores the value.
Thus, the checks would not work when writing/creating on `is_published`.
That would leave a loophole to bypass the expected behavior.
*website_crm_partner_assign, website_customer
Before this commit, some models would create their own `website_published`
field rather than using the `website.published.mixin` mixin which should be
used instead.
That was done to be able to override the default value of the boolean.
This commit simply adds the possibility to override the default value of the
mixin field.
Also, help and string could simply be added on xml views rather than overriding
the field.
The `website_published` field from the website's mixins is basically a readonly
from `is_published` field.
On read, this field will simply read `is_published` and check if the record's
website_id is accessible (only for the multi mixin).
On write, it will always write on `is_published`.
This commit improves a few things:
- A lot of code was writting on website_published which was just then writting
on is_published. Writting directly on is_published makes more sense.
- Some backend fields would still reference `website_published` instead of
`is_published` which would just go through the related for no reason.
Plus, using `is_published` will make the field tooltip more accurate as we
are not in a website context ('Visible on current website' to 'Is Published')
- Filter and search on tree view were still using the `website_published`
related field, which is just a readonly when we are not in a frontend
context.
- Some create and write function would have security check on
`website_published` value but that was wrong as the user could bypass that by
simply writting on `is_published`. For the write method, check `is_published`
is more accurate as it will cover both case since `website_published` will
then call the write method on `is_published`
It is now possible to specify the forum mode : Questions and Answers or
Discussions. In Q&A mode, a user can only reply once while there is no
limit in Discussions mode.
task-2008910
closesodoo/odoo#34097
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This check was introduced with d82b897ea1 in 12.0 where `get_base_url` was
not yet a model method.
Since f727cd2645, in saas-12.5, that method is now on model, making the
`hasattr` check useless.
closesodoo/odoo#35057
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Merge commit for PR #34925
Related enterprise PR odoo/enterprise/pull/4865
The goal is to:
- Use `image.mixin` on the models currently storing multiple image sizes.
- Create Image field and use it on models where mixin is overkill.
- Rename the image fields to contain the pixel number in the name.
- Add 512 size.
- Clean up `image.mixin`, zoom field, variant fields.
Note: models that currently store only a single size image will not be changed
in this PR.
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Nicolas Lempereur