Re: Contents Tab

v 0.1.1 has been committed to the Repository

Medur

On Wed, 28 Apr 2004 17:23:09 +0000
  <VasudevaService-K9y3B4ipJAZZAIG4hdpdiNBPR1lH4CV8@public.gmane.org> (Medur) wrote:
>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>.
>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>.