On the manufacturing order form view, the 'update' button to change
the production quantity doesn't give the current mo id to the wizard.
That means 'active_id' is used.
The issue is 'active_id' may refer to another object (a bom or
a workcenter for instance).
This commit fills the default_mo_id key in the context before calling the wizard
to ensure the correct production order is used in the wizard default get.
Task : 2043136
closesodoo/odoo#35453
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
from f5e99060b6, a scrap order was unlink
when clicking the discard button in the insufficient quantity wizard.
This lead to a access error when the wizard was closed on the scrap order
form view. The form view was reloaded on a deleted record.
This commit adds a context key that prevent the unlink if the scrap order
was validated from the scrap form view
Task : 2043136
Follow up of 344614b54a
If base64_source is falsy, we don't need to check the other parameters.
closesodoo/odoo#35489
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Currently, only 6 digits after decimal point is stored in database and for some currencies
it may require to have more digits after decimal precision to correctly convert rates,
like MXN -> USD currency. So, we allow maximum digits to be stored in database.
On the view side, wherever rate is editable(form or tree view), we show 12 digits
after decimal point and on list view, we truncate limit it to 6 digits.
Also, a bug is fixed for web where 'digits' attribute for float field on list view isn't considered.
Also, we have to remove a test case statement which only checks for 6 digits for a float number.
task: 2024668
closes: #34279
Signed-off-by: Josse Colpaert <jco@openerp.com>
Update invoice report to add id attribute in vat label and tax lines
elements in order to to be able to make clear/save inherit of this
report in Argentinian localization
Before this commit modifying/extending the information was difficult
After this commit, the id can be used for efficient xpath
<xpath expr="//t[@id='inv_tax_id_label']" position="attributes">
<xpath expr="//span[@id='line_tax_ids']" position="attributes">
This package point to first package found in `upgrades_paths` or
fallback to alias of legacy `odoo.addons.base.maintenance.migrations`.
closesodoo/odoo#32650
Signed-off-by: Christophe Simonis <chs@odoo.com>
This commit adds a new way to use upgrades scripts folders
whithout needing to symlink them to an hardcoded path.
The folders specified in --upgrades-paths is then being used by
migration.py to find and execute migrations scripts per module
specified in the -u CLI option.
The folder needs to have the following structure:
- <upgrades_paths folder 1>
- <module1 name>
- <version1>
- <script1>
- <script2>
- ...
- <scriptn>
- <version2>
- <scripts>
- <module2 name>
- <versions>
- <scripts>
- ...
- <upgrades_paths folder 2>
- ...
Update odoo/tools/config.py
Co-Authored-By: Olivier Dony <odony@users.noreply.github.com>
Task 2041208
1. I create a product with fifo and real_time valuation (make sure the invoicing policy is 'delivered' and make it available in pos).
2. set the cost of the product to be 5.0 and sale price to be 10.0.
3. I update its inventory and set 5 items. -> total valuation of 25.
4. I change the cost of the product to 1.0.
5. I update again the quantity to 10, making the valuation of the product to 30.0.
6. I configure point of sale to allow invoicing.
7. Open a pos session then sell 7 items of the product (invoice the order).
8. Since the product is fifo, this means that the cost of goods sold is 5 * 5.0 + 2 * 1.0 = 27.0.
9. The correct expense account line should have balance of 27.0.
10. The correct output account line should have balance of -27.0
Followp of https://github.com/odoo/odoo/pull/35335
There was missing the part when an invoice is created from the POS
When the invoice is created from action_pos_order_invoice, it only contains invoice_line_ids. The stock valuation lines are present when the account.move is posted through addons/stock_account/models/account_move.py post method. That method requires _stock_account_get_anglo_saxon_price_unit to give the average unit price if it comes from a pos.order, just like it does when a sale.order.
closesodoo/odoo#35379
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The main aim of the present refactoring is twofold:
- simplify the code that was largely complexified at the time of the
introduction of comparisons in the pivot view (Time Ranges menu),
- factorize the method expandHeader and _loadData that were too much complex.
Along the way, the pivot model structure has been simplified
and many tests have been added.
Performances in mobile mode have been improved by avoiding
unecessary operations due to useless column groupbys in that
mode.
It should now be easier to understand and modify the pivot view in future.
Co-Authored-By: Aaron Bohy <aab@odoo.com>
closesodoo/odoo#33615
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
An implicit call to toString was made for the
groupbys values in the function used to
group records in _mockReadGroup.
Consequently, the values false and 'false' were
mixed and the corresponding records put in the
same group.
math_utils is a small library that exports two
functions:
- cartesian: allows to compute the cartesian
products of any numbers of arrays
while preserving the internal
structures of their elements.
- sections: returns an array with all
the initial sections of the
array passed as parameter.
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
closesodoo/odoo#35439
Signed-off-by: Christophe Simonis <chs@odoo.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Read_group only work on stored field. We still can't make these fields
stored related because of what's explained on the comment: the write
aren't batched and a constraint is raised. See rev 0679d0d542
task-2036914
closesodoo/odoo#35268
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Use pkg_resources.get_distribution() to check if python external
dependencies are installed, instead of trying an import.
The import test is preserved as a backwards compatibility measure.
This better expresses which python distribution needs to be installed
from PyPI and allows declaring a minimum supported version using PEP 440
version specifiers.
Closes#25541closesodoo/odoo#25549
Signed-off-by: Christophe Simonis <chs@odoo.com>
This gc option should delete more notifications: we only keep notification
not send, and set inbox notification as sent.
closesodoo/odoo#30067
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
mark_all_as_read is using notified_partner_ids to filter
the messages to use. But anyway, the notification will
be filtered on partner right after that.
Since if we have a domain, the message set will be quite small,
(scope of a thread) we search all those messages.
If not, we actually avoid to search on message and go right
to the notifications.
Reading the message_ids will garantee to have the minimal
set of message that where actually passed from unread to read.
Since data should not be in cache at this time and mark_all_as_read
is usually called alone, we prefer to use cache and perform a read
immediatly.
Task-ID 402597
notified_partner_ids, (previously notified_partner_ids) is used to
populate a list of partner to prefetch + return a list of partner_ids.
1. the list of partner_ids is doesn't look to be used, and thus
can be removed. Was introduced in 1d4dbc3440
2. Prefetched list of partners is used to generate customer_email_data.
Since this list is limited to partner email notifications , we can use
a custom search instead.
The proposed implementation is far from perfect but proposes the minimal
changes to remove notified_partner_ids, without (hopefully) negatively
impacting performances.
Task-ID 402597
,*:crm, website_blog
The mail.message needaction_partner_ids meaning changed over time,
and doesn't actually reflect the list of partner in needaction.
More than that the message_format needaction_partner_ids used by js
began to diverged from mail.message field since 19fb650863
To avoid any confusion, renaming it to notified_partner_ids will help
to avoid confusion between python and js meaning, and reflect the actual
content of this field : a list of partner that where notified once on
this message. This field is mainly usefull for testing.
Task-ID 402597
This commit adds a new mailbox in the Discuss app called 'History'.
Messages that have been marked as read are moved to 'History'.
Notifications are required to link history messages to users. So
notifications are now deleted after they are more tha 6 months old.
This means History mailbox keeps less than 6 months old messages.
Note that this feature only works when user notifications are handled
in Odoo. This can be set in the user preferences, under the
"Notification Management" section.
Task-ID 402597
The action called from the product's bom stat button (mrp.product_open_bom)
fill the key 'default_product_id'. This allows, creating a bom from the list view,
to prefilled the product.
This context key will also fill each new bom line as the technical field is
called product_id too.
This commit overrides default_product_id to False for the bom line One2many
in the bom form view in order to only prefill the finished product and not
the components.
Task : 2045485
closesodoo/odoo#35444
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
If a dependency was wrong in the triggers, it was hard to debug
Co-Authored-By: Olivier Dony <odo@odoo.com>
closesodoo/odoo#31958
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit removes the store property of `res_name` from `ir.attachment`
as it doesn't need to be stored and could contain outdated information
if the record name was changed after the computation.
Task: #1943295closesodoo/odoo#34930
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
* = website_forum, website_profile, website_sale,
website_sale_comparison, website_slides, website_slides_survey
Some image links were hard coded in the xml views of website, now they
are replaced with website.image_url(model, field).
Part of https://github.com/odoo/odoo/pull/34149
task-2007400
closesodoo/odoo#34149
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* = website_event_sale, website_sale_comparison, website_sale_wishlist
Some product links were not using website_url, now that we have an url
for product.product we should use that one to reach the right product.
Part of https://github.com/odoo/odoo/pull/34149
task-2007400
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`
William Henrotin