Ticket #4882 (closed Bug: wontfix)

Opened 11 years ago

Last modified 7 years ago

showEditableBorder is too naive

Reported by: raphael Owned by:
Priority: major Milestone: 2.1.2
Component: Templates/CSS Version:
Keywords: Cc:

Description (last modified by limi) (diff)

plone_scripts/showEditableBorder should not always return False for anonymous.

Reason: This makes it impossible (without customizing it) to define _any_ type specific object tabs for anonymous. For more complex content types, this may very well be appropriate. It used to work prior to Plone 2.1 so this change is breaking exsisting behavior :-(

For my use cases it has been sufficient to just comment out the check for anonymous. The subsequent action filtering does what it is expected to do.


PS: I guess this (FMPOV unwanted) change was triggered by the inappropriate name of this script. It should rather be called something like 'showObjectTabs' as from a more general perspective it a priori has nothing to do with editing content (except that some of the default object actions require modification rights).

Change History

comment:1 Changed 11 years ago by Anonymous User


comment:2 Changed 11 years ago by shh

Raphael, this is due to a performance optimization applied for 2.1. In 2.0.5 the conditions where checked basically the other way round, i.e. most expensive first.

Editable border is the right name, btw. Green border means: you can modify this thing. I think the use case of tabs for Anon is a customerization only.

comment:3 Changed 11 years ago by Anonymous User

While I understand the performance issue, it is still unclear then how one is supposed to proceed when using object actions for anonymous. If there is general agreement that this should not be supported it should at least be documented and an alternative should be provided (document actions come to mind).

Further note that there are a number of add-on products (e.g. this collector) that do use object actions for anonymous up to now. They all break (silently) under Plone 2.1 by not offering actions to anonymous users that they used to offer (e.g., this collector provides 'browse', 'view', 'new' and 'followup' actions on an individual issue to anonymous).

If we do consider this a (site) customization issue only, how are add-on developers supposed to fix this then? One solution could be to (further) extend the FTI to include a boolean property whether or not to check for possible object actions depending on type defaulting to false if non-existing and to include a check for this as well in 'showEditableBorder' then checking for anonymous. This check per se shouldn't affect performance significantly.

Finally, considering the green border as indicative that you are allowed to change the object viewed may hold true for Plone OOTB but definitively not in general (as illustrated by plone.org itself).

comment:4 Changed 10 years ago by limi

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

This is intentional behaviour, and you can turn on the editable border explicitly for anon by triggering:

<metal:block fill-slot="top_slot"

tal:define="dummy python:request.set('enable_border',1)" />

comment:5 Changed 7 years ago by hannosch

  • Component changed from Visual and templates to Templates/CSS
Note: See TracTickets for help on using tickets.