Re: Question about how remoteURL are handled in navigation

On Fri, Jul 11, 2014 at 1:11 AM, Luca Fabbri <[email protected]> wrote:
> Today I found a strange bahavior that can easily understood looking at
> this change:
> https://github.com/plone/Products.CMFPlone/commit/be6b828870387259a731bf13c45150258efc48cb
>
> I'm wondering why this change has been added.
> For what I remember Plone navigation system historically used the
> getRemoteUrl brain data to send users to remote URL, but later we
> changed the way to do it: we sent the user to the Link object and rely
> onto the link_redirect view, that check for user permission.
>
> However it seems that in late 2011 we re-introduced the getRemoteUrl
> usage with some weird logic: if the current user is not the creator:
> display the use the remote URL (even worst: there's no type
> checking... I found that because a custom content types we use is
> implementing the getRemoveUrl method, but it's not a Link).
>
> >From my point of view this was a regression.
>
> Any comment?

I don't know the reasoning behind this specific change, but I can make
a guess based on my own experience.  It is often desirable to treat
external links differently from internal links (for example by styling
them differently or having them open in a new window).  If the Link
url is used, then something that may effectively be an external link
would always be treated as an internal link.

Using duck-typing (checking the existence of getRemoteUrl), rather
than checking the portal type, makes some sense since it allows custom
link types to have the same behavior without having to rewrite listing
views.  In that case, implementing getRemoteUrl on your content type
effectively means you've implemented the Link interface/behavior and
everything that comes along with it (since we can't actually check
interfaces on catalog brains).

Ideally, the listing would direct anyone with edit permissions on the
Link to the Link url.  Since it's not possible to check the permission
without waking the object, checking the creator is a semi-sensible
alternative (it should probably check the edit permission on the
portal root as well, to make sure admins get the same behavior as
creator/owners).  However, it might be better to just always use the
remote url, except in folder_contents and other administrative
listings.

In any case, there are probably quite a few users who viewed prior the
switch from using getRemoteUrl to using the link url in listings to be
a regression, and the switch back to using getRemoteUrl to be a fix.
The current solution is certainly a bit hacky though.

Alec

------------------------------------------------------------------------------