Re: Contents Tab

Hi Everyone.

I have some news that may be pertinent to this discussion.

First some background:
I have been working on the vsaRace product.  This started out 
as a verbatim copy of Archexample with a new content type: 
vsaRace: RaceArticle.  I got the new type to show up in the 
add new item dropdown and was eventuallly able to 
install/create an instance of a RaceArticle in a folder.
   Then I started working on controlling the behaviour of the 
global_contentviews macro.  This I believe is the subject of 
the current thread.  I wanted to control the appearance of the 
tabs strictly from the definition of the RaceArticle.py module 
and its attendant install.py in the its Extensions sub-folder 
and not modify the macros or skins in any way. I found that 
there was some conflict between the Archetypes code 
(ArchetypeTool.py) and the regular Plone Types (TypesTool.py) 
code.  Well it was more like competition rather than conflict. 
 
Actions are defined by the Plone machinery for all content 
objects and the Archetypes content types are no exception. 
Some of the default actions are: Contents, View, Edit, 
Properties, and References.  However, the archetypes-based 
content types can have the default actions over-ridden and can 
have new actions defined by declaring these settings in the 
class module for the object. A problem arose because I could 
not seem to get the Install function to set these overrides. 
 I think this is because there is some default behaviour 
coming from the regular Plone Machinery which takes place 
after the Archetype install has finished. In any case any 
changes I made to the class definition required a zope restart 
in order to get the changes to become effective.

My solution was to define my new actions and default 
over-rides in an ini file on the file system.  This ini file 
takes the place of the equivalent definitions in the object's 
class module.


There are several advantages to this approach:
1. The over-rides and new actions become effective upon an 
install or reinstall action in the portal_quickinstaller 
rather than at zope boot/reboot. This means that changes can 
be made on-the-fly by adjusting a text file on the filesystem 
followed by a reinstall in the portal_quickinstaller. 
2. The beauty of this approach is that the changes are 
accepted 100% of the time.  A change to this file is effective 
immediately. An anonymous user merely has to reload his page 
to see the new settings.
3. The entire action set for an object class can be determined 
from an ascii file so that it can become a config file for a 
site startup script.

It should be noted that Actions for a particular context and 
location are determined by the listFilteredActionsFor() 
function in the CMFCore.ActionsTool Class.
Another possibly relevant fact to be noted is that types and 
actions do not reside in the zodb.  Rather they are generated 
at start up and when new Products are installed and are stored 
in the portal_types and portal_Actions objects in tuples of 
TypeInformation objects and ActionInformation Objects..

Please note that this issue is at an object configuration 
level and so is not intended to be a solution to the 
permission and context resolution issue which this thread 
seems to be addressing.

Best Regards
Medur

On Wed, 28 Apr 2004 18:13:42 +0200
  <VasudevaService-K9y3B4ipJAZZAIG4hdpdiNBPR1lH4CV8@public.gmane.org> (Dhyani) wrote:
>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>.
>Vasudeva Service home: http://www.vasudevaservice.com/
>Browse list: 
>nntp://news.gmane.org/gmane.org.misc.vasudeva-server.web
>List archive: 
>https://pop.vasudevaserver.org:13031/Lists/VasudevaService/List.html
>--------------------------------------------------------------------------


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