[BUG]: Sugesstions for improving UI/UX for (folder) sharing

[h-2]

Describe the bug

First of all: Super happy to see this feature, thank you very much! Please see all of the following as constructive criticism ❤️

What are the permissions?

Upon creating a share of a folder, it says:

[] create [ ] edit [ ] delete

Upon creating a share of an individual note/list, it says:

[ ] read [ ] edit [ ] delete

That's a subtle difference, that is easy to overlook. Also, "edit" on note implies "read" on note, but "edit" on folder does not imply "create" on folder, does it? How does inheriting of these work?

More generally: is this difference really useful? From a security point of view, anybody with "edit" rights can add any content and remove any content, completely. What good is it, if someone cannot "delete" a note, but they can delete all the content of the note?

I think that for an application of Jotty's scope (small to medium number of users per instance), having only one distinction in "read-only" vs "read-write" (where the rw implies create and delete) would be totally sufficient (and much easier to communicate visually).

Inheriting

This is a bit confusing, because obviously the item inherits the sharing properties at the moment. If I do not click on "Keep this one private", why can I still modify the ui elements below? What happens?

I would suggest one checkbox on everything that is not top-level:

• Inherit from parent folder.

If this is checked, all other ui elements should be disabled/read-only (but still show correct values). If I uncheck the box, the inherited settings become encoded locally for the current item and the UI elements become enabled, so the settings are mutable.

This also allows a clean way to return to the default (by checking the top checkbox and re-inheriting the settings).

Sharing without any rights

What is the implication of sharing something but allowing neither create, edit, nor delete? I can remove all of this, but then it is still "shared" and I need to additionally "remove the user" from the share. This is not intuitive. Unchecking all three boxes should be the same as removing the share with the user.

Steps to Reproduce

See above

How do you run Jotty?

Other

Jotty Version

1.26.0

Checklist

• I have searched across other issues to make sure this bug has not been already reported.

[h-2]

To underline the inconsistent language and visual cues:

• for folders, it says "Can Edit", "Can Delete" ...
• but for notes, it says only "Edit", "Delete"

And

• for folders, there are no individual icons, and the red 🗑️ icon means "remove share"
• for notes, there are individual icons, and the red 🗑️ icon means "Delete"; while "remove share" has a different icon "user-".

I would suggest:

• Sharing with a user always means read-access. "Removing the share" means revoking read-access (and any other access).
• A single checkbox for notes/lists:
  • Edit
• A single checkbox for folders:
  • Create/Edit/Delete

[fccview]

Upon creating a share of a folder, it says:

[] create [ ] edit [ ] delete

Upon creating a share of an individual note/list, it says:

[ ] read [ ] edit [ ] delete

That's a subtle difference, that is easy to overlook. Also, "edit" on note implies "read" on note, but "edit" on folder does not imply "create" on folder, does it? How does inheriting of these work?

More generally: is this difference really useful? From a security point of view, anybody with "edit" rights can add any content and remove any content, completely. What good is it, if someone cannot "delete" a note, but they can delete all the content of the note?

I think that for an application of Jotty's scope (small to medium number of users per instance), having only one distinction in "read-only" vs "read-write" (where the rw implies create and delete) would be totally sufficient (and much easier to communicate visually).

create is folder specific, allows users to create files within a folder, right? Edit is not the same as create, because when you have "edit" it means users have "edit" power within the files in the folder, doesn't mean you may want them to be able to create new files or move files within the folder itself, it's more fine grained this way

More generally: is this difference really useful? From a security point of view, anybody with "edit" rights can add any content and remove any content, completely. What good is it, if someone cannot "delete" a note, but they can delete all the content of the note?

You are probably right on this one, maybe individual notes/checklists don't need a difference between edit and create, and probably folders don't need "edit" permissions, but I made it so it's easy to inherit, folder has all 4, notes/checklists have 3 of them, the only one that may make sense dropping is delete, but is having more control REALLY that bothersome?

This is a bit confusing, because obviously the item inherits the sharing properties at the moment. If I do not click on "Keep this one private", why can I still modify the ui elements below? What happens?

I would suggest one checkbox on everything that is not top-level:

• Inherit from parent folder.

If this is checked, all other ui elements should be disabled/read-only (but still show correct values). If I uncheck the box, the inherited settings become encoded locally for the current item and the UI elements become enabled, so the settings are mutable.

This also allows a clean way to return to the default (by checking the top checkbox and re-inheriting the settings).

This is SO much smarter than what I did and I'm 100% changing it to work this way, thank you!

What is the implication of sharing something but allowing neither create, edit, nor delete? I can remove all of this, but then it is still "shared" and I need to additionally "remove the user" from the share. This is not intuitive. Unchecking all three boxes should be the same as removing the share with the user.

