Sidnei da Silva wrote:
On Wed, Oct 19, 2005 at 04:17:02PM -0400, Jim Fulton wrote:
| >| >I don't think that's a CMF 'feature', unless the product is using
| >| >'contentValues()' which is part of the CMF API.
| BTW, this doesn't mean anything to me.
I guess it doesn't.
It did to me. I tried to solve this properly by actually going and
editing the disk based software. The results are in
Products/CMFPackage/SoftwarePackage.py.chrisw.2005-10-20 on app1. It was
only after several confusing refreshes on zope.org that I remembered
Andrew saying he'd added another app server to Zope.org. *sigh* It'd be
REAL nice if even the hardware setup of zope.org was documented
SOMEWHERE so that if any of us do get pissed off enough to actually try
and fix anything, we have a vague clue of where we need to go to update
| This policy causes us a world of pain, so if it's easy to fix, I'd
| really like to know how.
Yes, it's caused by the initial workflow state for 'Software Release
File' or whatever it is called being set to 'private'. That's what was
agreed on during the initial development. It's supposed to be trivial
to change it for someone with minimal DCWorkflow skills.
I'm surprised that if it causes so much pain that nobody has fixed it
Yes, well, Sidnei, as someone who should really have known how that
software was setup, you could have taken the half hour needed to fix
this damn problem.
Anyway, upshot is that, after reading the disk-based software, laughing,
and then crying, I've employed two large tal:on-error hammers to make
this rediculous problem go away.
..both have tal:on-error="nothing" in strategic places which should just
hide releases which have problems.
Admittedly, this hides a load of potential other problems, but no-one
really cares, right? ;-)
Anyway, I'm going to go and beat some walls down with my head. Hope the
changes I've made help even a little...
Simplistix - Content Management, Zope & Python Consulting
Zope-web maillist - Zopeemail@example.com