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/ on app1. It was only after several confusing refreshes on that I remembered Andrew saying he'd added another app server to *sigh* It'd be REAL nice if even the hardware setup of 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 stuff :-(

| 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  -

Reply via email to