g:link tag does not automatically pickup namespace of current controller

[snimavat]

Steps to Reproduce

Url mapping is:
"/admin/$controller/$action?/$id?(.$format)?"(namespace:"admin")

When g:link tag is used without a controller name, it intelligently findsout the name of current controller and does the proper reverse url mapping.

But when the controller is in a namespace, and no namespace is specified in the g:link tag, it will generate wrong urls and will not consider namespace for reverse url mapping:

So, for the url mapping example given above:

If i do <g:link action="create" class="btn btn-primary btn-xs">create</g:link>
And the current controller is PageController, which is in namespace admin. The generated url will be page/create and not admin/page/create

Expected Behaviour

Just like how link tag automatically figureout the controller name, it should also check if the controller is in a namespace, and automatically apply the proper reverse url mapping if there's a namespaced url mapping.

• Grails Version: 3.0.11

[jameskleeh]

When resolving a URL mapping (forward or reverse) to a namespaced controller, a mapping will only match if the namespace has been provided

The docs specifically state the namespace is required for it to resolve, however I agree this can be improved for the situations when the namespace is available in the request.

[jameskleeh]

Done by #10068. Will be included in the 3.1.10 release.

[snimavat]

Is it included in 3.1.10 ? changlog does not include this ticket https://github.com/grails/grails-core/issues?q=milestone%3Agrails-3.1.10

@Schlogen

[snimavat]

@Schlogen I am not sure whats changed in 3.1.10, but this definitely doesnt work as expected, and would break existing apps.

The issue is, it pickups namespaced url mappings when doing reverse url mapping, even when the target controller is not in namespace.

Example:
I have this url mappings

    final List<String> FORBIDDEN = [
            'plugins',
            'WEB-INF',
            'assets',
            'console',
            'is-tomcat-running',
            "admin"
    ]
       "/admin/$controller/$action?/$id?(.$format)?"(namespace:"admin")
 "$uri**"(controller:"content") {
            action = ['GET': 'show', 'POST':'update']
            constraints {
                uri(validator: { path ->
                    return !FORBIDDEN.any { p -> return path?.startsWith(p) }
                })
            }
        }

when i do g.createLink(controller: 'content', action: "show", params: [uri:url] from a view which is rendered from a namespaced controller (admin namespace). it generates the link http://localhost:8080/admin/content/show?uri=THE_URI (see the admin namespace is applied even if the ContentController is not in admin namespace)

It should have generated the url like http://localhost:8080/THE_URI/

Note: I dont have the default "/$controller/$action" url mapping

Looks like after your change, a namespaced url mapping will be picked up if the namespace is in the request, regardless the target controller of g:link belongs to the namespace or not.

Namespaced reverse url mapping should apply only if the target controller is in namespace and a namespaced url mapping exist for that namespace in urlmappings.groovy

Here's the expectation

Given the Example url mappings

"/admin/$controller/$action?/$id?(.$format)?"(namespace:"admin")
"/secure/$controller/$action?/$id?(.$format)?"(namespace:"secure")
"/$controller/$action?/$id?(.$format)?"(namespace:"secure")

class SettingsController {
 static namespace = "admin"
}

class UserController {
 static namespace = "secure"
}

//controller without namespace
class SimpleController {

}

View: admin/settings/index.gsp contains a link to User controller like this
<g:link controller="user" action="xx">User</g:link>

The generated link should be /secure/user/xx and not /admin/user/xx
<g:link controller="settings" action="xx"> should generate /admin/settings/xx
<g:link controller="simple" action="xx"> should generate /simple/xx

[jameskleeh]

@snimavat So the issue is that it is applying the namespace for links that go to controllers that are not the current controller. Thanks for testing this. I'm working on a fix

[jameskleeh]

@snimavat Can you use 3.1.11.BUILD-SNAPSHOT to verify the issue is resolved for you?

[snimavat]

@Schlogen where can i get the snapshot, i will test...

Is it implemented as i explained ? Like the namespace should be determined based on the controller name specified in the g:link and not just the namespace in request ?

Looking at the changes u made, it looks like, it will automatically apply the namespace only for the current controller.

Just like while doing the url mapping, it can figureout the controller based on the namespace provided in the url mapping pattern.. cant it figureout the namespace of controller (specified in g:link), when doing the reverse url mapping ?

[jameskleeh]

Just change your grails version to 3.1.11.BUILD-SNAPSHOT in your gradle.properties

Reopening this issue doesn't make sense because the improvement was completed, it just introduced a bug.

The namespace, if not specified, can only come from the request. It will not add the namespace for controllers other than the controller in the request.

Determining the namespace for controllers other than the current controller is outside the scope of your initial improvement request, and therefore was not considered. I'm not sure how much work would be involved to do so, or if it even makes sense.

[snimavat]

I think it makes sense to figureout the namespace from a controller when doing reverse url mapping... just like doing forward url mapping, Grails will findout which controller to use based on the name space in url mapping... the same should happen based on reverse url mapping... if controller is in name space, use that name space... if there are two controllers with same name in differnt name space, thn namespace must be provided, if one of the controller is in default namespace, that gets picked up.

Should i create a seperate issue for that ?
It not a deal breaker, but it would make g:link much more generic/intelligent

@Schlogen