You are right, I filed in the latest updates (how studid of me!)
while converting
the swikis to password protected swikis (I guess I hoped to get rid
of the "(fileServer is Undeclared)"
messages that kept appearing in the transcript when starting up the
server). The edit problem
stays when converting them back to unprotected swikis. It could be
related to update 2327 (12 June 2000).
Squeaks handling of Dates and Times may easily screw up swiki
behavior - this reminds me of the idea of
an "emergency Edit button/menu item" that allows you to force an
edit (either always when you want or, only
when the previous, stored version of the page appears to be dated
"in the future").
Hans
> > Yes, I know this has nothing to do with the password protection itself,
> but
> > apparently there is a mismatch
> > in writing and reading Dates in password protected swikis, that is not
> there
> > in the normal swikis. As also
> > '12/7/2000' asDate produces the wrong Date (7 december) I suspected that
> the
> > password protected one uses this method
> > to read the dates - and yes you're right, someone may have changed
> things
> > related to Dates in the 2.9 alpha. I can't check
> > as I am leaving for two weeks now, but in any case you're warned now ;-)
>
> If you are talking about ComSwiki, and not PWS Swiki, the password
> protected swikis (the ones using security.xml files) are the same as the
> others. I wrote the code and I'm sure that the security.xml has no
> correlation to the saving or reading of files. So, I don't think your
> diagnoses was completely correct. I don't doubt that there is a problem,
> but I can assure you that it has nothing to do with the security.xml
> functionality.
>
> Peace and Luck!
>
> Je77
