[Suggestion]: sorting and grouping

[Aphraniy]

Suggestion

Hello!

Thanks you so much for your apk.
I want to propose adding sorting and grouping of the date.
Like group of banks card: credit, debit, for deposit or payment cards. And in any group can make sorting, not just in alphabet and in user order.

Thank you!

Submission checklist

• I have specified my suggestion in the issue title

[GleammerRay]

Hello @Aphraniy !

I believe this is a duplicate of #64 (folders/groups suggestion). Correct me if I'm wrong.

[Aphraniy]

Hello! Thank you for your attention! I ask not about folder, some kind of group, like in screenshot. And opportunity make sorting in group. But idea with folders is great too. I will be grateful for any opportunity. Thanks! Получите Outlook для Android <https://aka.ms/AAb9ysg> ------------------------------ *From:* GleammerRay ***@***.***> *Sent:* Friday, October 27, 2023 11:07:50 AM *To:* GlitterWare/Passy ***@***.***> *Cc:* Aphraniy ***@***.***>; Mention ***@***.***> *Subject:* Re: [GlitterWare/Passy] [Suggestion]: sorting and grouping (Issue #71) Hello @Aphraniy <https://github.com/Aphraniy> ! I believe this is a duplicate of #64 <#64> (folders/groups suggestion). Correct me if I'm wrong. — Reply to this email directly, view it on GitHub <#71 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDRZ2K3WVWJOGM6AWQ25FULYBNTVNAVCNFSM6AAAAAA6SG3EEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBSGQ4DGNJUGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Aphraniy]

screenshot пт, 27 окт. 2023 г. в 11:20, Александр ***@***.***>:

…

Hello! Thank you for your attention! I ask not about folder, some kind of group, like in screenshot. And opportunity make sorting in group. But idea with folders is great too. I will be grateful for any opportunity. Thanks! Получите Outlook для Android <https://aka.ms/AAb9ysg> ------------------------------ *From:* GleammerRay ***@***.***> *Sent:* Friday, October 27, 2023 11:07:50 AM *To:* GlitterWare/Passy ***@***.***> *Cc:* Aphraniy ***@***.***>; Mention ***@***.***> *Subject:* Re: [GlitterWare/Passy] [Suggestion]: sorting and grouping (Issue #71) Hello @Aphraniy <https://github.com/Aphraniy> ! I believe this is a duplicate of #64 <#64> (folders/groups suggestion). Correct me if I'm wrong. — Reply to this email directly, view it on GitHub <#71 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDRZ2K3WVWJOGM6AWQ25FULYBNTVNAVCNFSM6AAAAAA6SG3EEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBSGQ4DGNJUGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[GleammerRay]

@Aphraniy Unfortunately I cannot see your screenshot as you seem to be replying via email. Email replies on github do not support any attachments. Please send it via the github website or app, thank you!

[Aphraniy]

Grouping like on screenshot (red line).

[GleammerRay]

Thank you for providing a detailed screenshot. This is a good suggestion, I feel like it's best to merge the groups feature and what you have thought of in the same feature. This way, you will be able to have these group folders to split your entries based on categories.

I believe it would be more effective if when creating a new entry you will be able to add it to various groups of your choice which can then be displayed in folder format at the top of the passwords (or any other entry type) screen.

This will be kept as a separate issue for now. I will notify you once, and if, this feature is released.

[Aphraniy]

I am great to hear your approval!
If additional you can add users sorting cards in group/folder that will be really cool.

Thank you, very much!
Nice to meet you!

[franco27]

Yes, yes, all passwords are mixed
and I would also appreciate being able to group or create folders.

[franco27]

Or implement a system of tags or labels for each password, another idea if it's simpler to do so

[GleammerRay]

Code-wise there would be no difference but I believe that folders are more friendly UX-wise as most people are already aware of how digital folders normally operate

[hgkamath]

Just a user here.
Not intending to complicate, but penning for completeness

Group generalizes into tag/label. A single-group-name is like a single tag/label.
Tags/labels/category allow for non-hierarchical organization and filtering in the listing-view.

For instance, a tag-cloud with "USA, supermarkets" can narrow the listing-view to those supermarkets in USA excluding those that one used when visiting other countries, as well as excluding other categories (bank, email) etc

