Scenario: Go to any list or kanban view: go to next page and set a
filter that matches less that 'limit' record (e.g. less than 40),
but at least one. No record will be displayed, because the offset
is kept for the search_read.
This rev. ensures to reset the offset to 0 when a search is done
using the searchview.
The app switcher in the enterprise branch introduces a new way to whitelist the
element in the app switcher. This commit apply this mechanism to the mail windows.
When paying in other currency that the one defined in the company, it
generates a payment which has to be in the currency of the transaction.
Otherwise it will generate an invoice which won't be completely paid.
opw:769278
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
Here is what could (sometimes) happen in community:
- the point of sale tour is started by the runbot
- it loads the '/web' url
- this instantiate the mail client action (init)
- the tour sees that the POS link is in the dom and clicks on it
- the action manager destroys the discuss client action (before its
start method is called)
- the destroy method from the client action is called, this.$buttons
is not set, the destroy method causes a traceback
Since python3 compare boolean and string is not
possible anymore. Priority field on stock move line is
not required and thus it happens that we compare a set
priority with an unset one.
In order to correct it this commit only compares move line
that have priority and if tey are not use the default priority
1.
Orderpoint has been removed by this commit 0e4f3bb959
However it was still used in the overide of product write in
order to avoid archive a product that still have active orderpoint.
This commit readd the field orderpoint_ids
The rationale for the need of a merge move mechanism is that, with the new default view,
having multiple stock move for the same products is confusing. The idea is that if a move
is confirmed in a picking already having a move with the same characteristics, we update
the existing move and unlink the new one. That’s why it’s done at the end of `_action_confirm`.
In some cases, merging moves is unwanted (backordered moves for examples). Therefore, we chose
to add a kwarg to `_action_confirm` in order do control the mechanism.
Before when comuting state picking there was a computation
among all moves in order to guess the picking state.
However this code could be reuse in other scenario for
example in merge moves.
In order to avoid code duplication this commit move the
part responsible for the state computation among moves
in a specific method inside stock move file.
When the mockserver handles an unimplemented route, it just log an
error. This is annoying because it does not break the QUnit suite, so
if the developer does not look at the console, it will look like the
test suite pass. However, the runbot will see that as an error.
With this commit, we throw an error to force the test suite to fail in
that case.
Before this commit, there was a crash when sorting a one2many in a form view.
This is due to the fact that the event from the one2many bubbled up to
the main form view, which basically assumed that it was supposed to sort
some sub one2many.
It could be seen for example when editing a 'attribute' in a product
form view (need to activate variants), then sorting the 'attribute
values' sub one2many.
With this commit, we simply stop the event propagation at the correct
level.
- Load more was invisible; now also add a little bit of styling
- Small column records were not centered in their column
- Add a column padding bottom to allow seeing reaching the scrollend
- Column create was misaligned since some padding changes
* 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
- Go in Accounting > Sales > Payment
- Fill the mandatory info, and create a "Payment Transaction"
- On the form view, change the Partner
- The Customer Details are empty, and saving is not possible since the
country (mandatory) is not filled in
Closes#15708
opw-771753
Purpose: Add button to see the number of
abandoned carts and the ability to send
a recovery email to those customers.
On the abandoned carts menu, you can see
the SO from the website where no reminder
email has been sent.
By selecting them, you can send an email
to the customer to tell him there is still
a cart waiting.
Clicking on the link, he can reuse his old
cart or merge it with his current one.
An abandoned cart is a SO from a website
sales team, and created after a treshold
parametered by a 'delay' settings (number
of hours to be considered as abandoned).
The `upgrade_boolean` widget should display an `Enterprise` label next to it.
There is however an issue when a `label` is specified for this field. In this case,
the `Enterprise` label should be placed next to the field label (and not the field
itself).
The easiest solution would have been to instantiate the field widget with its label,
but this can't work because the field widget is instantiated before its label.
We thus re-render the widget after its label creation.
Hardik Patel