Ticket #12024 (closed PLIP: wontfix)

Opened 5 years ago

Last modified 4 years ago

Non-inherited portlet assignment context

Reported by: mborch Owned by: mborch
Priority: minor Milestone: 4.3
Component: User Experience and Interface Version: 4.1
Keywords: Cc:

Description (last modified by mborch) (diff)

Proposer: Malthe Borch
Seconder: Ross Patterson

Motivation

PLIP  #9286 adds an option to hide one or more inherited portlets.

This is a proposal to allow making that choice from the other side: allow the assignment of portlets which are never inherited down.

The use case is that portlets are often only relevant for a particular view. The common trick to create these locally assigned portlets is to create a content object, set its as the default view on a folder and hand-craft a URL to manage the contextual portlets. This proposal makes it possible to have that same behavior on a folder.

Assumptions

This proposal targets the assignment context as a unit; it will not be possible to set a no-inherit flag per portlet. That might have been the best solution, but it's technically much more challenging.

Proposal & Implementation

For a portlet assignment context (/@@manage-portlets), add an option "Local assignment only" to mean that portlets added here will never be inherited down.

A setting needs to be added to ILocalPortletAssignmentManager and the setting taken into account in the portlet retriever logic.

On the user interface side, a checkbox needs to be displayed to give the user the choice. The default setting is False meaning that portlets are inherited down.

Deliverables

  • Implementation
  • Localization
  • Documentation

Risks

If a folder has this setting and there's subsequently a default page set for it, then the setting will be confusing because any portlets set on the folder won't show up for the default page.

However, there will be a note on the portlets management screen that mentions this.

Participants

Malthe Borch (mborch)

Progress

This functionality has been implemented and is ready for merge.

 https://github.com/plone/plone.portlets/tree/plip12024-local-assignment-only  https://github.com/plone/plone.app.portlets/tree/plip12024-local-assignment-only

Note that the portlets management code does not have unit tests. I have not included unit tests as part of the deliverables for this reason.

Change History

comment:1 Changed 5 years ago by eleddy

  • Milestone set to 4.3

comment:2 Changed 5 years ago by eleddy

Just a small detail - you need a seconder on this plip for it to be considered. This makes sure that someone can take over following this through in case you get sidetracked or something happens. Should be pretty easy to find.

Thanks!

comment:3 Changed 5 years ago by rossp

The FWT has wrapped up work on 4.2 and can start work on 4.3 whenever we have PLIPs to review. So can you as proposers or implementers please check in on your PLIPs and let us know what the status is and when we can expect issues to be addressed and implementations complete so we can review them for merge in 4.3.

comment:4 Changed 5 years ago by mborch

  • Description modified (diff)

comment:5 follow-up: ↓ 7 Changed 5 years ago by ldr

We discussed this at today's FWT meeting. Our main concern is the case of a folder with a default page - presumably a non-inheritable portlet set on the folder will not be inherited by its default page. This is likely to be very confusing for users.

comment:6 Changed 5 years ago by mborch

  • Status changed from new to closed
  • Resolution set to please review
  • Description modified (diff)

comment:7 in reply to: ↑ 5 Changed 5 years ago by mborch

Replying to ldr:

We discussed this at today's FWT meeting. Our main concern is the case of a folder with a default page - presumably a non-inheritable portlet set on the folder will not be inherited by its default page. This is likely to be very confusing for users.

See risks section (updated).

comment:8 Changed 4 years ago by alecm

Would it be possible to have non-inherited portlets appear on folder default pages? This would help avoid the sense that there are two different ways to set a non-inheriting portlet on a folder depending on what the default view of the folder is. It would be nice if such a portlet stayed in place when the folder default view is changed from a template to a content item.

comment:9 Changed 4 years ago by rossp

  • Status changed from closed to confirmed
  • Version set to 4.1

I went to review this today but I see no PLIP cfg in coredev against which to run tests. Will review when I have one.

comment:10 Changed 4 years ago by eleddy

  • Status changed from confirmed to closed
  • Resolution changed from please review to wontfix

Since we haven't heard anything on this plip in 7 months we are closing it. please reopen if interest still exists.

Note: See TracTickets for help on using tickets.