Before this commit:
1. If the website's homepage is unpublished and a public user naviguate on it,
it will log an access read error in the server. The user won't see the error
though.
2. If the user can't access '/', we serve the first menu's page instead.
This first menu's page can be an unpublished page, resulting in a 403, which is
not convenient.
3. Menus are sorted by sequence, then the ORM sort them by write_date.
Menu with same sequence will be sorted differently every time you edit one of
them. (This issue get hidden/solved if user edit and save the menus with
"Edit Menu" since it will recompute every sequence.)
- Create 3 pages 'A', 'B', 'C', with 'Add page in menu' enabled
- Menu is now 'A B C'
- Edit website.page B (in property dialog), it will write on the page's menu
aswell
- Menu is now 'A C B'
Now:
1. We prevent this error by ensuring the page is published and so can be read
by anyone before accessing its properties.
2. We serve the first menu's page that is published
3. We sort menu by id after sequence to keep original order
This closes#21259
Before this commit, if there was a menu entry linked to an unpublished
website.page, the menu would be shown. For restricted users, they would land on
a 403 forbidden.
Now, we dont show website.page's menu if user can't access it.
This closes#21328
Before this commit, if a website.menu had a URL set to null, it would throw an
error when displaying that menu.
It is normally not possible to do so in v11 but after a migration, menus can be
empty. (eg: Using an empty menu to display a divider in a dropdown menu)
Now we return an empty url instead of an error
This field should be required.
This commits closes#21997
@kangol: diff in addons/website/models/ir_http.py is for existing db
It can be ignored in master because required will be apply
1. Create a new user with all the permissions as manager (or at least
Accounting) except Inventory
2. Login and then go to Invoicing --> Settings
3. Do a minor change, save
An access error occurs.
Since the settings of all modules are smartly loaded in v11, it now
implies that a user must have extra manager access rights to be allowed
to save them. We could have kept separate actions for each setting page,
but we would have missed the fun of access errors.
Anyway, security-wise this is not an issue to force the manager groups
since a user with 'Settings' access rights can change his own rights.
It's just very annoying. Or fun.
Complement of aa65a46fc5Fixes#21766
opw-801210
The "Customize Theme" modal was displayed under the main navbar since
the introduction of the affix feature (especially in some themes). This
is because the main navbar's z-index has been increased for animation
reasons.
In fact, the fix seems simple: the customize modal does not need any
z-index override (it should behave like any modal).
In the module website, the relational field website_id is defined twice,
once for ir_ui_view and a second time for res_config_settings, for the
former we perform an ondelete='cascade', which means that when the
website model is unlinked, the field is unlinked as well.
This is not done for the website_id field in res_config_settings, which
instead defaults to setting the field to NULL, which violates a not-null
constraint and therefore causes issues when trying to modify/save
settings.
To solve this, a hard delete of the ir_model_field website_id is
performed during the uninstall process of the website module.
Fixes#21905
OPW 803018
Before this commit, website had incomplete context.
It was causing website.menu to not be translated correctly because lang was
not set on website.
Now, since the website has the context correctly binded, menus are translated
opw-787012
The regional variations are not published on Transifex and hsould be translated
manually.
The translations are mainly from previous versions or contains buggy fuzzy
translations (not matching the real source string).
Clean based on the .pot and delete the empty files
Fixes#21733
Before this commit, editing a website.menu (linked to a website.page (m2o))
would not save the URL on the website.page record but only on the
website.menu.
But since the URL retrieved to display the website navbar is:
1. The website.page url if the menu has a page_id
2. The website.menu url otherwise
It would never get the edited URL stored on website.menu
Clean method _add_dispatch_parameters
Remove unused code for caching
Call super before to have the correct lang when we browse website.
Without it, menu was not loaded in correct language.
The ORM does not currently, an probably won't support two fields with
the same name in different modules that do not depend on each other.
This is obviously a nasty hack, but it's the best one can do for a
stable branch.
THIS IS WHY WE HAVE DEPENDENCY MODULES, PEOPLE.
Purpose
=======
There are some usability issues in the website dashboard
Specification
=============
1/ Move button 'Go to Website' in the header
2/ Hide the action button bar if there's nothing in it
3/ Align the labels in the graph's legend
4/ Make the legend labels and display more obvious
5/ Modify the graph colors to be more readable
6/ Remove margins around todo buttons
Before this fix, the chatter always showed dates of messages in military time format.
This was not the expected behavior, as the user could have had customize
the date and time format in the settings of the current language.
Steps to reproduce the issue:
1. Set Odoo in English
2. Settings > Translations > Languages > English
2.1. Set Date Format to %m/%d/%Y
2.2. Set Time Format to %I:%M:%S %p
3. CRM > (Select any opportunity with at least one message) > Mouse hover on elapsed time (e.g. "an hour ago")
Expected:
- It shows the customized time format (e.g. 11/07/2017 5:33:36 PM)
Results:
- It shows the military time format (e.g. Tue Nov 07 2017 17:33:36 GMT+0100)
opw-781647
Odoo Translation Bot