Attribute 'protected' creates inconsistent behaviour

[dereks]

There is a "protected" attribute that is calculated for dirs and files. In the PHP connector (on line 1061), this is set to true unless the dir is both readable and also writable.

A small lock icon appears on dirs that are "protected".

If the user clicks on the tree's Plus-sign Button to expand the folder, he will get an error "System permissions do not allow you to perform this action." But if he just slides the mouse a few pixels to the right, and clicks on the name of the folder instead, it will open up the (read-only) folder. (It took me a while to figure out this was the case... I thought I was going crazy for a few minutes. "It works. Wait no.... what?")

This is because the onClick callbacks for the Plus-sign Button and the directory name are different. The plus sign has this extra javascript pre-check:

if(node.rdo.attributes.protected) {
	fm.error(lg.NOT_ALLOWED_SYSTEM);
	return false;
}

In contrast, clicking on the dir name just tries to read the dir, which works fine for read-only dirs.

Aside from this annoying user interface glitch, there is a deeper problem with the attribute "protected". It is used in filemanager.js on these lines, to mean different things:

• Line 505 ('protected' means it's not writable)
• Line 2277 ('protected' means it's not readable)
• Line 2921 ('protected' means it's not readable)

This makes is impractical to have files or dirs that are read-only on the shared filesystem. Furthermore, on Unix systems, there are sometimes dirs that are writable but not readable, for example, as drop locations, or for logging.

(The native Ubuntu "Nautilus" file manager only displays a lock accent on folder icons that are not readable. It does not accent directory icons based on whether or not they are writable.)

In order to support the basic difference between "read-protected" and "write-protected", I believe there need to be two separate attributes for objects. I will submit a Pull Request to implement this shortly.

[dereks]

OK, I just submitted a Pull Request with this change.

In this implementation, the lock accent only appears on folders that are unreadable, which is how my native file manager does it.

I've tested it locally on Ubuntu 14.04 with Chrome and it worked. RichFilemanager now gives me the same behaviour I get from phpFileManager.

I am not able to test the .ashx implementation. (The .ashx version just sets both attributes to zero, like it did with the 'protected' attribute.)

Thanks!

[psolom]

Good catch. After merging your commit I have changed attributes: read_protected to "readable" & write_protected to "writable", and reverted values, of course. Looks more friendly and should work according to your description. However feel free to make additional review and verification to make sure it works as expected.

Thanks for the contribution.