Hiding a Portlet in a Filesystem Package

[Martin Aspeli]

Hi Derek,

>>> Hey. I'm writing a package to provide a Plone 3.0-compatible UI for 
>>> PAS4CAS - a replacement for PloneCASLogin, which has not been updated. 
>>> The basics work. I now want to hide the login portlet, since it is 
>>> non-functional and confusing with CAS.
>> Really? Why? If CAS (what is it?) means you're always logged in, then 
>> the portlet shouldn't show up anyway (it only shows up for anonymous); 
>> if CAS requires some kind of explicit log in/log out, then you could 
>> customise/override/supplement the login portlet with that action.
> 
> Ah. CAS is a strange beast. It's actually a separate website that people go to 
> to authenticate. After they auth, it redirects them back to the originating 
> website with a ticket that the originating website can verify their identity 
> with. But at no point does the originating website see their password.
> 
> So, the original PloneCASLogin replaced the Login portlet with a new portlet 
> that just had a button to log in. But this takes up a bunch of screen real 
> estate for something that is done equally well by the 'login' link on the 
> personal bar. So, I figure, it'll be an improvement to just remove the portlet 
> altogether.

If you're working on a generic plug-in, then I don't think that's the 
right approach. Whether or not people want that screen real-estate 
really should be up to them. Maybe you don't need to make a new portlet 
with a big button (though you could), but messing with people's portlets 
on install seems a bad idea. The way PAS works, CAS may not be the only 
authentication service that's set up, so people may still want the 
portlet. That kind of policy really should be up to the site.

>> Being able to remove portlets in the GS handler would be nice (and the 
>> GS handler needs more work, as we've talked about before). However, this 
>> is a bit extreme - it won't be possible to add a new login portlet 
>> anymore once the portlet has been uninstalled like this; 
> 
> Right, that's what I want. Though, if they uninstall my package, then I'd want 
> to restore the ability to add login portlets. /me makes mental note.

And what if I'm using CAS for some users and regular log-in for other 
uses? PAS makes that perfectly possible, but if you nuke the login 
portlet that's going to get annoying. :)

>  > also, I'm not
>> sure if this would actually remove existing instances of the login portlet.
> 
> Aha, I will have to figure out how to do this.

You can't predict where and how people may've assigned portlets. You can 
look at the root of the site and remove it from its default location, 
but that's about it.

>> I'd say that this is not really something that belongs in a package that 
>> contains a PAS plug-in, by the way. The PAS plug-in ought to be generic 
>> enough not to have dependencies on Plone specifics such as the portlets 
>> implementation. Perhaps a higher level package that had the PAS4CAS 
>> package as a dependecy could contain this instead?
> 
> Oh, right. I wasn't clear. PAS4CAS by regebro provides the actual PAS plugin 
> with no deps on Plone. My package is merely a Plone 3.0 UI adjustment to use 
> PAS4CAS. So, I think I'm doing exactly what you suggest.

Ah, ok - cool.

>>> Questions:
>>>
>>> 1 - Is there a better way to hide the login portlet from a filesystem 
>>> package than to do it through GenericSetup?
>> You could just remove the assignment from the root of the site?
> 
> So, remove the portlet from being displayed but not remove its definition. Yes, 
> this would work. I still favor the more comprehensive solution, so that admins 
> don't think they can just add a login portlet and bypass the CAS redirect. But 
> perhaps I have too little trust. ;)

/me shrugs

I'm not sure how comfortable I'd be installing a product if I knew it 
was going to remove a core part of Plone (even if uninstalling the 
package puts it back). I think it'd be easier for everyone if this was 
just documented and you left the poor portlet alone. :)

>>> 2 - If I patch the portlet handler, is this likely to be accepted 
>>> back? If so, what is the first plone version in which it is likely to 
>>> be allowed in? I must admit, I'm a little confused by 3.0.x vs 3.1 vs 
>>> 3.5/4.0 and what is allowed in each. ;)
>> If you extend, rather than change the handler, it'd be a good candidate 
>> for 3.1.
> 
> I was thinking this syntax for the XML:
> 
> <portlet removename="Login" />

-1

Now you're overloading the <portlet /> directive to have a secondary, 
different behaviour.

The way we often do this, is with a remove="True" option on the directive.

  <portlet
    addview="portlets.Login
    remove="True"
    />

(here, title and description would be optional/not used, so I've left 
them out). Maybe we need some higher level construct for uninstall though.

> That simple. This directive would remove all the instances of the portlet 
> definition with the given name (specified as 'title' in the addview directive) 
> and remove the ability to add them to the site. 

Eeep! Removing all instances would involve walking the entire site and 
be very slow and possibly dangerous.

We currently have no way of adding a portlet assignment with GS - the 
<portlet /> directive only adds a new *type* of portlet, not a new 
assignment anywhere.

When we get a syntax for adding a specific assignment, it should be 
reciprocal so that you can remove a specific assignment as well, but 
there can be no syntax for removing any instances anywhere.

> If both 'addview' and 
> 'removename' were both present on the same <portlet />, then addview would take 
> priority and the removename wouldn't fire. What do you think?

If you have conflicts like this, it's better to raise an exception. It's 
clearly a programming error by the person who wrote the XML and you 
shouldn't guess what they may've meant.

>> You would need to do this work on a branch, by the way. :)
> 
> It looks like it would only affect portlets.py, be a few lines of code, and 
> would preserve back-compat with the current portlets.xml. Since I *still* have 
> not sent in my paperwork <duck />, can I just submit a patch?

Sure, but you should get commit access - I'm sure you'll be doing more 
of this in the future. :)

Plus, if you have a branch people can actually test and look at, where 
you can continue to work after you receive feedback, that's way better 
than a patch which is either accepted or rejected wholesale.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book