plone 2.1 showEditableBorder shouldn't make things hard for anonymous-editable content

[simon]

This change: [6266] , explained in  http://plone.org/products/plone/roadmap/90 , unconditionally hides the edit controls from anonymous users. It seems to assume that anonymous-editable content is really rare, requiring a strange workaround in that situation. Surely that's a bad assumption ? I think the plone 2.0 behaviour is correct; if the permissions say so, then the object is editable.

[simon]

Cf  http://zwiki.org/1187ActionTabsNotShownToAnonymousUsersInPlone21 .

[limi]

Alec suggests:

"the edit permission check could be placed before the isAnon check, it will result in a pretty insignificant performance hit, and preserve the 2.0 behavior, plus allow this use case"

also:

"we can check the Add portal content permission check as well, though, we could put all the permission checks before isAnon, the really important thing is that that isAnon check happpens before the actions and types checks. The earlier it happens the better."

We should probably try to get this into 2.1.2. Should be benchmarked too, just to make sure it doesn't add any significant overhead.

[hannosch]

Not enough time to fix it in 2.1.2. Should be dealt with right after 2.1.2 is out :)

[brcwhit]

(In [9788]) fixes #5117. added permission checks for 'Modify portal content', 'Add portal content', 'Review portal content' before check for anonymous to allow for enabling anonymous editing via perms

[aknoerig]

What about the case, where additional content view tabs just provide additional views on the content?

For instance, I have a Product content type and have several tabs to look at an Overview, Features, and Specs of the product. I don't want to grant additional rights to the user here, just to be able to display the tabs.

I think this might also be a frequent use case, and I have so far only found a dirty solution to make it work.

P.S. See also ticket  4882 for a previous discussion.

[hannosch]

As already discussed on the mentioned issue the editable border is semantically meant to highlight the fact that you have the possibility to edit in the current context.

If you define more than one anonymously available view you can either style these differently (for example with a CSS file which is applied based on permissions) or use the provided "top_slot" hook in your view templates to always enable the border. You are of course also free to just customize the script and change it to your needs. That's what customization is for ;)