Item8915: make a web directory read only, and hit edit causes ugly crash

we used to hide the actual error from the user, and tell them that they couldn't edit.

(this could be due to ASSERT - need to confirm)

I get

VC::Handler: failed to create file /home/sven/src/foswiki/trunk/core/data/Super/WebSubMenu.lease: Permission denied at /home/sven/src/foswiki/trunk/core/lib/Foswiki/Store/VC/Handler.pm line 711.

which is a regression in trunk.

also if the admin changes the permissions carefully, but then misses the hidden .change foswiki gives a proper HTML-ished error - telling the world where the foswiki topics are (exposing what should be secure information), and

VC::Handler: failed to create file /home/sven/src/foswiki/trunk/core/data/DimensionData/.changes: Permission denied

-- SvenDowideit - 16 Apr 2010

I would argue (strongly) that this is much better behaviour than a silent failure. The admin gets told something is wrong, and by a message that gives them a strong clue as to how to fix the problem.

Failure to report errors leads to those errors building up and impossible-to-debug installs. I think this report should be rejected. Marking for Sven's feedback so we can argue about it a bit.

-- CrawfordCurrie - 18 Apr 2010

I recon that silent failure is not an option either. However, it is also not necessarily true that the admin did this mistakenly. When migrating Wiki's or setting a web to legacy, its quite plausible that an admin intentionally sets the web to readonly on a filesystem level, expecting users to be able to view, but not to edit.

and so my suggestion would be to use an automatic BROADCASTMESSAGE and a 'readonly' context (so as not to fill up logs or otherwise hurt small animals).

the ancillary issue wrt the .changes file I agree - that one we should just oops on and fill up logs - everything being writeable other than our .changes file is un-necessarily complex.

-- SvenDowideit - 30 Apr 2010

I just don't think it's justified making this Urgent. There are many enhancements to the error reporting we could make, and we have to prioritise those that are most likely to bite end users.

Regrading as enhancement.

-- CrawfordCurrie - 05 May 2010

Commenting is disabled while not logged in