feature request: Read-Only mode

[linuxmail]

hi, like already on the wishlist, I would like a read-only mode too :-) especially working with multiple users and/or teams it would be great, if I can open Gorilla in a Read-Only mode.

[rich123]

Maybe I am missing some context, but if working with multiple users or teams and a shared passwordsafe file, wouldn't filesystem read only permission on the safe file achieve the same effect?

One small troublesome point is that the only support in the passwordsafe file format for any read-only setting is a field per entry for protecting a single entry (below from the pwsafe-format-v3.txt file):

[17] Entry is protected i.e. the entry cannot be changed until the user unsets this field. Effectively a read-only entry in a read-write database. This field was introduced in version 0x0308 (PasswordSafe V3.25). This a single character. An absent field or a zero valued field means that the entry is not protected. Any non-zero value is taken as meaning that the entry is protected.

And this setting would be one that any one of those shared uses 'could' unset if they wished and overwrite that password entry. I.e., it is not a global "protect the safe" flag. As well, at the moment Gorilla does not utilize that flag.

Which brings me back to that lack of context I mentioned at the top of this note. I'm not seeing just how you are making use of Gorilla in this shared environment nor am I seeing what issue it is you are trying to protect against, and not having the whole picture is not helpful from my end.

[linuxmail]

hi Rich123,

we have the file on a Dropbox and one user changed the contend, while I had Gorilla open. I made changes too and saved it, so we had a conflict. Dropbox created a "copy" from the password save and I saw it to late ..., so I have to ask the user, what he changed, or create a diff by my self ... In nearly 98% I want to have Gorilla open for reading, not for make changes ... so a "read-only" would force me to tell all others, to close Gorilla, so that I can do my changes without getting in conflicts. That was the idea behind the read-only mode. To make it possible to have the password-save on a Dropbox like share.

[rich123]

Ah, that helps. The 'development' branch (pre-160) of Gorilla includes some code that will give you a warning that the underlying safe has changed (provided of course that the change is visible to the running Gorilla process) before you make a save. This might have given you a warning when you tried your save that someone else had saved a change. (Note, not saying a 'read-only' feature isn't bad, just that the pre-160 branch might have acted differently for you in this situation.)

Does dropbox support any form of 'read-only' setting for files inside a dropbox? That could also work to prevent overlapping changes as well.

As for a 'diff', are you aware of Gorilla's 'merge' feature? It produces a 'diff' of two safe files and lets you select which changed items to keep from the pair. The intent of 'merge' was for a single user making changes on two different systems (desktop/laptop/etc.) and being able to merge the differences together later. But it would also work (because all it does is 'diff' a pair of safes) in the context of a pair of dropbox version1/version2 files for seeing what changed and combining the pieces.

[AndyHunt66]

I would like a read-only mode as well, but for a different reason - basically, that I'm clumsy.

I find it's too easy to accidentally drag'n'drop individual items when I'm trying to view the context menu for them, prior to e.g. editing, Add Login, etc.

The problem is worse on my linux laptop than on my windows desktop, as the right-click context menu doesn't stay open after right-clicking, and I have to use two hands on the laptop touchpad to a - keep the context menu open, and b - navigate to the correct menu item.

thanks, Andy

(p.s. I was not aware of the merge option, (for exactly the reasons you specify) and only came here to see if someone had already done one! Saves me some csv munging :-) )

[rich123]

Hmm... @AndyHunt66, what if the context menu for right click were to remain open after a click like the File/Edit/Login menus do (well, at least they do for me on Linux)? Then you could either a click inside the menu to pick a command, or click outside to dismiss the menu.

[AndyHunt66]

Yes! That would definitely help. And yes, my File/etc. menus remain open as well.

It wouldn't solve my clumsiness though, and I'm sure I would still manage to accidentally drag items , even on windows with a mouse :-), but yes, it would be a great help.

[rich123]

On your Linux system, are you running the source bundle (such is easier on Linux given that most distros. include Tcl/Tk as an installable package)?

If so, you can change this line (it is line 635 in the latest tip of the pre160 branch) in "gorilla.tcl":

bind .tree < Button-3 > { gorilla::TreeNodePopup [ gorilla::GetSelectedNode %x %y ] }

to say:

bind .tree < ButtonRelease-3 > { gorilla::TreeNodePopup [ gorilla::GetSelectedNode %x %y ] }

(Edit: Github messed up the syntax above. To get the < Button-3 > to appear, I had to add spaces between the greater than/less than signs. In the actual Tcl source there should be no spaces (but if I remove the spaces, the text disappears entirely here))

Then you will get the "sticky" (stays open until another click somewhere) style right-click context menu. The disadvantage is that the menu does not appear until you release the mouse, so you can't click, hold, and select an item in this mode. But you can give it a test run to see if it helps for the touchpad.

[AndyHunt66]

Aha! Fantastic. That works - Thank you!

A tiny, tiny "but", however... You can't dismiss the context menu (by clicking somewhere else, outside of it), if you haven't first highlighted/moved the cursor over one of the menu items.

1 - Right click a login item -- Context Menu pops up 2 - Don't move the cursor over any of the items in the menu - move it directly into a blank space in the UI 3 - Click (left or right - doesn't matter)

Expected result:

• Context menu disappears

Observed result:

• Context menu remains

(like I said - a very minor issue)

[rich123]

The issue you note is expected. This is the simplistic variant that has rough edges (the dismissal issue being one of several rough edges). I'm thinking/experimenting through on a variant with much smoother edges, but it requires more changes than just a single line.