| Age | Commit message (Collapse) | Author |
|---|
|
stock.picking
What are the steps to reproduce your issue?
1. Install "stock"
2. Go to Inventory/Inventory Overview/Internal Transfer
3. Create new record and set manually a date with year < 1000 like "0008-10-10 18:35:00"
4. Save
What is currently happening?
An error arises when saving the record, and it is then no longer
possible to reopen the records or any view containing it.
This also prevents us from correcting the date to no longer have the error
Why is this happening?
The root cause is an inconsistency in `strftime` for years < 1000 [1, 2]. To take it into
account, a zero-padding is needed in the DateTime parser.
How to fix the bug?
The missing padding is added.
However, such dates lead to problematic behaviors in Python:
```
DT_FORMAT = "%Y-%m-%d %H:%M:%S"
new_date = "0008-02-05 18:10:10"
datetime.strptime(
datetime.strptime(
new_date, DT_FORMAT
).strftime(DT_FORMAT),
DT_FORMAT
)
```
This raises:
```
ValueError: time data '8-02-05 18:10:10' does not match format '%Y-%m-%d %H:%M:%S'
```
As of today there was no reported business cases where dates with year < 1000 would be
necessary. Therefore, we limit the range to years >= 1000.
[1] https://bugs.python.org/issue13305
[2] https://docs.python.org/dev/library/datetime.html#strftime-strptime-behavior
opw-2408260
closes odoo/odoo#62818
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
The BS4 tempusdominus lib has 2 issues within Odoo:
1. On wrong string formating (eg typing "33"), the lib would trigger its own
error "datetimepicker.error" that would be catch in our crash manager making
it display a modal error.
This is generally handled by catching that event and preventing it to bubble
to the crash manager, see:
Datepicker widget: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web/static/src/js/widgets/date_picker.js#L128
OWL datepicker widget: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web/static/src/js/components/datepicker.js#L43
Snippets options: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web_editor/static/src/js/editor/snippets.options.js#L1646
2. If there is a valid date, and an user enter an unvalid date, the lib crashed
by throwing `Cannot read property 'format' of undefined'`.
Datepicker widget: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web/static/src/js/widgets/date_picker.js#L94 (fbbfa6ddca and 5481c429efb)
OWL datepicker widget: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web/static/src/js/components/datepicker.js#L149
Snippets options: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web_editor/static/src/js/editor/snippets.options.js#L1617
Note that the issue was reported at https://github.com/tempusdominus/bootstrap-4/issues/223
Those errors can be seen for instance in Page Properties dialog (publish date
field) and in the form builder snippet if you add a date(time) field.
task-2335403
closes odoo/odoo#60514
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
|
|
Before this commit, user could not selecta a date before year 1900.
This was an historical limitation due to python < 3.2 that didn't
support dates before 1900.
After this commit, user can select any date, user can select any
date from 01/01/0001.
taskID: 2166761
Fixes #41788
Closes #43055
closes odoo/odoo#51406
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
*: web
Part of https://github.com/odoo/odoo/pull/49142
task-2229551
Co-authored-by: qsm-odoo <qsm@odoo.com>
|
|
*: web_editor
General website option + page option
Part of https://github.com/odoo/odoo/pull/49142
task-2229551
Co-authored-by: qsm-odoo <qsm@odoo.com>
|
|
visibility_group was used for visibility, we now use the groups_id field.
groups_id is a M2M field while visibility_group was a M2O field resulting
in an issue to display the M2M field in the frontend. We decided to
allow editing the groups as a M2O in the frontend. If there is more
than one group the user will have to go through the backend to edit.
task-2264580
closes odoo/odoo#51846
Related: odoo/upgrade#1260
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
Website has a behavior that will ask you which menu you want to edit if you
click on 'Edit Menu' in the topbar and there is more than one menu in the DOM.
This is typically the case for the event pages where the event has its own menu
on top of the website one.
This event menu was not triggering that behavior since 5b563549fa6 where is
was accidentally broken.
closes odoo/odoo#48459
X-original-commit: 5c3c91e4a8da7b7b9f5e05f9c0ec5a6dea782d87
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
|
|
This commit:
- make handle_visibility a private function (even if not
exploitable in rpc easily since it uses request.website)
- encrypt the password in db (even if not critic, since this
password could be shared on twitter, ... it doesn't cost anything
to secure it a bit more)
- remove useless sudo, since handle_visibility does a sudo itself.
In the future, this notion of visibility should be handled on controller layer,
and no more on the View layer (during rendering)
closes odoo/odoo#48145
X-original-commit: 06e0e48217f25f17dff23331111f5dcb98e8cecd
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
in this commit, throw the wizard to enter the new page name, while duplicating
page button and new duplicate page button added in the page properties dialog.
updated the test case related to duplicate page along with duplicate menu
consideration.
task-2088546
closes #40085
Co-authored-by: jpr-odoo <jpr@openerp.com>
|
|
This reverts commit ff1c35513aecef5fbc30f7c2f3834450e719714e.
closes odoo/odoo#41480
X-original-commit: 116057b26e71db4692280463669f3e80d813ddcc
Related: odoo/enterprise#7110
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
You can use has_group(employee) instead
+ fix enumerate_page: when you search a page with visibility constraints,
you never seen it even if force was set to True.
task-2091365 again
closes odoo/odoo#41483
X-original-commit: f1c7a34f0b8276895c18ca6c450a142f9a815e3b
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
FontAwesome 5 introduced new names for some icons as described on
https://fontawesome.com/how-to-use/on-the-web/setup/upgrading-from-version-4#name-changes
This commit replaces the old names to the new ones.
closes odoo/odoo#35826
Taskid: 2050241
Related: odoo/enterprise#5180
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
In 4d5c3b9fc1c5 the arguments of the MenuEntryDialog widget were
altered, and one instantiation of this widget was not adapted, resulting
in the last parameter being undefined and causing a crash. This commit
adapts that call.
closes odoo/odoo#40187
X-original-commit: ab7f501ff401cc1a85a95dd3cc65d80ecfeec2cc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
Adapt website for 13.0 9996d04fd2 change of LinkDialog constructor
arguments (to get back to same arguments as in 12.0).
opw-2086444
closes #39888
closes odoo/odoo#39910
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
Before this commit, if you had a page_id set on a menu, and that you
fork this page, the page_id from the menu was always pointing to the
previous one, so you see old page, but edit new page.
> Reproduce:
> Fork Contactus (Page_id on menu become wrong)
> Refresh contact us (done on save btw)
> You see old content
> Edit with Html Editor, you sill see that forked view exists!
Bug was hidden before that we set page_id on menu, but it is needed if
we want to support the groups visibility on the menu item.
closes odoo/odoo#39472
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
Now, you can define a Visibility mode between:
Public (All poeple)
Connected (Portal or Employee)
Restricted Group (Has this group or is Employee)
With Password (Know password or is Employee)
Internal Users (Is Employee)
It is a 'fair' feature, but without really warranty that the content is
really unreadable via others methods, ...
It is more for frontend display, that real secret. Dont use this like
a keychain ;)
We only catch the visibility on the main view and not the t-call inside.
Even if it should work on controller too, it is only display now on the
page property menu. (Or on the view directly in backend)
task-2091365
|
|
After this commit, you will be able (in technical mode) to update the url for
the python controllers.
Eg.
You can now rename /shop in /garden and /shop/product/ in /garden/vegetable/
Most of urls will be replaced at fly in the renderd qweb, with the function
url_for but all old urls will keep available. So if you access url /shop you
will be automatically redirected to /garden (308 Permanent Redirect).
As for cdn and other post-process of att, the automatically replacement in the
rendered qweb is only done when you will be not website editor. But the new
dispatch of URL will be applied in all cases.
For developper, since it is Permanent Redirect, don't forget to clear cache or
open chrome debug tool (with option 'Disable cache while DevTools is Open) to
see your lasts changes.
closes odoo/odoo#36555
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
If the menu's parent is a newly created menu it will have a temp string
id which was failing to be parsed as an int and thus falling back on the
root menu as its parent.
This was broken by the new mega menu feature introduced with
https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
task-2069365
closes odoo/odoo#36606
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Allow users to create complex website menus, also known as "mega menus".
Mega menus are enabled individually via the edit menu dialog, then their
content can be customized by dragging snippets in them like any other
snippets area in edit mode.
task-1925319
closes odoo/odoo#36097
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Andrea Ulliana <aul@odoo.com>
|
|
Since saas-12.5, with recent ORM changes, writing on non-existing fields
does not trigger a warning anymore but instead crashes. This revealed
that the 12.0 "Edit Menu" dialog was doing some of that. Indeed,
depending on what was edited, we ended up writing on the 'is_homepage'
field, the 'text' field, the 'isNewWindow' field, ... which do not
exist.
This commit takes advantage of the fix to also lint the dialog code and
convert some of it to ES6.
Discovered while working on task-1925319
closes odoo/odoo#36204
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
- End of list in image library
- Title add menu item
- Warning message in html/css/js editor
- Wording building block sections
Part of https://github.com/odoo/odoo/pull/30986
task-1939869
|
|
Since the switch to jQuery 3, Odoo uses native promises in its JS. Some
mistakes were made in the website app during conversion from old jQuery
deferred to native promises.
- `this` -> `self` when wrapping in a promise
- `.always(fct)` -> `.then(fct).guardedCatch(fct)`
- a function returned sometimes a jQuery deferred, sometimes a native
promise. This made the caller fail when using `always` or fail
when using `guardedCatch`
closes odoo/odoo#31887
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
* im_livechat, survey, website_forum
When website is installed, the JavaScript code has access to utilities
to define improved widgets which are automatically attached to existing
DOM elements on page load. Those mechanics are more and more needed in
portal which does not depend on website (as it is website which depends
on portal). This commit moves part of website JS to web, so that it can
be used by all 'frontend' apps whose only common dependency is web
(portal, survey, auth_signup, ...).
This PR also questioned several other similar issues which will be
handled later like:
- website should maybe not depends on portal but only on http_routing
- part of portal should be moved to http_routing and http_routing
should be renamed (especially for frontend layouts, etc) so that apps
like survey can reuse some common code
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
Issue: wysiwyg asset slow down the loading of the website, error
inadvertently introduced: https://github.com/odoo/odoo/pull/29775
The assets are now loaded assynchroneously, when the editor is needed,
its assets will be loaded.
closes odoo/odoo#30700
|
|
* website_forum, website_gengo, website_mail_channel, website_sale
Retrieving the global context is now the root's job, this will prevent
problems when trying to extend the values the context has.
See upcoming improvements with https://github.com/odoo/odoo/pull/29442
closes odoo/odoo#30816
|
|
* website_forum, website_gengo, website_mail_channel, website_sale
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the web_editor.context module was moved to website without being
renamed. This commit renames it to website.context but also merge the
website extension that was made to that context directly within its
definition.
closes odoo/odoo#30409
|
|
* web_editor
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the website edit menu was not opening anymore.
- Fix JS bug at initialization
- Adapt JS code to target correct file which was renamed
- Restore 4-months-old commit https://github.com/odoo/odoo/commit/f1ccc4978b140b2ffb888ef628b27a691dc023a0
- Adapt JS to get the menu label field using the new editor JS
closes odoo/odoo#30353
|
|
* Creating a new structure by transforming all the plugins in the
library using the odoo inheritance system. Plugins are easier to
implement with the AbstractPlugin to add Odoo behaviors.
* From now on, the methods of the library (in this case Summernote) can
no longer be called by other modules or files. Only the wysiwyg
widgets can access it, to simplify the updating process. The wysiwyg
object serves as an interface.
* Depending on the options the snippets will be loaded or not, the
editor will be in an iframe or not... all of this is transparent from
the outside.
* Regarding iframes, all controllers related to editing have been
removed: the new API no longer needs them. This speeds up loading,
eases testing and removes complexity for the same
features.
PUBLIC FEATURES
There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
element (option available to select all, start or end)
A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
element
* focusInEnd: makes a focus and places the cursor at the end of the
element
* selectContent: makes a focus and selects the content
HTML FIELD
The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
cssEdit)
* wrapper: {template} qweb static template (containing a tag:
id = "wrapper") that will include the content during editing (removed
on save)
MASS MAILING
A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.
Co-authored-by: Antoine Guenet <age@odoo.com>
|
|
* web_editor, website_blog, website_crm_partner_assign, website_links,
website_livechat, website_mail_channel, website_mass_mailing,
website_slides
Calling a model's method thanks to an RPC will now always send the
web_editor context automatically, making sure the method gets the
website_id all the time, removing the need to guess the current website
(now the get_current_website method uses the context website_id if any).
Note: other routes already have the website_id via request.env.context
if they correctly set website=True (this commit also adds website=True
for scss files customization routes).
|
|
Advanced user can do it from the backend by the way and it is not
obvious to understand the impact to set/unset this option.
Seems like I was the only guy to think that this feature was needed
task-1878245
|
|
This was always supposed to be full-width but this was buggy since
before 11.0.
task-1878245
|
|
sale_report, ...
Fix bug from the initial poc of JOV
Fix menu creation
- creating a menu would create a 'container' menu in the DB (.create is call without website_id)
then writing on it would copy (if condition to cow) the menu with a website_id leaving the first
one as a menu container unused.
- website_menu should always have a website_id
we dont want to support the multiwebsite system that allow to have generic/specific menu
unlink/write is useless now since we always have a website_id
Make unique_path website dependent, 2 distinct website can have a page with same name
Make Sale report multiwebsite compliant
Make website_id on sale_order / account.invoice as a related stored from partner_id.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
|
|
Now we can see which specific page override wich page when page are sorted by url.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
|
|
This commit should not change the behaviour in most cases.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
|
|
This implements support to administer multiple websites. Although the
core functionality already existed, managing multiple websites was
fairly technical.
In the interest of database updates and migration this attempts to
keep duplicated data to a minimum. To do this the usual generic
records are rendered unless some website-specific record exists that
replaces it. Copy-on-write (COW) is used to create these
website-specific records. Through this mechanism creating a
website-specific record is delayed until necessary. A COW mechanism
has been implemented on 4 models: ir.ui.view, website.page,
website.menu and ir.attachment. These COW mechanisms are activated
when editing data through the website (aka frontend). These frontend
edits (e.g. with web_editor) will be website-specific, possibly
creating a website-specific record when necessary. When editing data
in the backend nothing special will happen, even when editing a
generic record. Note that because of this mechanism also facilitates
the ability to create new, uncustomized websites because the generic
data is kept.
Support is provided for a website to have any theme. Themes are fairly
complex to handle. Standalone themes can depend on other standalone
themes (e.g. theme_beauty depends on theme_loftspace) and themes
usually modify some data of the themes they depend on. Because a theme
can be installed on multiple websites, using website_id m2o fields
does not work well. It would require duplicate data, making updates
and migration harder. Because of this, data for themes (ir.ui.view and
ir.attachment specifically) have a theme_id m2o. website has a
theme_ids m2m that identifies all theme modules currently installed on
it. Through these fields we figure out what to render. A theme is only
fully uninstalled when it's no longer active on any website. The
advantage of this approach is that upgrading or migrating theme data
is no different from the single-website case.
The website.published.mixin class was modified to handle multiple
websites. A wizard was added in the backend to easily manage this for
multiple website.
Although not used anywhere in this commit, a 'website_id' variable has
been added in the evaluation context of ir.rule. It allows to easily
make any model multi-website aware, all that's needed is a custom
website_id m2o field on a model and a custom record rule.
|
|
* web_editor, portal
This commit introduces the first page options: header overlay and color.
The website builder is improved to allow the management of those. With
this commit, users can now click on the website header to make it go on
top of the first snippet, with a chosen transparent color. This is a
configuration that can be done on each page individually (as the feature
is very dependent of the first snippet on the page, this is typically an
option for homepages).
task-32155
|
|
|
|
The 'form-horizontal' class have been removed; the '.form-group'
elements must now use the 'row' class for an horizontal layout.
The 'control-label' class was renamed to 'col-form-label'.
The 'help-block' class was renamed to 'form-text'.
The 'has-error' and 'has-success' classes have been removed and
replaced by a new system using the :valid and :invalid pseudo-classes,
when a parent has the 'was-validated' class. While this system is great,
it is not straightforward to use it in Odoo. Fortunately, BS4 provides
the 'is-valid' and 'is-invalid' classes as fallback. This commit
replaces the 'has-error' and 'has-success' classes by 'o_has_error' and
'o_has_success' classes (for JS compatibility) and use the 'is-*'
fallback classes. (The 'has-warning' class has no equivalent but was
unused in Odoo anyway).
|
|
col-lg-* -> col-xl-*
col-md-* -> col-lg-*
col-sm-* -> col-md-*
col-xs-* -> col-*
col-lg-offset-* -> offset-xl-*
col-md-offset-* -> offset-lg-*
col-sm-offset-* -> offset-md-*
col-xs-offset-* -> offset-*
col-lg-pull-* -> order-xl-1
col-md-pull-* -> order-lg-1
col-sm-pull-* -> order-md-1
col-xs-pull-* -> order-1
col-lg-push-* -> order-xl-2
col-md-push-* -> order-lg-2
col-sm-push-* -> order-md-2
col-xs-push-* -> order-2
|
|
The system completely changed. I also had to adapt classes to new
screen breakpoints.
hidden/hide -> d-none
show -> d-block
hidden-xs -> d-none d-md-(block/inline/...)
hidden-sm -> d-md-none d-lg-(block/inline/...)
hidden-md -> d-lg-none d-xl-(block/inline/...)
hidden-lg -> d-xl-none
visible-xs-* -> d-* d-md-none
visible-sm-* -> d-none d-md-* d-lg-none
visible-md-* -> d-none d-lg-* d-xl-none
visible-lg-* -> d-none d-xl-*
hidden-print -> d-print-none
visible-print-* -> d-none d-print-*
...
and all possible combination of those had to be handled too.
|
|
|
|
|
|
* web_editor
Note: the <body/> element had to be explicitely 'position: relative;'
for the library to work.
|
|
With this commit, it is now possible to delete a page directly from it's page
properties dialog.
Before this commit, you had to go into the page manager and then find your page
that could take some time.
task-1850578
Closes #24861
|
|
This commit:
1. removed the possibility to create page from the menu manager.
The usability of this feature wasn't great since create menu as a new page
would redirect to that newly created page without saving the menu manager
state.
Plus, there is already the 'NEW' button on the navbar to create a new page,
the menu manager should, as its name hint, only manage menus.
2. Handle a new case (officially at least) of menu: menu container.
Those menu are simply menus with '#' as URL. It will be usefull to create a
menu as a dropdown list container.
Note: We should take care of a menu's URL being updated to '#' to avoid the
menu's page URL to be also edited to '#'.
opw-1825883 & opw-1824263
|
|
|
|
Before this commit:
1. The date would be displayed as UTC regardless of the user timezone.
2. The date would be sent to the backend in the browser timezone
Now we correctly take the user timezone into consideration when handling date.
Step to reproduce:
- Install a second language where time format is: %H.%M.%S or %H,%M,%S
(eg: Finnish, Bulgarian, Albanian )
- Set it as website default's language
- Open page properties dialog on any page
- The date looks correctly displayed but it is in fact the UTC hour and not
the user timezone date. (eg: 2 hours missing in Albanian case, it would
show '2018-Pri-05 02.11.02.' instead of '2018-Pri-05 04.11.02.')
- If you save, it will crash since it will send the wrong date format to the
backend that is expecting 'YYYY-MM-DD HH:MM:SS' format.
Closes #23500, closes #23566
|
|
|
|
Before this commit:
When editing a page URL through page properties it would redirect to that new
url afterward. If the url was not starting with '/' and had multiple level
before and after edition (eg: page/action to page/realaction) it would then
redirect to a wrong relative URL.
Now, we ensure that we redirect to the correct URL: the one slugified and
cleaned in the backend.
Step to reproduce:
- Create a page '/page/action'
- Go to that page and open Page Properties
- Edit the URL to 'page/someaction'
- You will be redirected to the incorrect relative URL /page/page/someaction
|