Read is a valid permission and default, without edit/delete/create you still have read only abilities, you may want to share a folder of view only elements with a group of people without them being able to do anything to said documents aside from reading them (a clear example of this is the demo, it has read only access to all files within a shared folder for people seeing the demo).

I would suggest:

• Sharing with a user always means read-access. "Removing the share" means revoking read-access (and any other access).

• A single checkbox for notes/lists:

  • Edit

• A single checkbox for folders:

  • Create/Edit/Delete

How would you fine grain create/edit/delete tho?
What if somebody wants to allow create but not delete for example?
What if you want to Inherit edit for notes but don't want users to create in the folder?

The reason why i'm pushing back is because (aside from the language inconsistencies you mentioned, which are totally valid) not everyone is probably thinking of using this feature the way you are, if I do it your way I close off customisation for people who may want it, whilst if i leave it fine grained as is, both you and someone else have total freedom on using the feature however you want it!

Regardless of how this conversation will go, both the inherited permission checkbox and language inconsistent WILL be fixed and release with next one, and this kind of feedback/issues are ALWAYS appreciated, I'd never take them in a negative way, so thank you so much for taking the time helping improve Jotty, frankly without you pushing me this feature wouldn't exist to begin with ❤️

[h-2]

Regardless of how this conversation will go, both the inherited permission checkbox and language inconsistent WILL be fixed and release with next one, and this kind of feedback/issues are ALWAYS appreciated, I'd never take them in a negative way, so thank you so much for taking the time helping improve Jotty, frankly without you pushing me this feature wouldn't exist to begin with ❤️

Thank you for making this application and being so open to feedback ❤️

create is folder specific, allows users to create files within a folder, right? Edit is not the same as create, because when you have "edit" it means users have "edit" power within the files in the folder, doesn't mean you may want them to be able to create new files or move files within the folder itself, it's more fine grained this way

Yes! That's what I was getting at. Ownership/permissions/sharing is not trivial, and you end up encoding a lot of things implicitly that are not super obvious:

• "create" means creating new notes in the folder. You say that's independent of "edit". So I can create a note in a folder that is shared with me. But I am not allowed to "edit" any notes in that folder. So can I edit the new note, or can I just create empty notes then? Or do I become the "owner" of the new note? Can I then prevent the owner of the folder from editing it?

I am not saying this is useful; I am just trying to highlight that the more options you offer, the more weird combinations you run into, with the potential of bugs or at least surprising behaviour.

You are probably right on this one, maybe individual notes/checklists don't need a difference between edit and create, and probably folders don't need "edit" permissions,

Folder needs "edit", because that's what covers "rename", right?

but I made it so it's easy to inherit, folder has all 4, notes/checklists have 3 of them,

But I also only see three on folders in the interface? Also having some permissions that are for the thing itself; and other that are only meant for the things that inherits from it...

the only one that may make sense dropping is delete, but is having more control REALLY that bothersome?

In my younger open source life, I loved having all the options. In my older software engineering life, I always see all the potential bugs and misunderstandings 😅

I will try to elaborate:

Flag	Meaning on folder for folder	Meaning on folder for children	Meaning on children
Read	n/a	Can read	Can read
Create	Can create children	n/a	n/a
Edit	Can rename	Can rename+edit	Can rename+edit
Delete	Can delete (incl children)	Can delete	Can delete

This table also explains why you hide "read" on the folder and hide "create" on the notes/lists. But I just realised that now after making this table :D
It isn't rocket science, but it is a lot more than "read-only" vs "read-write".

How would you fine grain create/edit/delete tho?

I wouldn't 🙂

For me, it's either "mine" (not shared), "mine but I want to show you" (shared read-only), or "ours" (shared read-write, but then I don't care about the details).

If I really wanted more fine-grained control, I can create a parent folder, and have one subfolder that is read-only (e.g. instructions) and one subfolder that is writeable.

What if somebody wants to allow create but not delete for example?

If they allow create, they need to allow edit, too, right? (see my confusion above)
If they can edit, they can delete all the contents...?

What if you want to Inherit edit for notes but don't want users to create in the folder?

Well... If I allow users to basically create infinite content inside my notes, and also delete all existing content within my notes... I don't see that disallowing them to create a new note in the folder is very useful? After all, every user can create infinite private notes and share all of them with me, if they want to spam me...?

To sum up:

• My concern is certainly not super important!
• But I don't think the added complexity of fine-grained controls is worth it.
• Neither to users
  • because the fine-grained controls aren't that useful
  • because it's non-trivial to understand what the options actually mean
• Nor to developers
  • because more options/combinations that need testing/debugging/explaining