-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 22 Sep 2004 12:40 am, Chris McDonough wrote:
Would you be able to write a short test case that demonstrates the
failure mode that you're seeing in your existing code? It would be nice
to understand the failure before blindly reenabling the
Alright, well, in the meantime, I think we're going to release the beta
with the aq_acquire DWIM removed and if it causes other folks problems
we'll be able to tell from folks using the beta
On Wed, 2004-09-22 at 06:22, Richard Jones wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 22 Sep 2004 11:14 pm, Chris McDonough wrote:
Alright, well, in the meantime, I think we're going to release the beta
with the aq_acquire DWIM removed and if it causes other folks problems
we'll be able to tell from folks using the beta
Tres is in Austria at the Plone conference. Don't expect any quick
turnaround...
jens
On Sep 21, 2004, at 3:04, Richard Jones wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/09/2004, at 1:00 PM, Chris McDonough wrote:
I'd just stick the code back in there for now and we'll see what
Richard Jones wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/09/2004, at 1:00 PM, Chris McDonough wrote:
I'd just stick the code back in there for now and we'll see what Tres
says.
No word from Tres, 2.7 branch release coming up...
Tres has been on the road for ten days, with no
Richard,
Would you be able to write a short test case that demonstrates the
failure mode that you're seeing in your existing code? It would be nice
to understand the failure before blindly reenabling the old behavior
because it really is DWIM.
Thanks!
- C
On Tue, 2004-09-14 at 21:18, Richard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/09/2004, at 1:00 PM, Chris McDonough wrote:
I'd just stick the code back in there for now and we'll see what Tres
says.
No word from Tres, 2.7 branch release coming up...
Richard
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[might dupe - sent the first copy of this from the wrong address, sorry!]
I've just upgraded to use the bleeding-edge 2-7 branch (from 2.7.2, running in
py 2.3.3) and I've started getting permission problems with attributes. The
cause appears to be
On Tue, 2004-09-14 at 21:18, Richard Jones wrote:
On the proposals object though, we don't have any delaration for the
secure_url attribute. If I add one, or a general
security.setDefaultAccess(allow), then the error goes away. This doesn't
seem correct to me.
It sure doesn't sound right.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 15 Sep 2004 12:15 pm, Chris McDonough wrote:
On Tue, 2004-09-14 at 21:18, Richard Jones wrote:
On the proposals object though, we don't have any delaration for the
secure_url attribute. If I add one, or a general
Yep, that's the situation. It appears to look for the security assertions for
secure_url on A instead of B. Note that secure_url is an attribute of B.
Yup. IOW, it looks like it used to find the first secure_url it could
access and return that, even if there were other acquirable secure_url
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 15 Sep 2004 12:36 pm, Chris McDonough wrote:
Yep, that's the situation. It appears to look for the security assertions
for secure_url on A instead of B. Note that secure_url is an
attribute of B.
Yup. IOW, it looks like it used to
On Tue, 2004-09-14 at 22:49, Richard Jones wrote:
Yup. IOW, it looks like it used to find the first secure_url it could
access and return that, even if there were other acquirable secure_url
attrs before that one in the acquisition path. I'm sure the fact that
it ignores any intermediate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 15 Sep 2004 01:00 pm, Chris McDonough wrote:
I'd just stick the code back in there for now and we'll see what Tres
says.
This is what I've done to speed up my testing, rather than fixing all the
places stuff is broken. I'll be testing for
14 matches
Mail list logo
