id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
1313	tiddly_on_tahoe shouldn't offer the option to save changes when you are viewing read-only	arch_o_median	nobody	"If you view a tiddly wiki through a read-write capability, like this:

 http://testgrid.allmydata.org:8123/uri/URI%3ADIR2%3Aedsdo6ees7ugabbyyy65635y5y%3Axthwymetpwjs5brmobmcjg7zeld37hdnc6jxyw5crayykraaufma/wimm.html

Then you should have a ""Save Changes"" button. But if you are viewing it through a read-only capability, like this:

 http://testgrid.allmydata.org:8123/uri/URI:DIR2-RO:kjtsjg4qrpzgjymiupf7qt2beu:xthwymetpwjs5brmobmcjg7zeld37hdnc6jxyw5crayykraaufma/wimm.html

Then you should not.

Note that those are two views on the same file, so for example if you edit and save the file using the read-write view, your changes will be visible in the read-only view.

Currently you get a ""Save Changes"" button in both cases, but if you try to use that button in the latter case then it fails.

One way to implement this feature -- the feature of showing the Save Changes button only in the case of the file being writable -- would be to parse the URL and see if it is a tahoe /uri/URI:DIR2 URL or if it is a tahoe /uri/URI:DIR2-RO URL. However, it would be too bad if adding this feature made the
!HTTPSavingPlugin become Tahoe-specific, because currently the !HTTPSavingPlugin is entirely general -- any server which respects the simple REST notion that ""HTTP PUT to a URL ought to overwrite the resource located there"" will work with the current !HTTPSavingPlugin.

So one way to go about it that might be more general is to have the HTTPSavingPlugin do a test PUT when it loads. If that PUT succeeds, then enable the ""Save Changes"" button. If that PUT gets an error, then keep that button hidden.


Changed 2 years ago by zooko

    * Summary changed from don't offer the option to save changes when you are reading from a read-only copy to don't offer the option to save changes when you are viewing read-only

comment:2 Changed 2 years ago by zooko

Also, when you are viewing a tiddly wiki which is writable, then it should be visually distinct from one which is read-only, to avoid that you accidentally give someone the URL to the read-write one when you thought you were giving them the URL to the read-only one.
comment:3 Changed 2 years ago by zooko

Tiddly Wiki already has an option named chkHttpReadOnly. This ticket is basically asking for that option to become cantWriteReadOnly. Instead of disabling the editing features whenever it is loaded over HTTP, disable the editing features whenever it fails to write a test file.
comment:4 Changed 2 years ago by zooko

Fixed by [changeset:4e5a6bf808cfdbb4].
comment:5 Changed 2 years ago by zooko

    * Status changed from new to closed
    * Resolution set to fixed

really fixed nicely by [changeset:94e051c1f06bf8b3] and associated patches. :-)"	defect	closed	major	undecided	unknown	1.8.1	fixed	tiddly