Introduce a new attachment field (access_token) to allow external
unauthenticated access. This will be an opaque unique number
(typically a UUID) that should be provided via an appropriate
controller, for unauthenticated display.
The field is intended to be NULL unless unauthenticated access has been
allowed, in which case a value will be set for the access_token.
This could be used e.g. for allowing access to images within mailings,
even when the recipient is not logged in (which is sometimes entirely
impossible, when email providers use restricted proxy servers to
load images)
Note 1: this is still a work-in-progress, but serves to freeze the API.
The implementation of the access check and provisioning of the new
field will be added later.
Note 2: namimg collisions with the file download token prevent the use
of a shorter 'token' parameter for download routes.
Apologies for the late (and incomplete) addition in saas-18 :-/
The command does not need to remove existing relations, as there is no relation
yet on new records. This saves one query per many2many field with that command
in a `create`.
If the server was launched with ``--test-enable``, `routing_map` tries to load
the routing map of module `None`, which is the current module being tested...
Changing the address type of a contact in the "Contact & Addresses" tab
could in some instance lead to a dead image (just visually, saving it
would not change it) because the image is set to something like
"data:image/png;base64,5.23 Kb" because of a combination of kanba/form
x2many view, onchange, the differences of field present.
In 9.0 this did not happen because the image was not a field in the form
view corresponding to a contact of the kanban contacts view.
In saa-15 thanks to bf26445 the image_small is different than image in
the kanban view and this got us out of the issue.
In saas-16 it is solved even further because new views only load missing
fields.
This commit just get out of the issue by preventing an update of the
records field (with bin_size which caused the issue of the image) when
opening the modal form view of a contact's contact.
Ideally we should solve this more deeply but this is dangerous code to
change (eg. removing the bin_size would solve it but this was done for a
reason and could affect performances) and the effect is just visual in a
very particular set of factors (if we save the form after the image is
dead, the previous image reappeared).
opw-765952
closes#19491
An update by a list of commands is now guaranteed to have at most three SQL
queries to update the relation, whatever the number of commands and records.
Go to General Settings, click on 'Change Document Template', and
in the opened dialog, click on a template.
Before this rev., it automatically closed the dialog, which was
not really convenient.
This rev. introduces a new field widget (image_selection) for
this use case, and ensures that the dialog doesn't close when
a template is selected.
Test written by @mba-odoo
aka 'Indian localization out of the box'.
Details:
GST introduced, module refactored.
Update GST chart of account, tags and SGST, CGST & IGST taxes.
Replace vat label with GSTIN in reports & views.
Added HSN Code field and display it on invoice form view & report.
Added pin number field in res_country_state.
Show the total amount in words based on Indian numbering system on form view of customer/supplier invoice/refund.
Arrange address format of India country.
l10n_in_schedule6: Introduce new GST taxes, chart of accounts & account tags.
l10n_in_sale, l10n_in_purchase, l10n_in_stock: added modules to add hsn code and replace vat with gstin in sale, purchase & stock reports
Was task: 33241. Was PR #18952
* Fix a bunch of ill-documented/incomplete/incorrect method docs
* add start of Sphinx extension to extract & integrate jsdoc into
Sphinx documentation:
- parse JS files (and don't blow up), uses a fork of pyjsparser as
the project currently does not parse comments
- extract cross-module dependency information
- parse JsDoc comments using pyjsdoc and infer structure from code &
jsdoc
- ``ast`` CLI printing a simplified AST of the input files
- ``dependencies`` creating a dependency graph of either all modules
in the provided input files or the modules matching the specified
filters (warning: will not work if missing dependencies),
generates a .dot file
- ``extractor`` generating a plain text module documentation (mix of
rst and markdown styles, not anything formal)
* sphinx extension with an "automodule" directive taking a module name
and generating the documentation for it
This commit removes the strange selection box based on a magic flag and
some strange methods returning a string. Instead just allow to send mass
mailing on all models inheriting from mail.thread using the is mail
thread flag.
Various addons are updated to remove the _mail_mass_mailing class
attribute used to determine mass mailing capability.
We consider people could send a mass mailing on every model inheriting
from mail.thread. It makes no sense to limit it to a given set of addons.
website.page = old ir.ui.view with page=True
website.redirect is a new mechanism to replace in the futur the ir.attachment
mechanism of redirect.
From now, we don't have a specific /page controller to serve 'page'.
We use a new model website.page which is rendered if none route matches the url
and that the field 'url' on website.page matches the request.httprequest.path.
The order to serve a path is:
- Routes defines in controllers (/shop, /blog, ...)
- ir.attachment with name matching the path
- website.page with url matching the path
- website.redirect with url_from matching the path
- 404
To improve:
- allow regexp in website.redirect model
- allow to edit the view_arch from the page.management via redirect backend
(needed when traceback in the page, or when modifying a js/css/less/...)
Split big universal RNG into view-specific schemas and moved rng based view validation
into view_validation.py file.
Adapt old views, and remove deprecated tag `version="7.0"` from views.
The purpose is to simplify the product configuration.
Adding detailled options about the service tracking
(create task and/or project) make the setup less
confusing for users.
The invoice policy is replaced by "Invoice based"
(only for services). We don't support "ordered
quantities" with "manual" tracking anymore. The
supported use cases are :
- Ordered quantities (using timesheet)
- Timesheet on task (delivered with timesheet)
- Milestones (delivered manually)
Also, even when selecting 'Milestones', the SO line
can generate a task/project, but timesheeting on
thoses objects will not change the delivered
quantities on the SOL. So, a task can always be created
whatever the service invoice policy of the product.
Every generated task or project are linked to their SO
line. But this SO line is only incremented (on delivered
quantity) if its product 'service_type' is timesheet.
Olivier Dony