- Fix import of group roles during workflow import
- Fix circular import handler dependencies bug
- Fix portal_quickinstaller so that persistent data is not lost on reinstall
Also included are a number of perhaps naughty extensions to the CMF content import handler.
- Permissive registrations of the StructureFolderWalkingAdapter so that folders under the profile's "structure" folder with the same name as in the container's .objects file can be used to import any kind of content object, not just folders. This allows, amongst other things, creating topics/collections and criteria on import.
- Set arbitrary AT fields on import using the options under the [FIELDS] section of .properties as field names and the option values as field values. If field.multiValued is True, then the option value will be split on newlines and each value stripped.
- Reindex imported objects so that imported titles, descriptions, and any other AT fields are reflected in the catalog and portal navigation after import.
- Set local roles on import where each option under the [ROLES] section of .properties is the principal/user id and the roles assigned to that principal are taken from the option value split at newlines with each item stripped.
- Do each workflow transition listed under the "transitions" option of the [DEFAULT] section of .properties. The option value is split at newlines with each item stripped.
- Set display layout using the layout option in the [DEFAULT] section of .properties
Also included is GSML which allows implementing GS import handlers as you would implement ZCML directive handlers. Some import handlers are included in collective.gsqi that make use of GSML.
]]>
When creating content from a template, the initial edit form is rendered and validation performed on the template after changing the owner of the template to the current user within a transaction.savepoint() which is rolled back after rendering. As a result, portal_factory is not involved and indexing occurs only on the final copy of the template. This may result in performance gains though this has not been tested.
While designed to be Archetypes agnostic, only an Archetypes implementation is currently provided. Templates may currently be designated using Archetype UIDs for the global templates or references for the context specific templates.
A reserved_id property can also be set on type information objects in portal_types. If set and an object with that ID already exists in the container, then the type is not allowed to be added.
Table of Contents
To use collective.contemplate for the Plone content types, include the collective.contemplate configure.zcml in your instance and install "Content Templates" in the "Add-on Products" control panel, or in the ZMI through portal_setup. This will replace the Plone content type information with template versions.
To install for other content types, register a template add form for the content type and use the TemplateDynamicViewTypeInfo meta_type for the content type information.
In the ZCML for the browser views:
<contemplate:formControllerPage
name="addFoo"
type_name="Foo"
for="zope.app.container.interfaces.IAdding"
permission="foo.AddFoo" />
Note that the "foo.AddFoo" permission must be registered and the name "addFoo" must be the same as your content type constructor. If you're using Archetypes, then the constructor may auto-generated by prefixing "add" to the content class name.
In the GenericSetup profile types.xml file:
<object name="Foo" meta_type="TemplateDynamicViewTypeInfo "/>
In the GenericSetup profile types/Foo.xml file:
<?xml version="1.0"?> <object name="Foo" meta_type="TemplateDynamicViewTypeInfo">
This package is currently incomplete until a UI for designating templates is included. In the mean time, you may set the global templates in the ZMI or context specific templates using the references GenericSetup import handler provided by collective.gsqi.
You can use a given content item as the global template by setting the global_uid property of the content type information under portal_types in the ZMI. Set global_uid to the Archetypes UID of the template.
You can use a content item as the template in the context of a specific folder by setting a reference from the folder to the item with the relationship of "contemplate.${type_info/getId}" where "${type_info/getId}" is the id of the content type.
A reserved id can be set using the reserved_id property of the content type information under portal_types in the ZMI.
The package can be installed using the standard python package installation procedure. Extract the tarball, then run the following command inside the extracted directory:
$ python setup.py install
This will install the command-line utility and the rpatterson-gmail.el emacs library. Then add the following to your ~/.emacs:
(require 'rpatterson-gmail)
Once installed, the filters can be exported to a file simply by calling M-x bbdb-export-gmail-filters. You will be prompted for a file to export the filters to.
For every BBDB record that has a value in the gnus-private field, a filter will be included that matches the "To" GMail filter field on any BBDB net addresses for that record and applies the label specified in the gnus-private field value. The same is done for BBDB records with values in the gnus-public BBDB field but filters on the "From" GMail filter field instead.
I've subsequently posted a survey in hopes of getting a sense of what people are using membrane and remember for and what direction they'd like to see them take. It should only take a few seconds to respond to so please do if you have any interest in membrane or remember at all.
I'm looking forward to working with Rob and to help keep membrane and remember moving forward!
]]>The Zope 2 security framework is very powerful and one of it's greatest strengths. A lot of it's power comes from it's flexibility. Exposing that power to site adminsitrators often ends up giving them enough rope to hang themselves with. This is exactly what the "Security" tab in the ZMI does.
In many cases, a site admin or consultant is faced with the daunting task of restoring all the security settings throughout the Zope object heirarchy in order to bring sanity and predictability back to the site. The collective.securitycleanup package provides GenericSetup handlers for restoring the role mappings and local roles back to their defaults. This handler can be used in combination with existing handlers to set role mappings and to re-apply workflow security settings to help start the process of security cleanup.
The clean up is performed on all ancestors including the Zope application root and by walking down the heirarchy to all descendants. This means all descendents of the context the handler is used on and all ancestors of the context including the root will be cleaned up. It will not clean up siblings or anything else that is not a direct ancestor to the context.
The clean up removes all permission settings stored on the instance which effectively restores them to code defaults. The clean up also removes all local roles except the "Owner" role for the user returned by OFS.interfasces.IOwned.getOwnerTuple() if already assigned.
Use of this tool will likely only ever be a starting point. So be sure to test thoroughly before deploying to your production server and backup your ZODB before using it.
]]>Firstly, since the portal object is not a BTree based folder it will begin to behave poorly if too many objects are added to it. Allowing the redirected paths independent from the location of the Redirect instances allows for many redirects without putting too many objects in the portal root.
Secondly, having the paths independent of the Redirect instance locations allows users to create redirect for paths that they can't add content too. Keep in mind that this might be a bad thing for your site and can certainly be abused as a DOS attack of sorts.
If multiple redirects exist for the same path, the one with the more recent publication date will be preferred. Finally a redirect will never override an otherwise traversable URL. IOW, a redirect cannot override an actual content object, skin object, view, or anything else traversal. The redirect only occurs when a NotFound error would otherwise be raised.
]]>See the PyPI page for more details.
]]>Layer authors often end up reproducing the functionality provided by their test case classes since the same functionality is needed to perform layer set up or tear down. The collective.testcaselayer.ztc, collective.testcaselayer.ctc, and collective.testcaselayer.ptc modules provide layer base classes that mix in the test case functionality from ZopeTestCase, CMFTestCase, and PloneTestCase, respectively. See the collective.testcaselayer.ztc, and collective.testcaselayer.ptc sections below (or ztc.txt and ptc.txt if reading this in the source) for more details. These layer base classes also include the layer base class support from collective.testcaselayer.layer and the sandboxed ZODB layer support from collective.testcaselayer.sandbox described below. Additionally, these modules allow for using the test case fixtures as layers themselves.
While class objects can be used as layers, as opposed to instances of classes, doing so means that it is not possible for a layer to subclass another layer *just* to re-use functionality without also depending on that layer being set up as well. See the collective.testcaselayer.layer section below (or layer.txt if reading this in the source) for more details.
The DemoStorage included with the ZODB provides a way to "nest" ZODB stores such that all writes will go to the DemoStorage while reads will be taken from the base storage if not available from the DemoStorage. The collective.testcaselayer.sandbox module uses this feature to associate a DemoStorage with each sandboxed layer to which set up changes are committed and restore the base storage on tear down. Thus sibling layers that write to the ZODB can be isolated from each other. See the collective.testcaselayer.sandbox section below (or sandbox.txt if reading this in the source) for more details.
See the PyPI page for more details.
]]>To try it out, just see the README on the pypi page. Here's a brief description.
This package provides some scripts that wrap parts of mswatch and
OfflineIMAP and integrate with Gnus to provide a local maildir that
is synchronized with a remote maildir as changes occur, instead of
polling on a regular basis. This provides for near instant delivery
of new mail while also reducing resource utilization. Integration
with the Emacs mail and newsreader, Gnus, is also provided in such a
way that your single threaded Emacs process is blocked much less as
changes occur to the maildirs.
]]>
The ZCA and the ZODB are a good combination where components require persistent state. ZCA factories or handlers typically retrieve any persistent state required from the persistent objects being adapted. If the persistent state required is not specific to the objects being adapted, a common solution is to register a persistent utility which is then looked up in the factory or handler. The persistent utility approach requires, however, that the one appropriate utility is looked up which requires support in the ZCA registrations either in the interface provided or the utility name.
In some cases, however, it is more consistent with the object oriented semantics of Python and the ZCA to think of the factory or handler as an instance method of a persistent object. With this approach the non-context specific persistent state can be accessed on self.
One example where this may be useful is where some non-context persistent state is tightly coupled to some event handlers in such a way where instance methods are better semantics.
The Baz class uses the decorator in the python code. Note that the factory decorator must come before the declaration decorators so that it will be run last and will reflect the declarations.
>>> from z3c.persistentfactory import testing
>>> baz = testing.Baz()
Register the persistent factory wrapped instance method as a handler.
>>> from zope import component
>>> component.provideHandler(factory=baz.factory)
The method adapts IFoo, so create an object providing IFoo to be used as the event.
>>> component.adaptedBy(baz.factory)
(<InterfaceClass z3c.persistentfactory.testing.IFoo>,)>>> from zope import interface
>>> foo = testing.Foo()
>>> interface.alsoProvides(foo, testing.IFoo)
When the event is notified, the method is called with the event as an argument.
>>> import zope.event
>>> zope.event.notify(foo)
Called <bound method Baz.factory of
<z3c.persistentfactory.testing.Baz object at ...>>
args: (<z3c.persistentfactory.testing.Foo object at ...>,)
kwargs: {}
Another example is where an adapter factory needs to look up persistent state specific to the objects being adapted but where that state can't be stored on the adapted objects them selves. The component storing the shared persistent state can register one of it's instance methods as the adapter factory which will look up the necessary persistent state on self.
Register the persistent factory wrapped instance method as an adapter factory.
>>> component.provideAdapter(factory=baz.factory)
The method implements IBar.
>>> tuple(interface.implementedBy(baz.factory))
(<InterfaceClass z3c.persistentfactory.testing.IBar>,)
When the adapter is looked up, the metod is called with the object to be adapted as an argument.
>>> result = component.getAdapter(foo, testing.IBar)
Called <bound method Baz.factory of
<z3c.persistentfactory.testing.Baz object at ...>>
args: (<z3c.persistentfactory.testing.Foo object at ...>,)
kwargs: {}
>>> result
(<bound method Baz.factory of
<z3c.persistentfactory.testing.Baz object at ...>>,
(<z3c.persistentfactory.testing.Foo object at ...>,), {})
]]>
There are a couple improvements I'd like to make to z3c.gibberish given interest and time:
I'd like to improve z3c.gibberish to use a weighted random selection so that more common words are selected more often.
On further thought, it would probably be best to support this by using a dictionary that repeats words to represent frequency. Maybe z3c.gibberish could be extended to take a normal dictionary and a file representing weights and output a weighted dictionary to be used for subsequent runs of z3c.gibberish.
I could also make it more efficient by pre-assembling a list of dictionary indexes for each row and then assembling the row by retrieving the words corresponding to the index in order to avoid repeatedly iterating through the dictionary for each row/cell.
]]>I'd like to complete z3c.recipe.subprocess and port this package to that. It does, however, work just fine now.
]]>