On 2007-08-24 07:55:08 +0200, Jodok Batlogg <[EMAIL PROTECTED]> said:
hi christian,
it seems like your recent changes to support skins in xmlrpc views =20
introduced some troubles.
we spent several hours to debug not working xmlrpc views and finally =20
found that nailing the zope.traversing e
hi,
it seems that http://buildbot.zope.org/ seems to be pretty borked.
iirc benji is taking care of the build master and other people are
maintaining the slaves.
in case we don't have enough slave maintainers, lovely systems would
be happy to provide a slave for linux 2.6 and make sure this
hi christian,
it seems like your recent changes to support skins in xmlrpc views
introduced some troubles.
we spent several hours to debug not working xmlrpc views and finally
found that nailing the zope.traversing egg to 3.4.x resolved the
troubles.
while looking at your changes we were
--On 24. August 2007 02:37:01 +0200 Philipp von Weitershausen
<[EMAIL PROTECTED]> wrote:
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-so
ftware.txt
Thanks for writing this excellent "guide". However I am personally unclear
about specifying the dependencies and
We have 100+ packages that make up what used to be distributed as
"Zope3". We have numerous more packages in svn.zope.org. Most of them
are developed, released and distributed individually. We like to think
this is a good thing (I certainly do). But currently we have a bit of a
chaos [2]. It's
Jim Fulton wrote at 2007-8-22 15:57 -0400:
> ...
>I eventually came to the conclusion that our original conclusion was
>sound, but that we should only introduce backward incompatibilities
>when the need is very dire, as it will cause lots of pain.
Very good!
--
Dieter
_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Theune wrote:
> Am Mittwoch, den 22.08.2007, 16:15 -0400 schrieb Tres Seaver:
>>> I eventually came to the conclusion that our original conclusion was
>>> sound, but that we should only introduce backward incompatibilities
>>> when the ne
Hi,
I ended up in overriding the permission storage map. This might not be
so conservative, but seems to work. Kills any not ALLOWED permission
and stops propagation.
ALLOWED = ['zope.View', 'zope.app.dublincore.view', ...]
class trashPermManager(AnnotationPrincipalPermissionManager):
def ge
On Aug 23, 2007, at 1:53 AM, Christian Zagrodnick wrote:
On 2007-08-22 16:12:42 +0200, Jim Fulton <[EMAIL PROTECTED]> said:
On Aug 22, 2007, at 8:16 AM, Christian Zagrodnick wrote:
Hi,
I'm doing things wich z3c.zalchemy and trying to find out why my
database connections are kept open eve
Hi,
On Thu, 2007-08-23 at 08:31 +0200, Adam Groszer wrote:
> Hello Christian,
>
> Thanks, tried that. The problem is when new users "arrive", they get
> ModifyContent permission in the site root. Now I shall add a
> subscriber for the new_user event or denying ModifyContent from
> Authenticated u
Roger Ineichen napisał(a):
Renaming doesn't make sense to me since in every book and
documentation ISite is used. I'm against every beautification
which has no benefit.
IPossibleSite --> ISite makes perfect sense to me.
IPossibleSite --> IComponentSite doesnt make sense to me.
and
IPossibleCom
11 matches
Mail list logo