Re: Contents Tab

My notes also below.

> Notes below.
>
>   (Dhyani) wrote:
>
> > Hi Jagrata / Priyadarshan,
> >
> > it's quite complicated. First, let's look at displayContentsTab. It
can't
> > really be customized, whatever I do, the "real" displayContentsTab is
being
> > called, not my customization. Whatever the reason for that may be.
> > Now, when you look at the code, they say in their comment that one of
the
> > three Permissions Copy or Move, or Modify portal content, or Add portal
> > content has to be set, or at least on the parent level. But the code
itself
> > does something else: It demands that ALL of the following three
Permissions
> > are set: 'Copy or Move', 'List folder contents', 'Modify portal
content'. On
> > the parent level, only two of them would be required.
>
> ok. recap.
>
> 1. If the object has those three props, we show the tab.

Or maybe we should say: if the user has those three permissions on the level
of the current folder.

> 2. If the object fails to have those three props, show the
>     tab if and only if (a) we are authorized to query
>     parent perms AND (b) the parent has both
>     'Modify portal content' and 'Copy or Move'.

Exactly. I'm wondering, by the way, if the "List folder contents" permission
might actually be a mistake, and the "Add Portal content" permissions should
take its place.

> > 'Modify portal content' in our case is State-dependent, which means that
if
> > the State=Published, we do not have this Permission, with the result
that we
> > don't get a Contents Tab. If I change this setting in the workflow, then
the
> > editor can edit published content, something we decided not to allow.
>
> Given our workflow, let's identify the logic
> we want and change displayContentsTab.

Exactly! That's what I would have done next, but a nap got into my way.

> > Why did we see the Contents Tab previously? I'm not quite sure, since
there
> > are so many things involved. But I guess that we had some private stuff
in
> > the folder - or even on the parent folder level - and thus got a
different
> > set of Permissions from the workflow.
>
> Yes, and for that matter, why have we seen different behaviors
> on Windows and Linux?

I'm not 100% sure that we saw different behaviors on Windows and Linux. I
have to confess that now, on my local machine - using the exported
srichinmoyraces.org - I'm not seeing the Contents tab anymore. All right, I
saw it this night. Then when I started messing around with Security
settings, looking also at what happens at the Root level, I lost it and
never really got it back (until I got serious about it and found out the
stuff reported above). So the question remains, why did I see it in the
beginning? Well, it might be that the Security settings on the Zope Root
level come into play here. As I said, settings for the Anonymous user can
change the behavior for Editors or Members etc. - not what you would expect!
So there might have been a side effect from the settings on my Zope Root,
which may vary from the settings on Zopestage Root.

> I have changed (in place) 'AND' above to 'or' on the stage.
> You can confirm that the contents tab does show
> for editor_usa in places where it didn't before.
> I am not saying this is the right config, but at
> least the change is showing up on the stage.

Zopestage is currently not accessible. Can you please make it clearer to me,
what you mean by 'I have changed in place' - do you mean you changed the CMF
code on the filesystem? Or have you just customized it? (The latter approach
did not work on my machine!!)

Greetings
Dhyani


--------------------------------------------------------------------------
This message is sent to you because you are subscribed to the mailing list <VasudevaService-K9y3B4ipJAZZAIG4hdpdiNBPR1lH4CV8@public.gmane.org>.