IMHO, for the use-case of small textual databases, folders are less preferable to tags. Folders are good when one has a need to keep entries separate in some backend and contained entries are exclusive to one another. The user may intend to forego simultaneous listing and do hard-separation by some criterion like by-user, by-creation-date, by-backup-plan, by-activity, by-industry, by-workplace etc. Though folders may allow for a system of hierarchical sub-folders, this requires the user to remember the hierarchy. Folders help when the search space is huge like a computer filesystem. However, password databases store textual information and are smaller in size.

Tags/Groups and Folders aren't exclusively implementable features. Though I think tags are superior to folders, if someone really needs hierarchical exclusive folders, supporting both is still possible. I am not familiar with kdbx internal format, but if my assumption that it is a linear list of entries is correct, then my guess is that folders will be emulated, by having a path field for entries in subfolders below the root folder. Tagged searches, could also be made to descend subfolders by checking an option.

.. returning from topic-digression on folders back to tags/groups ...
A separated-by-group listing-view requires some thought to generalize to tag-cloud/tag-filtering.

• One way to do this is to let one tag of the tag-cloud filter work as a group by field
  • ex tag cloud "Germany, supermarket" and group by "state" will filter for supermarkets in Germany and group by the state they are in. The value for the state could either come from a field in the entry, or tags themselves should be allowed to take a value.
• Another way to do this is to expect the user to create tags for each value but this may create a tag explosion
  • ex: state-california, state-new-york, state-washington, etc.
• One could also forego the need for a separated-by-group listing-view, and expect the user to each time retype the search/filter tag-cloud field to separately view listing of "Germany, supermarket, state=berlin" or debit-cards or credit-cards or cardtype=debit anything else.

More often than not, non-hierarchical tagging is more suited to the nature of information. Information entries are usually non-hierarchical and have multiple-membership.

I also sense that you care a lot for UX, but favor folders, and so to argue against I also pen the following. The idea of storing information hierarchical folders arose since the DOS/Win95 when storage size of mediums were small, computers were slow and sharding was inevitable. Much analogy was to paper storage. It was necessary for users in those days to care about data hierarchy in order to facilitate easier storage and faster searching. gmail, in contrast to traditional email clients (thunderbird, outlook, msn/hotmail) was one of the early adopters of labels and introduced to its users the idea to prefer tagging over email-folders. Since 2010, more and more software support tagging. Older users who are used to folders, may at first have found tagged information a little more abstract than folders, in part because one needs to let go of the 'where is it stored' feeling. but now they too are warming up to the tagging method, finding tagging natural and relegating folder separation to the hash-breadcrumb based backends. Folders will start to feel a little restrictive, due to exclusive partitioning. Ex: most note-taking tools do tagging. Younger users, who are raised on fast computers, large system-drives and cloud storage take to tagging naturally, install the software, start using it, feel not the need to transfer data around on floppies or even USB-sticks. For the most part, they need not care about where and how an app stores its data, but in addition to syncing between machines will be expected to do occasional remote backups.

[GleammerRay]

Hello again @hgkamath ! I understand your request for tags and I will consider implementing it.

I am not familiar with kdbx internal format, but if my assumption that it is a linear list of entries is correct, then my guess is that folders will be emulated

Passy does not utilize KDBX as it does not fully meet Passy's data management ideas but Passy's format is indeed made up of linear lists of encrypted entries to which I plan attaching virtual folder information.

More often than not, non-hierarchical tagging is more suited to the nature of information.

That is a good point. I believe that it is worth trying to implement tags. I'll try it out and see how it goes. As always, I post any related developments in corresponding issues. Thank you!

[GleammerRay]

After a long intermission, I am glad to finally announce that tags and most tag-related features are now implemented on the dev branch and that Passy v1.8.0 is coming sooner than ever. There are still a few small things left to work on (Aegis import) but they should not be of any problem.

Tag synchronization will most probably be backwards compatible with older Passy versions for most entry types regardless of Passy version with notes being the one exception (notes data structure modified to include tags, tag data will be lost if note entries are modified on older Passy versions).

I am planning to release Passy v1.8.0 this/next month and I am looking forward to your feedback very much.

Here are some preview screenshots including the new tags features:

[GleammerRay]

Hello @Aphraniy , @franco27 , @hgkamath !

Passy v1.8.0 is now available - https://github.com/GlitterWare/Passy/releases/tag/v1.8.0

Windows and Linux builds are already available but it may take a week or two for the F-Droid builder to cache Passy in their repositories.

Thank you all for your input on this suggestion!
I will keep this issue open for now so that one may propose additional improvements to it. Feel free to unsubscribe from this issue if you do not wish to receive further notifications here.