Making other categories a sub-class of the Login category

rosborn

This is a really old topic, but could I add my name to those who complain about what seems like an arbitrary distinction between other categories and login categories? At present, there is a rather clumsy (and still uni-directional by default) way of linking, say, a Rewards item with the Login item to go to the Rewards site. The reason for having a Rewards category is that it pre-defines a number of useful fields, which I would have to define every time I create a new Login item. Why not just apply the templates directly to Login items, instead of treating the Rewards category as a completely different type, i.e., treat the Rewards category as a sub-class of the Login category? If it contains a URL and a password, then it should be possible to login. My impression is that this was a design decision made many, many years ago, but I believe it has long outlasted its usefulness and should be updated in the way that many users have requested over the years. There may be categories (Documents, Drivers Licenses, Passports?) that should not be a sub-class of the Login category, but these days virtually every interaction involves logging into to website. Please make it simpler.

P.S. if there is some good programmatic reason that I don't understand for keeping the current Rewards category separate, please consider adding a way of applying templates to existing Login items. It would end up being the same thing.

---

1Password Version: 7.6
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

ag_ana

Hi @rosborn!

Thank you again for sharing your feedback with us! I replied to your post in this other discussion, and I am quoting my response to you here for your convenience:

Thank you for the feedback! I think one of the reasons categories exist is so they give flexibility: if you think using additional categories would be useful, they are there for you. Otherwise, you can use Login items and avoid the additional category if it causes confusion. In your case, from what you wrote, I think using just the Logins category, with perhaps some custom fields and sections, would be the right choice ;)

As for this question specifically:

Why not just apply the templates directly to Login items, instead of treating the Rewards category as a completely different type, i.e., treat the Rewards category as a sub-class of the Login category?

Personally, I have a couple of items in the Rewards category which have no website attached to it, because I don't have an account there. They are Rewards item with no login information to login anywhere. So making that part of the Login category would be confusing, for example.

For other reward items that do have a website, I create a Login item with custom fields as required :+1:

rosborn

What you are arguing is that, because a small number of Rewards cards might not have an associated URL, I should be forced to create new custom fields every time I create a separate login item for the vast majority that do. There has to be a more profound reason than that preventing logins from Rewards or Membership items.

Creating custom fields is tedious, and the reason for wanting a template is that it also alerts you to the kind of information that you should consider storing. This has been a requested feature for many years, by people who just want to simplify making a new item. From a programming point of view, making the Rewards and Membership categories sub-classes of the Login category doesn't seem as if it would be that hard to do.

ag_ana

@rosborn:

Thank you for the additional information! I see how this could be useful to you. We don't have any plans to change how categories work at the moment, but this is certainly something we can keep in mind should we revisit this in the future :+1:

rosborn

Let me be clear that this isn't just a convenience for an isolated customer. Other customers have been asking for this for years. Just a quick search of your forum showed similar requests here, here, and here, with someone claiming they saw a similar request back in 2010! As far as I can tell, there has never been a good explanation of why it can't be changed. We're just told that that is the way it is. It would be good if one of your developers can explain why it would be hard or undesirable to do. Ten years ago, or whenever this was first implemented, it might have been true that a lot of memberships or reward programs didn't require a login, but that is definitely not the case today.

ag_ana

Got it, thank you for the clarification @rosborn!

I can certainly ask a developer to chime in here when they get a chance :+1:

rosborn

I just hit this issue again when I had to create a completely separate Login item to accompany a Membership item. Now 1Password scolds me for using the same password. Of course, it's the same password - if you let me login from a Membership item, I wouldn't need a duplicate entry. Has there been any progress on an issue that people have complained about for 11 years or more? Will the developers have a chance to chime in anytime soon?

ag_ana

@rosborn:

We don't have any updates about this yet, sorry! The duplicate password issue is being investigated separately from our team, so I will let them know that you have encountered it too :+1:

ref: dev/projects/customer-feature-requests#130

In the meantime, I would recommend not entering passwords in the Membership item and only keep them in the Login item (Membership items cannot be filled via the browser extension anyway, so keeping the password information in the Login item will be more helpful when you use 1Password in the browser).