On Apr 20, 10:56 am, Asko Soukka <asko.sou...@jyu.fi> wrote: > On 20.04.2010 01:40, sunew wrote: > > > In getpaid.core.options, the PersistentOptions class, used for > > handling the annotation storage on objects, for items as well as > > payment processors and so on, was setting the annotation_key on the > > PersistentOptions class itself instead of the generated storage > > classes (like BuyableContentStorage). > > Hi, > > quite a reveal!
Yes :) And it's and old bug - introduced in revision 9. > > > The migration should probably consists of trawling through the whole > > site, and fixing annotation keys where necessary, for both content and > > settings in general. > > Which objects could really have annotations set by PersistentOptions? > Any else than he portal root (for store settings and processor settings) > and objects marked with IPayableMarker? (And those can be directly > queried from the catalog without traversing the whole site.) yes they should be easy enough to find. > > I guess, the hard part would be the heuristics to go through the > existing annotations on a particular object and move the found payable > settings to a proper annotation dict with a correct key. Although, if > we'd create a list of all possible getpaid-related annotation keys (and > respective interfaces), the only problem would be properties of > different plugins/markers with colliding names? I agree. Don't know yet if there are any conflicts. > > Interestingly, for me it seems that with the default installation all > the different payble settings (key "getpaid.content.*") get stored with > key "getpaid.configuration" > (dict(obj.__annotations__)['getpaid.configuration']). I wonder, if the > plugins can really change the class generation order so that the key > could be different from that. I guess, plugins.zcml on > Products.PloneGetPaid could prevent that. In my case everything ends up being stored under getpaid.content.variableamountdonate, which is the last content storage in Products.PloneGetPaid.content. My payment processor apparently gets imported earlier, also getting this key for storage. (a print statement in the PersistentOptions. wire class method reveal the order). Most of the general setup is now based on a utility, see Products.PloneGetPaid.preferences. > > Would you still use Products.PloneGetPaid's custom upgrading framework > for a such migration or should it be done as GenericSetup upgradeStep? I havent looked at the getpaid upgrading stuff, I guess GenericSetup would be my prefered choice. Sune > > Best Regards, > Asko > -- GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker) You received this message because you are subscribed to the Google Groups "getpaid-dev" group. To post to this group, send email to getpaid-dev@googlegroups.com To unsubscribe from this group, send email to getpaid-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en?hl=en
