#90: Editable border computation should be optimized

When trying to calculate whether to show the green "this document is editable or workflowable", Plone does a lot of expensive checks that can be re-ordered to return the correct True/False value with much cheaper operations than the worst-case scenario.

• Changing the order of operations in showEditableBorder
• Adding a check for Modify Portal Content
• Changing global_define is_editable to only check Modify Portal content
• Remove allowed_types from global_defines (old code (no cases in Plone or associated Products) will have to use here/getAllowedTypes instead

• There is one use case where it will work differently than the old one: If you are an Anonymous User, you will never see the border unless it is explicitly turned on in the template (enable_border).

  This is good for several reasons, the most prevalent one being a UI issue: If you're anonymous, the green border is not where you would normally look for the "add" button. A classic case to illustrate this is an issue tracker, where you would not have the green border show up just to allow Anonymous to add an issue.

  If you want this (let's say you use view tabs to show stuff to anonymous, which is something you shouldn't do, but some old products do it anyway), you can still add one line to that form (enable_border), and it is such an uncommon use case that slowing down Plone to optimize for it makes no sense.

• Old code (no cases in Plone or associated Products) will have to use here/getAllowedTypes instead.

Alec Mitchell
Alexander Limi