1. A menu with `/page/website.***` should be flagged as `active`
if the current url is `/page/***`. This is a retro-compatibility
patch for c9d41679fb, so the
menu is marked as active without having to rename it, by
removing this `website.` thing.
2. If you defined two menus with as url `/page/test` and `/page/test2`
Both menus were flagged as `active` when you browsed the url
`/page/test2`, because it started by both menus urls.
Fixes#3059Closes#3070
In the top menu bar, the `active` class is set when the
menu url matches the page url (the url in the browser url bar)
A while ago, we made so all urls
`/page/website.***'
were automatically redirected to
`/page/****`
Therefore, if the menu url still contains this `website.` prefix,
the active class wasn't set on it, while it should.
Fixes#3059Closes#3070
The fields are properly reflected for base many2many fields. Moreover, the
code has been improved to remove a custom many2many field whose table is still
used by another field.
Onchange methods have been added:
- When name, model and comodel are chosen, propose table and column names.
- When table is modified, propose column names if the table is already used by
another many2many field.
When ordering results on a many2one fields, results are ordered by
order of the target model. The code was wrongly assuming that this
`_order` attribute only contains `_classic_read` fields (that can be
directly read from the table in database). Now correctly generate the
"ORDER BY" clause using the current table alias.
`res.users` can now be sorted by name.
The dataset implementation has been improved to handle the result of a `read`
on ids that are already modified in the dataset: the lists `to_create` and
`to_write` are updated properly.
Use `field.convert_to_onchange` to format the output of method `onchange`. By
default it behaves like `convert_to_read`. This is useful for the many2one
case, as the client automatically receives the display name of the record.
For the *2many case, we return a list of dicts values, in recordset order, with
all the known fields in the view:
[{id: 42, name: "Existing record"}, {name: "New record"}, ...]
Each dictionary contains the values of all known fields in the view. The
client is responsible of determining which fields are dirty by computing the
difference with former values.
Since the method `onchange` now uses `field.convert_to_onchange`, the method
`field.convert_to_write` has been simplified, as it no longer needs its extra
parameters `target` and `fnames`.
Titles are now just for contacts (people), not for companies
anymore. For that purpose directly adding the suffix (Ltd, ...)
in the name is sufficient.
The domain field is therefore removed.
Updated data, demo, views, code and res.partner model accordingly.
I do not think portal users need to log the holidays or the see the list of installed modules
Also, I got tired of the generic cube icon for portal in the new design; feel free to change it if you find something more meaningful
- remove public project
- some data was depending on demo data, moved it to demo
- add website_published mixin on projects
- remove project members from frontend view
Since public projects do not exist anymore, project.project objects now have the website_published mixin; any project with the rating activated and published on the website will be visible in the "Project Customer Satisfaction" link for public users
The frontend template has also been modified to remove the team members photo since project members have disappeared as of 9398fe9 by our dear @tde-banana-odoo
[ADD] website_project_issue_sheet: link module between website_project_issue and project_issue_sheet
Frontend integration of issues:
- issues details
- chatter integration
- timesheets
[REM] portal_project: move ALL the things
- move portal access rights from portal_project and website_project_issue to project and project_issue
- move portal menuitems back to their respective module
- remove public visibility of projects
- adapt demo data to have a 'Demo Portal' project
- add correct access rights for account.analytic.line for portal users
- small view tweak (do not display 'timesheet' tab if one can't see antyhing in it anyway)
- don't add comments in posbox ld.so.preload, it causes the second line to be
interpreted as a library.
- allow image creation in headless environment. This checks whether or not X is
running and runs qemu-system-arm with or without graphics.
When creating a new bank account
e.g. Accounting > Configuration > Accounts >
Setup your Bank Accounts
When the user leaves the journal blank,
a journal, and an account associated to this
journal, are automatically created.
The account type of the account created could be wrong,
as it used the account type of the parent of the first
account of internal type `Liquidity`, which
could not be an account of account type Cash or Bank, but of
account type 'View', and such an account type does not
have the right delivery forward method, in order to report
correctly the amounts when closing a fiscal year.
Instead of using the account type of the parent,
it should actually uses the account type of the sibbling,
which have a correct delivery forward method
opw-647311
This dashboard has implied some refactoring:
- the wizard pos_session_opening has been deleted and all the methods have been put inside pos_config
- new fields in pos_config to display some useful informations (closing balance, closing date, etc.)
Christophe Matthieu