Re: [Zope-dev] cut/paste catalogue aware zclass instances still broken in 2.20?
I had this problem with 2.1.6, but it seems to fix itself with 2.2.0. I think you must be having a different problem. The problem with 2.1.6 was to do with the copying of objects to the clipboard. You were not able to call absolute_url() on an object in the clipboard, and that cause problems when cutting and pasting catalog aware classes since the index in the catalog is done by the absolute url and so when unindexing, absolute_url() is called. However, the clipboard stuff has changed in 2.2.0 and the problem seems to have been fixed as far as I can tell. terry "Dr. Ross Lazarus" wrote: Has anyone else noticed a problem with pasting cut or copied catalogue-aware zclass instances? The collector item #1371 I submitted on June 27 seems still to be present in 2.20 final - sorry, I don't have a patch... It's a function I need and duplicating it without using manage_pasteObject after a manage_cutObject is going to be painful. The manage_cutObject and manage_copyObject functions seem happy enough, but when I do a manage_pasteObject, I get "the object foobar does not support this operation" - no traceback. Zope-2.2.0 source on Redhat linux 6.1 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- Terry Kerr ([EMAIL PROTECTED]) Adroit Internet Solutions Pty Ltd (www.adroit.net) Phone: +613 9563 4461 Fax: +613 9563 3856 Mobile: +61 414 938 124 ICQ: 79303381 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ENHANCED PATCH: Expanded access file
I've further enhanced yesterday's patch with the following additions:
* "Short-circuit evaluation" of local roles in User.getRolesInContext().
This speeds up security evaluation for complex DTML by stopping the local
role search as soon as one of the desired roles is found. The change is
fully backward compatible with any other usage of getRolesInContext()
(although there *arent'* any other usages in the Zope core). (Note: this
change also prevents infinite recursion of local roles lookup when the
local roles are provided by a ZPatterns attribute provider which is owned
by a user who has the necessary roles to compute local roles.)
* Encapsulation fix. The current version of Zope directly accesses
__ac_local_roles__ when checking access rights, which negates any ability
for Zope objects to provide rule-based local roles without computing all
possible roles for all possible users.
* Added "get_local_roles_for_user()" method to
AccessControl.Role.RoleManager that works with a user object, rather than a
user name. This is to allow objects to supply computed local roles using
attributes of the user as part of their decision process. An object need
only implement get_local_roles_for_user(user,roles) to carry this out.
These additions, in conjunction with the ability to add more users to the
"access" file, will allow ZPatterns and LoginManager to do without
'unownedness' and other convoluted alterations of the Zope security model.
They will also make it possible to add local role plugins to ZPatterns.
This is somewhat more tested than yesterday's variant of the patch,
although I have not found any bugs in what I posted yesterday. The post
itself was flawed, however; this time I'm attaching it as a file in the
hopes of preventing that happening again.
If there are no comments/questions/feedback on it, I'd like to go ahead and
submit it to the Collector for inclusion in Zope CVS; as it will make
continued development of ZPatterns and LoginManager much cleaner and in
full compliance with the 2.2 security model.
As I move further into the development of local role plugin support for
ZPatterns, I may have additional patches to suggest, as there are some
other encapsulation/interface issues with the "get_local_roles()" method as
currently used/implemented in Zope. Most likely, there needs to be a
"get_users_with_local_role()" method for those uses, leaving
"get_local_roles()" to mean "get *editable* local roles". Also,
ObjectManager still inspects __ac_local_roles__ rather than going through
an interface to set the initial owner role of an object. Personally, I
think this should be done by one of the many other after-add type calls
such as manage_afterAdd or manage_fixupOwnershipAfterAdd, etc., but
backward compatibility for that would be tricky.
Patch follows.
Index: AccessControl/Role.py
===
RCS file: /cvs-repository/Zope2/lib/python/AccessControl/Role.py,v
retrieving revision 1.39
diff -u -r1.39 Role.py
--- Role.py 2000/06/20 01:59:40 1.39
+++ Role.py 2000/07/23 18:46:03
@@ -365,9 +365,12 @@
keys.sort()
return keys
-def get_local_roles_for_userid(self, userid):
+def get_local_roles_for_userid(self, userid, roles=()):
dict=self.__ac_local_roles__ or {}
return dict.get(userid, [])
+
+def get_local_roles_for_user(self, user, roles=()):
+return self.get_local_roles_for_userid(user.getUserName(),roles)
def manage_addLocalRoles(self, userid, roles, REQUEST=None):
"""Set local roles for a user."""
Index: AccessControl/User.py
===
RCS file: /cvs-repository/Zope2/lib/python/AccessControl/User.py,v
retrieving revision 1.112
diff -u -r1.112 User.py
--- User.py 2000/07/11 18:42:48 1.112
+++ User.py 2000/07/23 18:46:04
@@ -137,22 +137,27 @@
"""Return the list of roles assigned to a user."""
raise NotImplemented
-def getRolesInContext(self, object):
+def getRolesInContext(self, object, findRoles=()):
"""Return the list of roles assigned to the user,
including local roles assigned in context of
- the passed in object."""
-name=self.getUserName()
+ the passed in object. If asked to find specific
+ roles, return true if any of the specified roles
+ is found, false otherwise.
+"""
+
roles=self.getRoles()
+for r in findRoles:
+if r in roles: return roles
+
local={}
object=getattr(object, 'aq_inner', object)
+
while 1:
-if hasattr(object, '__ac_local_roles__'):
-local_roles=object.__ac_local_roles__
-if callable(local_roles):
-local_roles=local_roles()
-dict=local_roles or {}
-for r in dict.get(name, []):
+if hasattr(object,
[Zope-dev] DateTime.py
There's a problem with strftime() in DateTime.py.
Try this DTML method to see:
dtml-var standard_html_header
dtml-let time1="_.DateTime('2000/07/23 BST')"
Time: dtml-var time1 br
Time: dtml-var time1 fmt=Date br
Time: dtml-var time1 fmt="DayOfWeek" br
Bad Time: dtml-var time1 fmt="%a, %d %B %Y %Z" br
Time: dtml-var "time1.fCommonZ()" br
/dtml-let
dtml-let time1="_.DateTime('2000/07/23 GMT')"
Time: dtml-var time1 br
Time: dtml-var time1 fmt=Date br
Time: dtml-var time1 fmt="DayOfWeek" br
Time: dtml-var time1 fmt="%a, %d %B %Y %Z" br
Time: dtml-var "time1.fCommonZ()" br
/dtml-let
dtml-var standard_html_footer
Note that the time given in the line "Bad Time:" above is actually wrong
-- it reports itself to be in GMT, but gives the time as one hour
behind.
If you specify a date as /MM/DD, then the date that is stored is
(quite reasonably) midnight on that day, in your timezone.
This gets rendered back into days correctly for methods such as
DateTime.day(), as these methods directly ask the DateTime instance for
what it thinks the day is. The instance replies in the context of its
own timezone (as given in the constructor, or the local timezone if none
was given), and so it returns the expected result.
If you use the strftime() method, by using fmt="%d %H %Z" or whatever,
instead of asking the DateTime instance to do the formatting, the
formatting is delegated to the Python time module.
Unfortunately, at any particular time, the Python "time" module only
knows about two timezones: Your local one (with and without daylight
savings) and GMT.
Therefore, in any other timezones, Pythons time.strftime() cannot
correctly render the time.
This is particularly apparent in the current DateTime.py, because its
strftime method just interprets the internal representation of the time
as GMT, whatever.
We can fix this easily:
*** lib/python/DateTime/DateTime.py Sun Jul 23 20:03:05 2000
--- lib/python/DateTime/DateTime.old.py Sun Jul 23 20:03:04 2000
***
*** 1376,1382
return millis
def strftime(self, format):
! return strftime(format, gmtime(self.toZone('GMT').timeTime()))
# General formats from previous DateTime
def Date(self):
--- 1376,1382
return millis
def strftime(self, format):
! return strftime(format, gmtime(self.timeTime()))
# General formats from previous DateTime
def Date(self):
Now, at least, the time will be reported correctly, although not really
usefully if you want to have the time formatted in the timezone given to
the DateTime instance.
Also, this patch will cause formatting calls to create a new DateTime
instance if the instance you want to format is not in timezone GMT+0.
The only general solution that I can see is to replicate the formatting
algorithms of the time module in DateTime.py, but written so that they
take account of timezones.
There is another issue:
When I call _.DateTime('2000-07-23'), what do I mean?
The current implementation of DateTime interprets that as "midnight (the
earliest possible time) on 2000-07-23, interpreted in the local
timezone".
However, if I'm being naive, I might think that I'm refering to a Day,
and that the Day should be the same day no matter what timezone I put it
into.
In that case, the DateTime module needs rewriting to have a sense of
precision built into it: If I specify a time to the day, I get the
latter behaviour. If I specify the time more precisely, I get the
current behaviour.
Another approach would be to make _.DateTime('2000-07-23') mean Midday,
GMT rather than Midnight, local time. That would give the latter
behaviour for most timezones at most times; the exceptions being places
near the international date line that are in daylight savings time.
--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DateTime.py -- ignore the patch
Steve Alexander wrote:
This is particularly apparent in the current DateTime.py, because its
strftime method just interprets the internal representation of the time
as GMT, whatever.
We can fix this easily:
*** lib/python/DateTime/DateTime.py Sun Jul 23 20:03:05 2000
--- lib/python/DateTime/DateTime.old.py Sun Jul 23 20:03:04 2000
***
*** 1376,1382
return millis
def strftime(self, format):
! return strftime(format, gmtime(self.toZone('GMT').timeTime()))
# General formats from previous DateTime
def Date(self):
--- 1376,1382
return millis
def strftime(self, format):
! return strftime(format, gmtime(self.timeTime()))
# General formats from previous DateTime
def Date(self):
Now, at least, the time will be reported correctly, although not really
usefully if you want to have the time formatted in the timezone given to
the DateTime instance.
No, no, no!
Ignore the patch, it is a placebo :-/
I should read these things back more carefully...
The bit about reimplementing time.strftime() in DateTime.py still holds
though.
--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DateTime.py -- ignore the patch
Steve Alexander wrote:
No, no, no!
Ignore the patch, it is a placebo :-/
I should read these things back more carefully...
The bit about reimplementing time.strftime() in DateTime.py still holds
though.
In brief, though -- and hopefuly clearer this time:
If you format DateTimes using strftime (that is, fmt="%d %m" and so
forth), you can only have the time rendered in GMT.
This is confising the counter-intuitive, as the internal timezone of the
DateTime instance is not preserved.
The only reasonable way around this is to reimplement the strftime
function of Python's time module in DateTime.py, but have it take
account of timezones.
As another issue, when you create a new DateTime instance with
_.DateTime('-MM-DD'), the actual time stored is midnight in your
local timezone. A more useful default time would be midday, GMT. This
shouldn't break much code, as the current behaviour isn't well
documented and is arguably broken anyway.
--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
