e18eeca7d1b1cf47c72f8aa2c0348cdb8649d0d6
150575
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 roen-odoo
|
e18eeca7d1 |
[FIX] pos_hr: save cashier correctly in db
Current behavior: In PoS restaurant cashier were not saved correctly in db if you switched table before making the payment of the order. Steps to reproduce: - Install PoS - Activate restaurant on one of your PoS - Activate Authorized employee - Start a PoS session, and select a cashier - Create an order on a table - Leave the table and comeback to it - Make the payment for the order - Go in the PoS orders, the cashier wasn't saved opw-2794574 closes odoo/odoo#91447 X-original-commit: 2c6ea058f9f8cfaf75529ff4028913a59f021ab8 Signed-off-by: Masereel Pierre <pim@odoo.com> Signed-off-by: Trinh Jacky (trj) <trj@odoo.com> Signed-off-by: Engels Robin (roen) <roen@odoo.com> |
||
|
Louis Wicket (wil)
|
301076e2ce |
[FIX] mail: fix default value of date in clock model
The first date should be the date of the record creation instead of the time the model was initialized. closes odoo/odoo#91372 X-original-commit: 2635b29193ba16d85f62aabd8bddd7d7692007f0 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> Signed-off-by: Louis Wicket (wil) <wil@odoo.com> |
||
|
Thanh Dodeur
|
806fcc2a38 |
[IMP] mail: place the rtc overlay inside the participant card frame
Before this commit, the overlay with status icons of the participant card was at the border of the whole card, which made it difficult to see in some situations, like when focusing on one participant. This commit places the overlay over the main frame of the card. part of task-2692836 closes odoo/odoo#91297 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com> |
||
|
Thanh Dodeur
|
305bf22fe9 |
[REF] mail: move rtc session remote track update to the right model
part of task-2692836 closes odoo/odoo#91296 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com> |
||
|
Thanh Dodeur
|
d33188e9a6 |
[REF] mail: move session stream update to the right model
part of task-2692836 Part-of: odoo/odoo#91296 |
||
|
Thanh Dodeur
|
5799880ad0 |
[REF] mail: move transceiver ordered names to model field
part of task-2692836 Part-of: odoo/odoo#91296 |
||
|
Jacky (trj)
|
537d067569 |
[REF] point_of_sale, pos_restaurant: cleaning of the methods and flow
Cleaning of the principal methods used in the pos_restaurant flow. This make the code a lot more readable and maintainable as we strive for the single responsibility principle. A few notable changes: - [REF] `point_of_sale.assets` in `pos_restaurant` now uses glob syntax (`**`) for the js files, no need to add them in the manifest anymore. - [MOV] Moved some methods to `pos_restaurant` (because it was only used there) from the `point_of_sale` - [REF] Only the created, removed and updated orders of a table are being sent to the server once we reach the Floor Screen. Before, all the orders of a table were being sent to the server as the newest state. This led to some synchronization problem when two users wanted to modify each a different order of the same table, the user leaving the table last had **all** his orders states (even the ones he didn't modify) pushed to the server. - [IMP] After a table transfer while being in offline mode, the transferred order is saved locally (if not yet synchronized) and going back to the previous table after getting the connection back will no longer show the transferred order after the orders fetching from the server. - [FIX] When an order is selected (normal Point of Sale and in a table in `pos_restaurant`), the selected order is not changed in the Ticket Screen when deleting an order unless the deleted order is the current selected order. - [FIX] Same as above but while settling all the tips from the `Ticket Screen` - [FIX] Errors are now properly handled in the `Floor Screen` depending on the context. - [REF] Kitchen order printing flow has been revamped and improved. This also fixes a bug where we would print a cancelled receipt changes for a skipped order line when adding a product which was already printed before (add 1 product => print => add same product + skip => print would give a cancelled changes for this order line). closes odoo/odoo#85956 Related: odoo/enterprise#25051 Related: odoo/upgrade#3375 Signed-off-by: Masereel Pierre <pim@odoo.com> |
||
|
qsm-odooandIvan Yelizariev
|
b246def6d5 |
[FIX] website: consider configured email_to on the contact us page
Configuring the email_to field on the contact us page was not working anymore. The email was always sent to the company email whatever the user chooses in edit mode. This was due to [1] which gave the priority to the data-for and prefill system over default values. While this makes sense in general (e.g. if the URL on the contact us page contains ?name=John, then the form is prefill with "John" whatever the value that is set as default), it does not make sense for the email_to field which is always prefilled with the company email. The data-for/prefill system priority probably has to be reviewed in the future. Meanwhile, this commit will make the email_to field as an exception for this system and only use the data-for value if nothing has been configured by the user. This commit also handles another case. Indeed "if nothing has been configured by the users" is currently kinda broken as just clicking on the form and saving will force the value "info@yourcompany.example.com" as the email_to value... thus making the form use it instead of the company email. We will make that as an exception of the exception: use the data-for value (company email) if what was configured by the user is the dummy default value "info@yourcompany.example.com". A test for each of those two exceptions has been added (only the first test breaks before this commit as [1] made the second test pass by chance). [1]: https://github.com/odoo/odoo/commit/7b23d3aacd22f87cb0c22ecd0478eba4a17b4bf3 opw-2842211 Original idea for the first exception: closes odoo/odoo#91407 X-original-commit: a08574a04ff2ce8ea2d6fd2b79f56cc57bba953b Signed-off-by: Romain Derie (rde) <rde@odoo.com> Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com> Co-authored-by: Ivan Yelizariev <iel@odoo.com> |
||
|
Victor Feyens
|
508bc6c4a2 |
[FIX] sale_management: admin doesn't have access to sale.order.template model
If a default template is specified in a given database (it is the case by default on runbot databases because of sale_quotation_builder), the webclient will try to fetch its display_name (through a name_get rpc). As this happens even if the default_sale_order_template_id field is hidden in the view, administrators without sales rights were not able to open the settings, because they didn't have read rights on sale.order.template model. This commit makes sure that settings users are able to open the settings independently of their level of rights for the Sales scope (salesman/sales manager). Fixes #84597 closes odoo/odoo#91380 X-original-commit: 74857e31bd5ecc329cb4f07b786e199e01da044f Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com> |
||
|
Patrick Hoste
|
d041cbe6ab |
[IMP] mass_mailing: ignore past date when scheduling
PURPOSE With this commit, when trying to schedule a mailing with a past schedule_date one will be asked a new date. LINKS Task-2833321 closes odoo/odoo#90891 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> |
||
|
Abdelouahab (abla)
|
1a84399314 |
[FIX] account : fixing type of journal_id
the `write` method from `AccountMove` class and its children expect `journal_id` in `vals` to be an `int` and not an `account.journal`. linked PR : https://github.com/odoo/enterprise/pull/26515 opw-2794392 closes odoo/odoo#91422 X-original-commit: 69ea8b2389e62a415b70edbd109333b1a1a03e8e Related: odoo/enterprise#27349 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com> Signed-off-by: abla001 <abla@odoo.com> |
||
|
Merlin (megu)
|
80a4dc912a |
[FIX] account: edit payment's partner_bank_id
Payment's partner_bank_id cannot be modified because the field is in readonly Steps to reproduce: 1. Install Invoicing 2. Go to Invoicing > Vendors > Payments and create a new payment 3. Specify a vendor, edit this vendor and add two bank accounts (in the Invoicing tab) then save 4. The field 'Vendor Bank Account' is populated with one of the bank accounts 5. Save the payment then edit it again 6. Change the 'Vendor Bank Account' and save 7. Refresh the page 8. The 'Vendor Bank Account' hasn't changed Solution: Add a condition to the readonly so that it only applies when the field 'Company Bank Account' is displayed opw-2826507 closes odoo/odoo#91406 X-original-commit: 47b69d6cbf1bf9c9512a4b46a223e3b9f3c89e06 Signed-off-by: Olivier Colson <oco@odoo.com> Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com> |
||
|
Pieter Claeys (clpi)
|
b3305b1886 |
[FIX] stock,purchase_stock,mrp: replenishment notification
When clicking order now on a replenishment line (orderpoint) for a manufacture or WH resupply route, it will sometimes show a notification for a purchase order that was created earlier instead of the correct one. closes odoo/odoo#91404 X-original-commit: 9ca9bcc51fa289ddb0548f81a795755d196e31ca Signed-off-by: Arnold Moyaux <arm@odoo.com> Signed-off-by: Tiffany Chang <tic@odoo.com> |
||
|
Hubert Van de Walle (huvw)
|
516b539237 |
[FIX] project: Burndown Chart date_group_by selection is empty
Steps to follow - Go to project - Click on the 3 littles dots on a card - Go to Burndown Chart - Add a custom filter on the date_group_by field -> this.fields[condition.field].selection[0] Cause of the issue The date_group_by field selection should be declared as a list, not a tuple opw-2819936 closes odoo/odoo#91397 X-original-commit: e3254a882199f229e4a8b4f38ce7f7529fd8da46 Signed-off-by: Hubert Van De Walle <huvw@odoo.com> |
||
|
Pierre Paridans
|
8ed9d667fe |
[FIX] web: Dialog footer buttons' spacing
Before this commit, some dialog's footer buttons were glued to each other which impacted their readability and usability. This commit fixes it by properly applying the existing `gap` CSS rule which defined the spacing between the buttons, and this independently of the structure of the footer. Indeed, due to historical reasons, the `.modal-footer` may contain drastically different structures depending of the kind of modal. A non-exhaustive list of encountered structures: - `.modal-footer > button` - `.modal-footer > div > footer > button` - `.modal-footer > div > button` Note: some existing rules already illustrate that in `modal.scss`. task-2792884 closes odoo/odoo#91371 X-original-commit: d15bfc785d392a7dffadf9489d1d21f449d42ca4 Related: odoo/enterprise#27337 Signed-off-by: Pierre Paridans (app) <app@odoo.com> |
||
|
Fabio Barbero
|
fc79bd1e0e |
[IMP] sm modules: "neutralise" genders
Purpose ======= Change all masculine nouns in Odoo's code to neutral nouns (when possible), making sure that demo data is correctly handled. This is particularly important since our code is open source, and nowadays lots of machine learning models are trained on open source repositories. With this small change we contribute to training more "fair" models, and teaching models that "employee" or "user" != "he". This also affects some text visible by the user, hence making it more inclusive for Odoo users. Task-2853046 closes odoo/odoo#91292 Related: odoo/enterprise#27302 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> |
||
|
Laurent Stukkens (LTU)
|
1a8389858a |
[FIX] web: prevent access error in calendar
Prior to this commit: - If the color attribute is set on a field on which the user might not have access to the model / record, a traceback is returned. However, in the case of a M2O, the name_get would be returned, so its is a pity that the color raise an access error. After this commit: - A search_read is made instead of a read, which returns nothing if the user does not have access to the model / record and does not raise a traceback. closes odoo/odoo#91147 X-original-commit: 3e8744418d629a62e9eacd16dfa4721921e02453 Related: odoo/enterprise#27318 Signed-off-by: Géry Debongnie <ged@odoo.com> Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com> |
||
|
Adrien Minet
|
42a637202b |
[FIX] crm: lead.scoring.frequency must be accessible by admin
How to reproduce the bug ? - install the CRM and sales modules - remove the user from the all the sales security group - go back to the dashboard and click on settings What is the bug ? The res.config.settings model of the CRM module has a field referencing the crm.lead.scoring.frequency model. This model can only be accessed by the members of the sale security groups. If an admin is not part of the sales group, he will get an error when he wants to access the settings while he will not see the sales or the crm settings tab. opw-2755177 closes odoo/odoo#91405 X-original-commit: 5f2d6dfac018339283971eadc2a3bbadc857ae35 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com> Signed-off-by: Minet Adrien (admi) <admi@odoo.com> |
||
|
Philippe Wauthy
|
d6685480d3 |
[FIX] hr_holidays: fix TestAccrualAllocations tests
There are several instances in TestAccrualAllocations where freezetime is used on a dynamic date. This fix freezes the time to an iconic date. task-2853089 closes odoo/odoo#91316 Signed-off-by: Kevin Baptiste <kba@odoo.com> |
||
|
gawa-odoo
|
9e2b7569a1 |
[ADD] l10n_ke: Create localization for Kenya
Added CoA and account groups for Kenya. Added taxes for Kenya task-2809108 closes odoo/odoo#91396 X-original-commit: ac95f9f961405ed6f6b24f08a8aab05a6561e410 Related: odoo/enterprise#27344 Signed-off-by: Florian Gilbert <flg@odoo.com> |
||
|
Josse Colpaert
|
ded97e9960 |
[FIX] l10n_it_edi_sdicoop: if to the PA, it should be changed to sent
First thing is that when you send an invoice to PA in test/production, it should be considered as sent after the xml is generated as we do not have the functionality to send sign invoices yet. We added a test for posting the invoice when the invoice partner has a l10n_it_pa_index (and it is of length 6). Alos, when the proxy user is a 'demo' user, creates a traceback. The solution is to only add the demo response to those that would have been sent to the iap server otherwise. We also avoid doing a call to the IAP server if there are no invoices to be sent (e.g. because they all go to the PA) opw-2807213 closes odoo/odoo#91419 X-original-commit: 2221f0145607e4cd0880e7435b637f620d15cecf Signed-off-by: William André (wan) <wan@odoo.com> |
||
|
Pouya Malekinejad
|
9a34a6add3 |
[IMP] account_invoice: prevent erasing of a tax line entry if there is a tax related to it in the invoice
This is actually checking if for each tax of each line of invoice in the move, there exist a tax entry. This will prevent the users from accidentally or dully erasing tax lines which includes 0% taxes. If the users delete the line containing tax, it will be added again the same way as the counterpart line for an invoice line is being added. Also, fixes the following: Recalculating all invoices if a single invoice in a batch has a line with `recompute_tax_line` set should not be allowed. Deleting a tax account entry of a posted move should not be allowed. task ID:2834679 closes odoo/odoo#91414 Pr: #90834 X-original-commit: 5f39f8c1533502be52ea9d3ef114430b5b8cd9a6 Signed-off-by: William André (wan) <wan@odoo.com> |
||
|
Hardik Prajapati
|
c0662dc68b |
[IMP] base{_geolocalize},project,web: usability improvements
purpose of the task is to improve the usability of the base, base_geolocalize, project and web task-2764760 closes odoo/odoo#85295 Related: odoo/enterprise#24706 Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com> |
||
|
dbkosky
|
f99c93b5ce |
[FIX] l10n_it_edi: double IT country code filename
The current problem is that the codice fiscale field is validated using a regex that matches an alphanumeric code of 16 digits (that causes no problems) and both a simple numeric code (of 11 digits) and an alphanumeric code (of 13 digits, starting with the country code 'IT') for businesses. The problem is that the systems that make use of the codice fiscale code tend to utilise the former (i.e. the 11 digit code, without the 'IT' prefix). The filename for the EDI comprises a country code, the codice fiscale of the company and a progressive number. When the codice fiscale is completed as being eg. 'IT00465840031', the country code + codice fiscale will be 'ITIT00465840031', which will be rejected by the edi system (a single country code is expected). This commit removes the 'IT' in the xml by utilising a function on the template _l10n_it_normalize_codice_fiscale from the res.partner model. related ticket-id: 2845341 closes odoo/odoo#91370 X-original-commit: 39dcee1cc1ef1ed4c4a85494b689f4f604e32de6 Signed-off-by: Josse Colpaert <jco@odoo.com> |
||
|
Antoine Vandevenne (anv)
|
fadff0cc91 |
[REF] payment, *: make helper methods on portal private
*: account_payment, sale This doesn't change anything from a technical point of view, but it helps to consistently assess whether a method is attached to a route or not, only by looking at the class' skeleton. closes odoo/odoo#91359 X-original-commit: 93de42458ed0a7df20a7bc2f2c2b106386293c78 Related: odoo/enterprise#27330 Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com> |
||
|
Alexandre Kühn
|
0574077999 |
[FIX] mail: fix typo on passing props
This typo crashed the code because the component expect receiving the view record as prop. closes odoo/odoo#91358 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> |
||
|
abd-msyukyu-odoo
|
0dddbd25e0 |
[FIX] knowledge: add dependencies to /article dialog
- What is broken: The /article command of the editor when editing a page on `website` has a traceback and the dialog does not open. - The fix: Add a xmlDependency to the KnowledgeArticleLinkModal so that the modal can be used in website to select the desired article when using the /article command. Task-2674460 closes odoo/odoo#91343 Signed-off-by: David Beguin (dbe) <dbe@odoo.com> |
||
|
tsm-odoo
|
9c1cf242c0 |
[IMP] mail, *: replace widget el by target
*: hr, test_mail. This PR prepares the ground for the one introducing the new environment in the discuss app. Indeed, the createWebClient helper will be used instead of createView/Widget thus the returned value won't be a Widget anymore but a DOM element. This change impacts they way the tests were written: JQuery functions have to be transformed to native JavaScript ones. In order to reduce the noise in the main PR, those changes are done now. task-2582313 closes odoo/odoo#91290 Related: odoo/enterprise#27313 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> |
||
|
tsm-odoo
|
6c8fbd0da1 |
[IMP] mail, *: add sendmany/sendone to the mock server
*: im_livechat, website_livechat. In order to reduce the noise in the PR introducing the new environment in the discuss app, calls to widget.call, env.bus_service.call during tests have been replaced by a mocked implementation of _sendone/_sendmany. Moreover, this approach will allow us to mock the longpolling during tests, resulting in a more realistic behavior. task-2582313 closes odoo/odoo#90724 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> |
||
|
Cedric Prieels (cpr)
|
55a88226f3 |
[IMP] project: improve project updates reports
This commit improves the timesheet reports linked to the sales. task-2802506 closes odoo/odoo#88749 Related: odoo/upgrade#3443 Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com> |
||
|
dasa-odoo
|
9ea3981466 |
[IMP] calendar: improve _compute_meeting performance
We can use ._search() to make sure that permissions and ir.rules are applied. By making use of psql subqueries, we remove the need of costly python filtering afterwards, thus increasing performance. Created test_meeting_count() to check that that the computing of meeting_count is done correctly. closes odoo/odoo#91325 X-original-commit: 2df40ab03d29045546fbf7f19203e66796d52dc0 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> |
||
|
Sébastien Geelen (sge)
|
9de29c709d |
[FIX] web_editor: fix toolbar visibility check
When the selection span across two element linked to odoo field that cannot be styled. The toolbar should not be visible. The visibility check was performing a verification based on the `range.commonAncestorContainer`, therefore when the selection spanned across multiple element the common ancestor was higher in the DOM than we wanted, and the check was not working. We changed the check to use `selection.anchorNode` and `selection.focusNode` to ensure the verification works any time. task-2845346 closes odoo/odoo#91324 X-original-commit: aaa65a49489bad3d25cc3229f0b85e66b8ae855d Signed-off-by: David Monjoie (dmo) <dmo@odoo.com> |
||
|
David Beguin
|
19ba321d87 |
[FIX] knowledge: fix confirm dialog in permission panel
The owl dialog was imported in the permission panel file but the usage was the legacy way to display a dialog. This commit import the legacy dialog. Task-2674460 closes odoo/odoo#91313 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> |
||
|
Thanh Dodeur
|
9b6b4c902b |
[FIX] mail: change incorrect component names
Before this commit, the name of the component incorrect names were used instead of `RtcConfigurationMenuDeviceComponent`. This commit fixes this issue. closes odoo/odoo#91303 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> |
||
|
Huy
|
6768e77f9b |
[FIX] website: allow editor users to edit theme views
Currently, "Editor and Designer" can't edit the views which originate from a theme (which are copies from the theme `theme.ir.ui.view` records). This error is caused by [1], which is preventing the `arch_updated` field to be set to `True`, as this field is supposed to be set to `True` only on manual user change, not during module update. Indeed, restricted users don't have access to the themes records, making the overide raising an error. But there were actually no reason for this code to be executed outside module operation. Steps to reproduce: - Create any view in a theme module. For example: create a custom footer view. - As a "Editor and Designer" user, edit this view through the website builder. - An access right error is raised. [1]: https://github.com/odoo/odoo/commit/1eb7c577ecb31c2f0876b6dd76769e2b47802cb0 closes odoo/odoo#91255 X-original-commit: d2be8dc99eb99321be1172af447d5f2536c17364 Signed-off-by: Romain Derie (rde) <rde@odoo.com> |
||
|
Thanh Dodeur
|
adc62e21e6 |
[REF] mail: remove unused code
part of task-2692836 closes odoo/odoo#91295 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> |
||
|
Merlin (megu)
|
b4e9cda4bf |
[FIX] sale,sale_product_configurator: company access in price_compute
There is an access error when using the product configurator in a mutli- company environment Steps to reproduce: 1. Install Sales 2. Go to Settings > General Settings > Companies and create a new company 3. Go to Settings > Sales > Product Catalog and enable Product Configurator 4. Switch to the new company 5. Go to Sales > Products > Products and create a new product 6. Set the product's company to the new company 7. Add the 'Color' variant on the product with at least two values 8. Go to Sales > Orders > Quotations and create a new quotation 9. Add the new product to the quotation, the product configurator shows up 10. Increasing the number of product in the configurator will put the total to 0 and the http request `/sale/get_combination_info` raises an access error Solution: Pass the company in the context of the rpc call Problem: If we are in a secondary company, we try to acces the product of this company from the default company in `price_compute`, which raises the error opw-2826227 closes odoo/odoo#91266 X-original-commit: 5477e1bce1a3791b39d0f6de9d382416fb4b6ebf Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com> |
||
|
Fabien Pinckaers
|
0e0047a533 |
[FIX] forum: typo in forum manifests url
closes odoo/odoo#91139 X-original-commit: 20928abe443973cbf199c206724427050cd993a9 Signed-off-by: Fabien Pinckaers <fp@odoo.com> Signed-off-by: Jérémy Kersten <jke@odoo.com> |
||
|
tsm-odoo
|
c23f85903a |
[IMP] mail, *: use pyEnv in the mockServer
Now that pyEnv is available, using it in the mock_server lighten the syntax. task-2582313 closes odoo/odoo#90783 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> |
||
|
Odoo's Mergebot
|
1da3a974e6 |
[FIX] knowledge: fix changing internal permission
Before this commit, it was not possible to change the internal permission in the permission panel. This commit fixes that. Task-2674460 closes odoo/odoo#91283 Signed-off-by: David Beguin (dbe) <dbe@odoo.com> |
||
|
Fabio Barbero
|
113fc468a0 |
[FIX] knowledge: fix changing internal permission
Fix bug that prevents user from changing internal permission from view. Task-2674460 Part-of: odoo/odoo#91283 |
||
|
momegahed
|
3e26216b43 |
[FIX] account_analytic_default: fixing restrictions on analytic tags
If applied, this commit will fix the following bug by adding some restrictions on the creation of analytic default and the uses of tags in account.move Steps to reproduce: 1- install account.accountant, account_analytic_default 2- Accounting --> Configuration --> Analytic Tags, analytic accounting 3- Create an Analytic Tag, with no Analytic Distribution. 4- Accounting --> Configuration --> Analytic Default Rules. Create an Analytic Default Rule, using the Analytic Tag above and select a Partner 5- Create a Vendor Bill on that partner. The Analytic Tag is added to the invoice, as expected 6- However when selecting Accounting --> Reporting --> Analytic Report, the report is empty and does not contain the Analytic Tag. Adding the Analytic Tag to the filter has no effect. Bug/Issue: An analytic tag is meant to be an additional dimension of analysis. Dimension which is only worth/valid when an analytic account is specified. An analytic default rule should never be applied without - either an analytic account - or analytic tag used for distribution Fixes: 1- changing the error condition on creating analytic default 2- changing the error message accordingly to better explain the issue 3- raise an error when the user creates an account.move with analytic tags without (analytic tags + analytic account) or (analytic tags with analytic distrubtion) Please refer to the ticket for the whole discussion on this OPW-2766749 closes odoo/odoo#91271 X-original-commit: 99c50b9d48448bff54fc5a7c76bbec300bd25d25 Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com> Signed-off-by: William André (wan) <wan@odoo.com> |
||
|
MAHAMADASIF ANSARI
|
e2429999fe |
[FIX] calendar: remove description_to_html_lines method reference
With commit that replaced most of the text fields to HTML fields (see commit[1]), the `description_to_html_lines` method was removed from `calendar.event` model and linked templates. But another commit[2] merged afterwards introduced a mail template that used this method, due to which the rendering used to crashed. This commit adapts the template and thus fixes the crash while rendering the template. commit[1] - https://github.com/odoo/odoo/commit/cb4f597410bcb08208ee277144d755bef8b6d688 commit[2] - https://github.com/odoo/odoo/commit/40fd44f618cb54d8c75b8c090cc36655316aa825 task-2821957 closes odoo/odoo#91280 X-original-commit: 71b9e36f5c5e36f13f26bf74038ddb736d5e25de Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> |
||
|
Xavier Morel
|
c5964f84d9 |
[FIX] auth_oauth: improve implicit flow implementation / compat
The current implementation is rather non-standard and largely an ad-hoc pre-RFC implementation, with a number of incompatibilities with the standard & actual real-world identity providers (IDP). Tested with the following IDP: - google oauth v1 - google oauth v3 - auth0 - okta Add support to bearer Authorization =================================== Sending the access token via "Authorization: Bearer $TOK" is strongly recommended by the RFC, and required for all IDP to support. The query parameter method is a legacy compatibility method and should be avoided. Query parameter access tokens are supported by Google (both v1 and v3), and auth0, but not okta. All three support bearer tokens. However making this the default is complicated by compatibility issues with current behavior. Use standard `sub`ject for identity =================================== The specification defines `sub` as the userinfo key providing the user identifier at the IDP. - auth0, okta, and google v3 use `sub` - google v1 uses `id` - google v1's `tokeninfo` (possibly v3 as well, not tested) uses `user_id` - odoo replicates the google v1 tokeninfo behavior, using `user_id` All the code is now standardised on `sub`, with `_auth_oauth_validate` performing unification under that key. Support non-json error bodies and WWW-Authenticate ================================================== Per-spec, there is no requirement for error (userinfo) responses to return any body, and all error information can be returned via `WWW-Authenticate`. Both auth0 and okta return empty bodies on error, though only okta returns a useful www-authenticate, or relevant 40x statuses (auth0 seems to always return 400, okta has been observed to return both 400 and 401 depending on client error). Error handling in `_auth_oauth_rpc` has been updated to only parse the body as json on success (200), and fallback on a generic error payload if `WWW-Authenticate` doesn't contain relevant information. Nonce ===== Okta requires a nonce to be provided. Misc ==== A few improvements which are in no way required but should make things simpler / clearer: - update the default scope to match the standard for the implicit flow's values (intersected with our requirements) - update the default google configuration to use the v3 endpoints and drop the tokeninfo request, remove the explicit scopes - update the label of `validation_endpoint` to match the official terminology, same with `auth_endpoint` - add a label to `body` in order to explain what it's for (as that's really confusing when the form just says `body` until you hover the field) Expected future updates ======================= These issues were left out and may lead to degraded security, but were considered too large changes fora stable compatibility-oriented update: * store and validate the nonce * request and properly validate the id token, as well as validate the access token (implicit guide sections 2.2.1, 2.2.2) * implement "basic" flow[^basic], and / or "hybrid" flow, the implicit flow[^implicit] is intended for purely client-side applications (SPAs), the "authorization code" flow is intended as the primary flow for normal web applications involving a server component, the main advantage of the hybrid flow is that the id token *can* contain the claims selected by `scope`, avoiding the need for the userinfo request[^idtoken] * remove support for query parameter requests * remove support for Google's v1 oauth and subject identifiers other than `sub`, facebook has not been tested but looks to support that key as well in the OpenGraph API[^fb], this will require migrating existing google providers to v3 implicitly (but would allow simplifying their configuration) References: RFC 6749, RFC 6750, Implicit Client Implementer's Guide 1.0 draft 23[^implicit] Closes #88618, closes #64348, fixes #63963, closes #63970, closes #69568 [^implicit]: https://openid.net/specs/openid-connect-implicit-1_0.html [^basic]: https://openid.net/specs/openid-connect-basic-1_0.html also known as "authorization code" flow [^fb]: https://www.facebook.com/.well-known/openid-configuration [^idtoken]: during testing, only auth0 returned the additional claims as part of the id token, but this may be a configuration issue closes odoo/odoo#91262 X-original-commit: fb3c4845b1549bc2e1378620a5f01e52aa4dbbdb Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com> |
||
|
|
42a3b704f7 |
[ADD] knowledge: manage knowledge
Purpose
=======
Allow companies to centralize all their knowledge in a specific place they own.
Create wiki-like pages to structure the information and make it easily
available. Leverage those later on while working in the back-end.
Specifications
==============
An article is mainly composed of a title and a body. The later is an html field
that can contain text, images, link to other articles or records from other
models, templates, etc..
Articles will be classified in 4 categories:
- *Workspace:*
The articles are available for each internal users in read or write access.
Only internal users can create, read, modify and delete knowledge articles.
- *Private:*
The articles are only available for the owner. Only internal users
can set an article as private. A private article can be shared to external users
in read access only. If the article is shared with internal users, see Shared
section.
- *Shared:*
The articles are not available for any user except the ones that have been
added as members on it. For the current user, this section contains all the
private article the user shared with someone and all the other's private
articles shared with me.
- *Favorite:* (Additional category for UX)
Articles can be set as favorite and are user specific. Any identified user can
set an article in favorite, as long as the user has access to it. Public users
cannot add articles to favorites. Favorites can be reordered and this ordering
is user specific.
An article can have a parent and multiple children. Each parent and each
children is also an article. Root articles are the highest parent in the
hierarchy and are considered as the *Subject* (aka Topic) of their whole
hierarchy. There is no limit on how many levels there are in the hierarchy.
In the 3 first categories, the articles are listed starting for the root
article. The child articles are listed below their parents only if the user has
access to them. It can be that a user has access to an article that is not
listed in knowledge main view because that user has no access to the parent
article. More information about access below.
Categories are based on the root article. If a children is private, because only
accessible by 1 user, and its parent is accessible by everyone, the children
will be listed in Workspace section.
Technical notes
The following domains apply to assign root articles in the different categories:
- Private: permission 'none', only member = uid
- Shared: permission 'none', more than one member with read/write access
- Workspace: other
In addition, the UX category
- Favorite: is_user_favorite = True (can contain articles from any category)
Home View (backend)
===================
The main knowledge view is a tweaked form view that displays all the accessible
root articles and their accessible children in a side panel hierarchic tree.
This side panel allow quick access to each articles without having to navigate
back to a list or kanban view. This form view mainly displays the title and the
body but also integrate custom buttons to manage and search the articles.
All those buttons + the side panel are detailed below.
This "Home" view is loading displaying the first favorite article of the
user. If the user has no favorite, it falls back to the first root article of
Workspace section.
The default view mode depends on the user access:
- If user can read: readonly mode
- If user can write: edit mode
Search View
-----------
The standard list view will be used as an advanced search to find an article
that cannot be found easily via the command palette (ctrl+K). All the searching
options remains standard (search / filter / group by). Selecting an article in
that view will redirect to the home view (displaying the selected article).
Side Panel
----------
- *Reorder and hierarchy:*
From the side panel, drag and dropping an article can resequence the articles
between them and/or change the parent of the moved article.
Note on reordering:
Each parent have its own sequence for its children. So the sequence is not
common for each articles in the database, but specific for the children of a
same parent. The resequencing is done among the children of the same parent.
If some articles has no parent, there are considered as the root articles and
all root articles have their own sequence too.
- *Create:*
From the hierarchy tree, the user can directly create an article using the '+'
signs:
- as root of Workspace or Private section
- as a child of a target article.
- *Fold/Unfold:*
To speed up Home page loading: only first level is loaded + the articles that
user already unfolded in the past. The app keeps track of unfolded articles per
user (using Local Storage).
- *Icon:*
Each article has an icon associated with it. The user can click on the icon to
change it.
- *Search an article:*
This button opens the command palette to perform a search on articles.
More detail on this in the Advanced Feature section (below).
Article header and Button Menu
------------------------------
- *Breadcrumb:*
Located on the top left of the main view, the breadcrumb can be used to edit the
article title.
- *Favorite:*
Next to the title, a star button can be used to add/remove the article to/from
the favorite.
- *Create:*
Creates a new private root article.
- *Share:*
Opens the permission panel. This is where the user can configure the access on
the article or, if user has no write access, see what are the access rules on the
article. More detail on this panel in the Access Rules section (below).
- *Chatter:*
Toggle the chatter On/Off at the right of the article view.
There users can:
- Send messages and log notes
- Schedule activities
- Follow an article
The following buttons can found in the kebab menu, in which we can also find
who created or edited the article last and when.
- *Move To:*
Opens a modal to select the parent under which the current article should be
moved. The article will be placed as the last children of the selected parent.
- *Lock:*
When activated, prevents all edition of the article content (body and title)
until it is unlocked. (Purpose: avoid accidental edits)
- *Duplicate:*
Creates a copy of the current article, under the same parent, but does not copy
the children articles. The new created article will have the same access rules
as the original article.
- *Archive:*
Will archive the current article and all its children. Archived articles can be
retrieved using the Advanced Search (see below for detail) with "Archived"
filter.
- *Full Width:*
By default, the article is centered in the view, to make it easier to read.
If needed, the can activate the full width. This will make the article body take
full width available on the article view. This option impacts the rendering of
article, also in the frontend view. More detail on the Frontend View below.
Body
----
The body is composed of an html field that can be edited using the Odoo Editor
and all its capabilities. Some new commands have been added to enrich the
editor: /template - /file - /article (More details in Advanced Features section)
At the top of the article body, the article icon and cover can be added using
their respective "Add" buttons.
- *Icon:*
Can be modified by simply clicking on it.
- *Cover:*
Can be modified using the "Pen" icon at the top left of the cover,
and deleted using the "Bin" icon at the top right.
Frontend View
=============
The frontend view is basically a simpler version of the backend view where users
can only read the article and add them to their favorites (if user is
identified).
The frontend view is composed of the side panel in the left, the article title
and favorite button on the top and the main body view.
From the side panel, the user can navigate to each available article, reorganize
them favorites and filter the articles using the search bar.
From the main body view, the user can consult the content of the article and
download eventual attached files from the '/file' sections.
Access Rules
============
Basics
------
The access is defined depending on two criteria:
- The Internal Permission
- The article members and their permission
Both have 3 level of permission:
- none (No Access)
- read
- write
The internal Permission is the base permission for internal users. By default,
all internal users can write on the article, unless the permission have been
downgraded to 'Read' or 'No access'.
An internal user however can be added as a member of the article with a
specific permission that applies only for them. This member permission takes the
priority on the internal permission.
The internal users will always be redirected to the backend view when they want
to consult an article.
By default, external users (portal or public users) cannot have access to the
articles, unless they have been added as member. They can only be invited with
read acces on the articles.
External users will always be redirected to the frontend view when they want to
consult an article they have access to.
An administrator (group_system) will always have write access, even if
permissions tell the contrary. However, only the articles they have the
permission to see or write on will be listed in the side panel. They can find
the other articles in the Advanced Search view.
Only the users with write access can edit the article body and title, reorder or
change the parents and children, invite members and edit the access rules of the
article.
- *Constraint:*
An article should always have at least one user having write access on it.
- *Lock mechanism:*
Only users with write access can lock or unlock the article.
when an article is locked, the title and body of the article cannot be edited,
even by a user with write access on it.
Access Inheritance
------------------
By default, a child article inherit the access rules from its parent.
That means that access rules can be defined on the root article and those rules
will apply for each descendant article (children and their own children, etc.).
However, a child article can have specific rules that will apply only on itself
(+ its descendant):
- *Synchronized:*
That can be done by adding a member on that article, or by upgrading any of the
permission based on its parent(s). In that case, the article access rules still
depend on its parent(s). If an additional member is added on the parent,
the child article will still inherit that member. The rules that applies
specifically on the child article have the priority on the inherited rules.
- *Detached:*
When an access rule is downgraded in a child article that initially depends on
parent's access rules, the article access rules are detached from the parent's
access rules. All the access rules that applied on the parent are copied on the
child article and that article is flagged as detached. The children of that
article will, for now on, only depend on it, and not on higher parents anymore.
An detached article can be resyncronized with its parent. In that case, all the
specific access rules that do not apply on its parent will be removed. The child
article will still keep its specific upgraded access rules but will, once again,
depends on its parent.
Share Modal (and access rules application)
------------------------------------------
The share modal (or permission panel) is where the access rules of an article
can be configured.
From there, a user with write access can:
- *Invite new members:*
A modal opens and the user can:
- add existing partners or type email addresses and create new partners
- select the permission that should apply on all selected partners.
If there are external users among the selected partners, only the read access
can be used. That means that if the user select:
- Write permission: the read permission will be given to that partner.
- No Access: The partner will not be added the members.
An invitation email is sent to the invited partner.
If the partner is already registered (has an active user), them can directly
access the article with the link provided in the email. They may need to log in
first.
If a partner is not yet registered (have no user), when using the link provided
in the email, them will be asked to register first, and will be afterwards
redirected to the article.
- *Modify the Internal Permission:*
The user can select the new permission to set for all internal users.
- Special use cases:
- If the user sets internal permission != write, the user will be added as
member with write access. The purpose is to let the user continue to edit the
article.
- When downgrading internal permission on a child article (that depends on its
parent), detach it from parent in terms of access rules.
- when upgrading internal permission on a child article, just set the
permission. The article is not detached from parent, but the article will use
its own internal permission to compute the user accesses.
- *Modify a member's permission:*
The user can select the new permission to set on the target member. The user can
also remove a member.
- Special use cases:
- When downgrading or removing a member based on parent: Detach the article
from it's parent
- When upgrading a member based on parent: add a new member with the selected
permission.
Website Published (Access for public users)
-------------------------------------------
When the Website App is installed, users have the possibility to publish the
articles. When an article is published, everyone can read the article.
- *Internal users* can read a published article even if their permissions does not
allow them to read it. They can access those published articles like every other
articles, still in backend view.
- *Portal users* can read a published article even if their permissions does not
allow them to read it. They can access those published articles like every other
articles, still in frontend view.
- *Public users* can read a published article. They can access it by using the
article link from the frontend view.
Advanced Features
=================
Search and Advanced Search
--------------------------
- *Command Palette:*
Searching is done through the command palette. Just as we have '#' for channels,
'/' for menus and '@' for users, '?' has been added for articles.
The command palet is accessible by either
- Hitting CTRL+K (and then adding ? to search among articles)
- Clicking on the fa-book icon of the chatter, which already
adds the '?' so that one can start searching straight away.
- Clicking on the "Search An Article" button (in the side panel)
while reading another article, where the '?' is automatically added too)
The search result are ordered as followed:
My Favorites > Most Favorites > the rest.
The results display the article name + the subject (highest parent name).
If no results are found and user have write access, them can create a new
(private) article with the search query as title.
- *Advanced Search:*
If the user is not happy with the search results, them can do an
"Advanced Search", which sends me towards a normal Odoo list view where I can
search, filter, groupby, ...
Editor Commands
---------------
Some new editor commands have been added:
- */article:*
This command is available on every html field using the Odoo Editor.
This command allows to add a direct link to the selected knowledge article.
- */file:*
This command is only available in the Knowledge App.
This command allows to add a file (or an image) download button inside the
body. The user can choose a file to add from its own file directory or an
existing attachment already present in the database.
- */template:*
This command is only available in the Knowledge App.
This command allows the user to create a block where them can write and lay out
content destined to be reused by the readers of the article. The lasts will be
able to copy and paste it to send it as message or use it as a description on
other records.
No /command can be added inside a template.
Technical notes:
/file and /template commands can be activated in other modules by adding
knowledge_commands = True on the html field in the view where they should
be activated.
Technical considerations
========================
Access Rules Computation
------------------------
Articles access rules are based on inheritance from parent articles. Purpose is
to avoid making copies of all member rules on each article in the hierarchy.
This allows to lower database storage. The counter part is that the computation
of user accesses is made more complex. Instead of simply reading the article
internal permission and members permissions on the article, access is computed
based on each parent above the article.
To speed up batch compute, user permissions are computed directly with recursive
SQL queries. They collect all the needed information for multiple users (based
on their partner) and multiple articles.
Ordering on is_user_favourite
-----------------------------
To allow ordering on is_user_favourite computed field, the search method have
been overridden to add the favorite articles of the current user to the search
result. This is used in the advanced search view but will also be used in
the ctrl+K command.
Sequences and resequencing
--------------------------
Sequences in knowledge article does not respect the conventional sequencing
(one sequence for all the records of the model). Instead, the sequence is
specific for all children of same parents. Resequence had to be overridden to
take that into account and only resequence the children of same parent, and not
the entire table. Moving an article in the middle of a 'folder' should not
impact the other folders but only the children of that target folder.
Breadcrumb
----------
On the form view, the breadcrumb will be located in the control panel.
For the knowledge module, we needed a headless layout. In the mockup,
the breadcrumb has to be placed within the form sheet.
Unfortunately, the breadcumb is a owl component and its logic is
encapsulated in a function which makes it not editable.
To avoid having to update the core, we will render a custom breadcumb
that will be generated based on the `breadcrumb` parameter passed to the
`init` function of the form view.
Task-2674460
closes odoo/odoo#82315
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Julien Banken <jbn@odoo.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Fabio Barbero <faba@odoo.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Aurelien Warnong <awa@odoo.com>
|
||
|
|
419377ab3d |
[IMP] knowledge: generate private tutorial article per user
To ease onboarding on the knowledge application, this commit allows to generate one tutorial/welcome article in the private section of each existing or new user. That tutorial article can directly be edited by the users to test all the functionnality of the Knowledge App. To avoid generating those articles, a context key can be used: - knowledge_skip_onboarding_article Task-2674460 Part-of: odoo/odoo#82315 Co-authored-by: Damien Abeloos <abd@odoo.com> Co-authored-by: Julien Banken <jbn@odoo.com> Co-authored-by: David Beguin <dbe@odoo.com> Co-authored-by: Fabio Barbero <faba@odoo.com> Co-authored-by: Thibault Delavallee <tde@odoo.com> Co-authored-by: Aurelien Warnong <awa@odoo.com> |
||
|
|
05c7433789 |
[IMP] knowledge: add /article command and open article link in editor
This commit adds /articlde command that can be used in the html editor. Editor Commands --------------- - */article:* This command is available on every html field using the Odoo Editor. This command allows to add a direct link to the selected knowledge article. Task-2674460 Part-of: odoo/odoo#82315 Co-authored-by: Damien Abeloos <abd@odoo.com> Co-authored-by: Julien Banken <jbn@odoo.com> Co-authored-by: David Beguin <dbe@odoo.com> Co-authored-by: Fabio Barbero <faba@odoo.com> Co-authored-by: Thibault Delavallee <tde@odoo.com> Co-authored-by: Aurelien Warnong <awa@odoo.com> |
||
|
|
3cd87ca0dc |
[IMP] knowledge: add the template and file commands
This commit adds some commands that can be used in the html editor. Editor Commands --------------- Some new editor commands have been added: - */article:* This command is available on every html field using the Odoo Editor. This command allows to add a direct link to the selected knowledge article. - */file:* This command is only available in the Knowledge App. This command allows to add a file (or an image) download button inside the body. The user can choose a file to add from its own file directory or an existing attachment already present in the database. - */template:* This command is only available in the Knowledge App. This command allows the user to create a block where them can write and lay out content destined to be reused by the readers of the article. The lasts will be able to copy and paste it to send it as message or use it as a description on other records. No /command can be added inside a template. Technical notes: /file and /template commands can be activated in other modules by adding knowledge_commands = True on the html field in the view where they should be activated. Task-2674460 Part-of: odoo/odoo#82315 Co-authored-by: Damien Abeloos <abd@odoo.com> Co-authored-by: Julien Banken <jbn@odoo.com> Co-authored-by: David Beguin <dbe@odoo.com> Co-authored-by: Fabio Barbero <faba@odoo.com> Co-authored-by: Thibault Delavallee <tde@odoo.com> Co-authored-by: Aurelien Warnong <awa@odoo.com> |
||
|
|
0727bbe8f1 |
[IMP] website_knowledge: allow public users to access published articles
This commit gives the read access to public users to published articles (website_published = True). Task-2674460 Part-of: odoo/odoo#82315 Co-authored-by: Damien Abeloos <abd@odoo.com> Co-authored-by: Julien Banken <jbn@odoo.com> Co-authored-by: David Beguin <dbe@odoo.com> Co-authored-by: Fabio Barbero <faba@odoo.com> Co-authored-by: Thibault Delavallee <tde@odoo.com> Co-authored-by: Aurelien Warnong <awa@odoo.com> |
||
|
|
661f98be3c |
[ADD] knowledge: manage knowledge
Purpose
=======
Allow companies to centralize all their knowledge in a specific place they own.
Create wiki-like pages to structure the information and make it easily
available. Leverage those later on while working in the back-end.
Specifications
==============
An article is mainly composed of a title and a body. The later is an html field
that can contain text, images, link to other articles or records from other
models, templates, etc..
Articles will be classified in 4 categories:
- *Workspace:*
The articles are available for each internal users in read or write access.
Only internal users can create, read, modify and delete knowledge articles.
- *Private:*
The articles are only available for the owner. Only internal users
can set an article as private. A private article can be shared to external users
in read access only. If the article is shared with internal users, see Shared
section.
- *Shared:*
The articles are not available for any user except the ones that have been
added as members on it. For the current user, this section contains all the
private article the user shared with someone and all the other's private
articles shared with me.
- *Favorite:* (Additional category for UX)
Articles can be set as favorite and are user specific. Any identified user can
set an article in favorite, as long as the user has access to it. Public users
cannot add articles to favorites. Favorites can be reordered and this ordering
is user specific.
An article can have a parent and multiple children. Each parent and each
children is also an article. Root articles are the highest parent in the
hierarchy and are considered as the *Subject* (aka Topic) of their whole
hierarchy. There is no limit on how many levels there are in the hierarchy.
In the 3 first categories, the articles are listed starting for the root
article. The child articles are listed below their parents only if the user has
access to them. It can be that a user has access to an article that is not
listed in knowledge main view because that user has no access to the parent
article. More information about access below.
Categories are based on the root article. If a children is private, because only
accessible by 1 user, and its parent is accessible by everyone, the children
will be listed in Workspace section.
Technical notes
The following domains apply to assign root articles in the different categories:
- Private: permission 'none', only member = uid
- Shared: permission 'none', more than one member with read/write access
- Workspace: other
In addition, the UX category
- Favorite: is_user_favorite = True (can contain articles from any category)
Home View (backend)
===================
The main knowledge view is a tweaked form view that displays all the accessible
root articles and their accessible children in a side panel hierarchic tree.
This side panel allow quick access to each articles without having to navigate
back to a list or kanban view. This form view mainly displays the title and the
body but also integrate custom buttons to manage and search the articles.
All those buttons + the side panel are detailed below.
This "Home" view is loading displaying the first favorite article of the
user. If the user has no favorite, it falls back to the first root article of
Workspace section.
The default view mode depends on the user access:
- If user can read: readonly mode
- If user can write: edit mode
Search View
-----------
The standard list view will be used as an advanced search to find an article
that cannot be found easily via the command palette (ctrl+K). All the searching
options remains standard (search / filter / group by). Selecting an article in
that view will redirect to the home view (displaying the selected article).
Side Panel
----------
- *Reorder and hierarchy:*
From the side panel, drag and dropping an article can resequence the articles
between them and/or change the parent of the moved article.
Note on reordering:
Each parent have its own sequence for its children. So the sequence is not
common for each articles in the database, but specific for the children of a
same parent. The resequencing is done among the children of the same parent.
If some articles has no parent, there are considered as the root articles and
all root articles have their own sequence too.
- *Create:*
From the hierarchy tree, the user can directly create an article using the '+'
signs:
- as root of Workspace or Private section
- as a child of a target article.
- *Fold/Unfold:*
To speed up Home page loading: only first level is loaded + the articles that
user already unfolded in the past. The app keeps track of unfolded articles per
user (using Local Storage).
- *Icon:*
Each article has an icon associated with it. The user can click on the icon to
change it.
- *Search an article:*
This button opens the command palette to perform a search on articles.
More detail on this in the Advanced Feature section (below).
Article header and Button Menu
------------------------------
- *Breadcrumb:*
Located on the top left of the main view, the breadcrumb can be used to edit the
article title.
- *Favorite:*
Next to the title, a star button can be used to add/remove the article to/from
the favorite.
- *Create:*
Creates a new private root article.
- *Share:*
Opens the permission panel. This is where the user can configure the access on
the article or, if user has no write access, see what are the access rules on the
article. More detail on this panel in the Access Rules section (below).
- *Chatter:*
Toggle the chatter On/Off at the right of the article view.
There users can:
- Send messages and log notes
- Schedule activities
- Follow an article
The following buttons can found in the kebab menu, in which we can also find
who created or edited the article last and when.
- *Move To:*
Opens a modal to select the parent under which the current article should be
moved. The article will be placed as the last children of the selected parent.
- *Lock:*
When activated, prevents all edition of the article content (body and title)
until it is unlocked. (Purpose: avoid accidental edits)
- *Duplicate:*
Creates a copy of the current article, under the same parent, but does not copy
the children articles. The new created article will have the same access rules
as the original article.
- *Archive:*
Will archive the current article and all its children. Archived articles can be
retrieved using the Advanced Search (see below for detail) with "Archived"
filter.
- *Full Width:*
By default, the article is centered in the view, to make it easier to read.
If needed, the can activate the full width. This will make the article body take
full width available on the article view. This option impacts the rendering of
article, also in the frontend view. More detail on the Frontend View below.
Body
----
The body is composed of an html field that can be edited using the Odoo Editor
and all its capabilities. Some new commands have been added to enrich the
editor: /template - /file - /article (More details in Advanced Features section)
At the top of the article body, the article icon and cover can be added using
their respective "Add" buttons.
- *Icon:*
Can be modified by simply clicking on it.
- *Cover:*
Can be modified using the "Pen" icon at the top left of the cover,
and deleted using the "Bin" icon at the top right.
Frontend View
=============
The frontend view is basically a simpler version of the backend view where users
can only read the article and add them to their favorites (if user is
identified).
The frontend view is composed of the side panel in the left, the article title
and favorite button on the top and the main body view.
From the side panel, the user can navigate to each available article, reorganize
them favorites and filter the articles using the search bar.
From the main body view, the user can consult the content of the article and
download eventual attached files from the '/file' sections.
Access Rules
============
Basics
------
The access is defined depending on two criteria:
- The Internal Permission
- The article members and their permission
Both have 3 level of permission:
- none (No Access)
- read
- write
The internal Permission is the base permission for internal users. By default,
all internal users can write on the article, unless the permission have been
downgraded to 'Read' or 'No access'.
An internal user however can be added as a member of the article with a
specific permission that applies only for them. This member permission takes the
priority on the internal permission.
The internal users will always be redirected to the backend view when they want
to consult an article.
By default, external users (portal or public users) cannot have access to the
articles, unless they have been added as member. They can only be invited with
read acces on the articles.
External users will always be redirected to the frontend view when they want to
consult an article they have access to.
An administrator (group_system) will always have write access, even if
permissions tell the contrary. However, only the articles they have the
permission to see or write on will be listed in the side panel. They can find
the other articles in the Advanced Search view.
Only the users with write access can edit the article body and title, reorder or
change the parents and children, invite members and edit the access rules of the
article.
- *Constraint:*
An article should always have at least one user having write access on it.
- *Lock mechanism:*
Only users with write access can lock or unlock the article.
when an article is locked, the title and body of the article cannot be edited,
even by a user with write access on it.
Access Inheritance
------------------
By default, a child article inherit the access rules from its parent.
That means that access rules can be defined on the root article and those rules
will apply for each descendant article (children and their own children, etc.).
However, a child article can have specific rules that will apply only on itself
(+ its descendant):
- *Synchronized:*
That can be done by adding a member on that article, or by upgrading any of the
permission based on its parent(s). In that case, the article access rules still
depend on its parent(s). If an additional member is added on the parent,
the child article will still inherit that member. The rules that applies
specifically on the child article have the priority on the inherited rules.
- *Detached:*
When an access rule is downgraded in a child article that initially depends on
parent's access rules, the article access rules are detached from the parent's
access rules. All the access rules that applied on the parent are copied on the
child article and that article is flagged as detached. The children of that
article will, for now on, only depend on it, and not on higher parents anymore.
An detached article can be resyncronized with its parent. In that case, all the
specific access rules that do not apply on its parent will be removed. The child
article will still keep its specific upgraded access rules but will, once again,
depends on its parent.
Share Modal (and access rules application)
------------------------------------------
The share modal (or permission panel) is where the access rules of an article
can be configured.
From there, a user with write access can:
- *Invite new members:*
A modal opens and the user can:
- add existing partners or type email addresses and create new partners
- select the permission that should apply on all selected partners.
If there are external users among the selected partners, only the read access
can be used. That means that if the user select:
- Write permission: the read permission will be given to that partner.
- No Access: The partner will not be added the members.
An invitation email is sent to the invited partner.
If the partner is already registered (has an active user), them can directly
access the article with the link provided in the email. They may need to log in
first.
If a partner is not yet registered (have no user), when using the link provided
in the email, them will be asked to register first, and will be afterwards
redirected to the article.
- *Modify the Internal Permission:*
The user can select the new permission to set for all internal users.
- Special use cases:
- If the user sets internal permission != write, the user will be added as
member with write access. The purpose is to let the user continue to edit the
article.
- When downgrading internal permission on a child article (that depends on its
parent), detach it from parent in terms of access rules.
- when upgrading internal permission on a child article, just set the
permission. The article is not detached from parent, but the article will use
its own internal permission to compute the user accesses.
- *Modify a member's permission:*
The user can select the new permission to set on the target member. The user can
also remove a member.
- Special use cases:
- When downgrading or removing a member based on parent: Detach the article
from it's parent
- When upgrading a member based on parent: add a new member with the selected
permission.
Website Published (Access for public users)
-------------------------------------------
When the Website App is installed, users have the possibility to publish the
articles. When an article is published, everyone can read the article.
- *Internal users* can read a published article even if their permissions does not
allow them to read it. They can access those published articles like every other
articles, still in backend view.
- *Portal users* can read a published article even if their permissions does not
allow them to read it. They can access those published articles like every other
articles, still in frontend view.
- *Public users* can read a published article. They can access it by using the
article link from the frontend view.
Advanced Features
=================
Search and Advanced Search
--------------------------
- *Command Palette:*
Searching is done through the command palette. Just as we have '#' for channels,
'/' for menus and '@' for users, '?' has been added for articles.
The command palet is accessible by either
- Hitting CTRL+K (and then adding ? to search among articles)
- Clicking on the fa-book icon of the chatter, which already
adds the '?' so that one can start searching straight away.
- Clicking on the "Search An Article" button (in the side panel)
while reading another article, where the '?' is automatically added too)
The search result are ordered as followed:
My Favorites > Most Favorites > the rest.
The results display the article name + the subject (highest parent name).
If no results are found and user have write access, them can create a new
(private) article with the search query as title.
- *Advanced Search:*
If the user is not happy with the search results, them can do an
"Advanced Search", which sends me towards a normal Odoo list view where I can
search, filter, groupby, ...
Editor Commands
---------------
Some new editor commands have been added:
- */article:*
This command is available on every html field using the Odoo Editor.
This command allows to add a direct link to the selected knowledge article.
- */file:*
This command is only available in the Knowledge App.
This command allows to add a file (or an image) download button inside the
body. The user can choose a file to add from its own file directory or an
existing attachment already present in the database.
- */template:*
This command is only available in the Knowledge App.
This command allows the user to create a block where them can write and lay out
content destined to be reused by the readers of the article. The lasts will be
able to copy and paste it to send it as message or use it as a description on
other records.
No /command can be added inside a template.
Technical notes:
/file and /template commands can be activated in other modules by adding
knowledge_commands = True on the html field in the view where they should
be activated.
Technical considerations
========================
Access Rules Computation
------------------------
Articles access rules are based on inheritance from parent articles. Purpose is
to avoid making copies of all member rules on each article in the hierarchy.
This allows to lower database storage. The counter part is that the computation
of user accesses is made more complex. Instead of simply reading the article
internal permission and members permissions on the article, access is computed
based on each parent above the article.
To speed up batch compute, user permissions are computed directly with recursive
SQL queries. They collect all the needed information for multiple users (based
on their partner) and multiple articles.
Ordering on is_user_favourite
-----------------------------
To allow ordering on is_user_favourite computed field, the search method have
been overridden to add the favorite articles of the current user to the search
result. This is used in the advanced search view but will also be used in
the ctrl+K command.
Sequences and resequencing
--------------------------
Sequences in knowledge article does not respect the conventional sequencing
(one sequence for all the records of the model). Instead, the sequence is
specific for all children of same parents. Resequence had to be overridden to
take that into account and only resequence the children of same parent, and not
the entire table. Moving an article in the middle of a 'folder' should not
impact the other folders but only the children of that target folder.
Breadcrumb
----------
On the form view, the breadcrumb will be located in the control panel.
For the knowledge module, we needed a headless layout. In the mockup,
the breadcrumb has to be placed within the form sheet.
Unfortunately, the breadcumb is a owl component and its logic is
encapsulated in a function which makes it not editable.
To avoid having to update the core, we will render a custom breadcumb
that will be generated based on the `breadcrumb` parameter passed to the
`init` function of the form view.
Task-2674460
Part-of: odoo/odoo#82315
Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Julien Banken <jbn@odoo.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Fabio Barbero <faba@odoo.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Aurelien Warnong <awa@odoo.com>
|