Add the functionality for deleting (default) sections again
In the prev. versions it was always possible to delete the default sections which have been added by 1Password as default when adding a new server entry for instance. In v7 it is not possible anymore. Or I can't just find it. So I would like to ask if you can add that feature again? It's annoying if you add a server with "thousands" of predefined sections, which I don't need and can't delete. Yes, I can remove the content of these sections, but then I have a bunch of empty sections and fields (see screenshot). Why is it not possible to delete them anymore?
1Password Version: 7
Extension Version: Not Provided
OS Version: OSX 10.13.6
Sync Type: Not Provided
Comments
-
Welcome to the forum, @stefanbauer! You should still be able to delete any extra sections you've created or were imported (if you did that). You can't delete the default fields (and never could), but if you have multiple unnecessary fields in a record (which it appears you do, in the screenshot you provided), you should be able to delete them by clicking the
Editbutton and working from there. Any empty, non-default section should be able to be removed. And - as you've probably figured out - even default sections will not appear in the (non-edit-mode) record, if they're entirely empty.0 -
Hi @Lars,
thanks for your reply, but i cannot confirm what you say. Please take a look at my attached screenshot. This happens when I click creating a new "server" entry. On the left side, 1Password 6, on the right side 1Password 7. In v6 I can delete all default entries/sections. In v7 I can't. You get what I mean?
0 -
@stefanbauer - ah, gotcha. I think I may have misunderstood what you were getting at. Question: what happens when you click OUT of Edit mode? You should notice none of those areas that are not filled in being visible in the actual saved record; if a (default) section is empty, it does not appear in the record except when in Edit mode. This has remained unchanged from version 6 to version 7.
What has changed is allowing deletion of default sections/fields. When I said "and never could," in my earlier reply, that (clearly) appears to have been incorrect. It gets difficult to remember specific functionality of long-retired versions, but I think we used to prevent deletion of those fields in earlier versions of 1Password for Mac, but you're right, in 1Password 6 for Mac it was possible. We removed that ability in 1Password 7 for Mac because it's part of the structure of the database; the fields each version of 1Password expects to see (that includes 1Password for Windows, 1Password for Android, 1Password for iOS as well as 1Password for Mac -- not to mention the 1password.com servers as well). What was happening was that removing those fields altogether resulted in cases of malformed data for certain records under certain conditions, and that causes all sorts of other problems, for syncing, import/export and a variety of other operations. So this isn't likely to return as a "feature."
I'm not sure how/why you're adding a server with "thousands" of unnecessary fields, but I'd recommend adding new servers manually to avoid this issue. If all you need is name, URL, username/password and a few other fields, that'll be the most time-saving way to enter them. How are you adding them now, CSV? 1pif?
0 -
@Lars got it! Nah I add it manually. With "thousands" of unnecessary fields, I meant, that I don't need at least one of the default fields/sections in the server type entry. Of course, I don't see them in non-edit mode, but when editing, I have all those fields, have to scroll down, just because I don't need them and fill in there then my custom specific fields.
I saw your "Template" functionality in the beta state which I activated. I thought that this will solve my problem. Just copy one template, edit it to our needs, save it and hide the old one. But I found out, that some of the templates cannot be hidden, and in some others, some default sections/values cannot be changed or deleted. It's kind of little bit... not being straight in the philosophy.
Hope you don't get me wrong.
This is a screenshot of how we maintain the entries. We would like to have all the relevant data of one server in one entry. As you can see, the above default sections are all empty (because we don't need them). And then below we start using custom fields. And this really huge space above is unnecessary in our case.
0 -
Additionally to my prev. post: What I don't get is that you say these default sections are necessary as part of your database structure. But what I do know is, open my stuff in 1PW6, remove the fields and sections and then continue working on that entry in 1PW7, so it seems, for 1PW7 it's no problem that these sections/fields have been deleted. So why is a big problem to make them deletable?
0 -
@stefanbauer: Because 1Password for Mac knows how to handle its own data. :) The problem is that these data structures have a long history, and are not handled the same way everywhere. Even different versions of 1Password 6 have some variation when we've had to make changes to fix bugs or help avoid them. Being able to remove them in 1Password 6 was not intentional, but it's something we're aware of and can work around to some extent in 1Password 7. But we don't allow these fields to be removed because that can have unpredictable results when they are expected to exist, and because, of course, you can simply leave them blank and they will not be shown in the item details anyway. We would like to get custom categories/templates to a point where they're ready for everyone to use in the future (this is a long-standing dream of ours and, I know, many customers as well), but the only way we're going to get there is by sticking to the spec. So, for now, no delete for you! Sorry! ;)
0 -
As a long time user of 1Password, this is a very unwelcome change. For a password manager to tell me what data I should be storing is borderline insulting.
I have some questions for the IA/Devs behind this:
- Do YOU enter the fields for HOSTING PROVIDER every time you add a new server?
- Do YOU have an ADMIN CONSOLE for your cloud servers?
- Do YOU have a URL for all your servers?
If there was a cloud server category with no rigidity, I wouldn't be here. But there isn't.
We could get into this same argument with the Database category. It assumes many things that modern setups simply don't have most of the time.
It is very irritating to have to scroll down past all these useless (and I do mean useless) fields just to edit the information I can actually use. Not great from a UI perspective.
Bottom line: If you won't let us delete them, at least let us collapse the sections in the UI so we don't have to see 10 empty fields every time we edit.
Rants/vitriol aside, I think 1Password needs to think long and hard about the architecture for Categories. Categories should essentially be a tagging feature with some "sensible" defaults (that, btw, can be removed). Nothing more. They're categories. Not data types.
0 -
As a long time user of 1Password, this is a very unwelcome change. For a password manager to tell me what data I should be storing is borderline insulting.
@brendanc: 1Password neither tells you what data to store nor insults you. It's entirely up to you whether or not you use any field, and you won't be harangued if you leave some blank. :)
I have some questions for the IA/Devs behind this:
Do YOU enter the fields for HOSTING PROVIDER every time you add a new server?Not every time, no.
Do YOU have an ADMIN CONSOLE for your cloud servers?
For some, yes.
Do YOU have a URL for all your servers?
Many, but not all.
If there was a cloud server category with no rigidity, I wouldn't be here. But there isn't.
I don't know what this means. No one is forcing you to use all of the fields, in "Server" items or any others.
We could get into this same argument with the Database category. It assumes many things that modern setups simply don't have most of the time.
Assumptions? As with any item template, if I don't have a use for a field in that particular item, I simply don't enter anything into it. And then when I save it, 1Password doesn't display that field at all. That's true of literally every item template in 1Password. I doubt anyone actually uses every one of them in every item. They're there for those who want to use them (which saves the user the trouble of creating a bunch of custom fields from scratch each time), but they're not even displayed in the detail view if left unused.
It is very irritating to have to scroll down past all these useless (and I do mean useless) fields just to edit the information I can actually use. Not great from a UI perspective. Bottom line: If you won't let us delete them, at least let us collapse the sections in the UI so we don't have to see 10 empty fields every time we edit.
I'm sorry that you find it so irritating. Collapsing sections is an interesting idea.
Rants/vitriol aside, I think 1Password needs to think long and hard about the architecture for Categories. Categories should essentially be a tagging feature with some "sensible" defaults (that, btw, can be removed). Nothing more. They're categories. Not data types.
It's easy for you to say that. But who gets to decide what's "sensible"? I think we'd end up right back at square one. ;)
If we were just creating 1Password from scratch today, we might do something more along those lines. And perhaps we'll move in that direction over time. But any changes to re-engineer how categories work (or get rid of them completely) need to be carefully considered before we have a bunch of devs spend a lot of time and effort making fundamental changes to the apps, and make 1Password users re-learn how to use it (and work around compatibility issues when syncing with devices running pre-existing versions). I think that would actually be an evolutionary dead-end, and all because of this fixation on default template fields, and whether or not they can be removed. Long-term, we'd rather do something like custom categories, to enable a lot more flexibility. You could create your own templates! I can't say for certain when that might be possible, but it's something we'd really like too. It's probably better if we put our efforts into that than trying to shoehorn changes like this into the exiting setup. We'll never be able to satisfy everyone that way, and there would still be a lot of work and growing pains involved.
0 -
Sorry, I was very frustrated last night that I had to google why I could no longer do what I used to be able to do. I apologize for the tone, but my general sentiment towards the removal of this feature remains more or less the same.
I think where the defense of this "feature" falls apart for me is the fact that I can delete the titles of the sections and fields, leading to literally 9 or more blank fields. I'm sure this isn't intended, per se, but it is possible. It also makes these fields useless because they're also not mutable in terms of content type (e.g. string, password, date, etc). Therefore, I can't even repurpose some of them.
In other words: Why would you let me delete the contents of the fields, but not delete them entirely? As a developer (that has little/no knowledge of the behind-the-scenes in 1Password, admittedly) I can't wrap my head around a technical reason for this.
0 -
100% ack @brendanc
0 -
@brendanc and @stefanbauer - I've added this as a feature request, we'll see what we can do about it. Thanks for your diligence and persistence on it.
ref: apple-1855
0 -
Awesome! Thanks @Lars
0 -
@stefanbauer - you're quite welcome. :) :+1:
0 -
I just found this thread after getting repeatedly annoyed and confused by this same issue.
I understand the reasoning explained here behind why these template data structures must remain fixed, and while I'm disappointed that the ability to delete and repurpose the default fields in 1Password 6 was an accident, I get it. This also explains some of the weird data corruption I saw on some of my records between versions.
It's incredibly bad UI to force us to view and scroll past a bunch of fixed fields we don't want to use in edit mode. Even if those fields must remain in the structure of the app, there should be an option to hide them or move them around.
I like using the server template, for example, partly because if its icon and how easy it is to locate all my server records in one place. But I often cannot fit my data into the default fields, and I end up using custom fields at the bottom. Then, I need to scroll down past several screens of empty, useless fields (depending on the size of the viewport) just to edit my data.
I love the idea of custom templates for everyone, too, but I imagine that's a long way off. Even if more people aren't vocal about this issue of rigid default fields, I bet a lot of people are confused or annoyed by this at least at a low level. Especially anyone who got used to the flexibility accidentally offered in 1Password 6 for Mac. That's got to be a lot of customers.
If hiding the fields is too challenging, what about letting us drag them to new locations on the screen? If I could just drag all the useless default fields to the bottom, leaving my preferred custom fields at the top, it would be an acceptable workaround until custom templates are a reality. At least then I wouldn't have to scroll through and pick between a bunch of fixed fields to edit my stuff.
0 -
@chadbush - thanks for taking the time to add your voice to this thread!
I like using the server template, for example, partly because if its icon and how easy it is to locate all my server records in one place. But I often cannot fit my data into the default fields, and I end up using custom fields at the bottom.
While I can certainly understand, from the perspective of a user (which of course I also am) the advantages of "repurposing" certain templates in the absence of one that fits exactly what you're trying to do/save, I think it's not entirely fair to use one for something it wasn't purpose-built for, then point out that it doesn't do the thing you're using it for perfectly. Nevertheless, the idea of either allowing removal of baked-in template fields or the option to hide or at least move the location of some of them is well-taken.
I love the idea of custom templates for everyone, too, but I imagine that's a long way off.
Not as far as you may imagine. It's actually a beta feature in 1Password Business right now, as we speak. If you have such an account, you can enable it in the beta section and play around with it, with the usual caveats about beta features (i.e. - don't put anything truly mission critical in there, as there are still kinks to be worked out). And of course I can't say when or whether such abilities might filter down to Individual or 1Password Families accounts. Just pointing out that it's not in the "someday maybe" category.
Thanks again for taking the time to share your views; I suspect this is something we'll be iterating on in the relatively near future. Stay tuned! :)
0 -
@Lars - Thank you for your thoughts about this.
I think it's not entirely fair to use one for something it wasn't purpose-built for, then point out that it doesn't do the thing you're using it for perfectly.
I would just like to add that in my example use case, I am in fact using this template exactly for the purpose for which it was built — namely, for storing data about how to access a server — but the template is preconfigured in a way that lacks certain fields I need, and contains fields I do not need.
Specifically, I sometimes need to specify which port to connect to the server via SFTP, and that data needs to be next to the rest of the SFTP login info so I know it's there when setting up an SFTP client. But the server template contains exactly three fields at the top, and I can't add another or change the password to something else. Also, I almost never put a hosting provider on this record, because I almost always need to login to a hosting provider's control panel, and the 1Password Login prebuilt template works better for that, especially with browser extensions.
So, I don't agree that this is a matter of me trying to force a pre-built template to do something it wasn't made to do, then complaining that it doesn't work the way I want.
The design decisions made by 1Password engineers as to what default fields to include in default templates are very opinionated, and I'd guess that a lot of users probably do not agree that they make the most sense. Some degree of flexibility really would benefit the user interface.
0 -
The design decisions made by 1Password engineers as to what default fields to include in default templates are very opinionated, and I'd guess that a lot of users probably do not agree that they make the most sense. Some degree of flexibility really would benefit the user interface.
I don’t disagree. Thanks for the feedback. :)
Ben
0 -
I just came across this thread because of the same thing, the inability to delete sections using the 1password 7 Mac client where you could before.
I found you can delete those sections using the web version of 1password, not ideal but at least its something..
0 -
Thanks for the feedback. We'll see what we can do to make it more flexible in the future — both with regard to customizability, and also removing some things from the templates which are not so relevant today. :)
0 -
Hey @Lars - I'm not following this comment:
"We removed that ability in 1Password 7 for Mac because it's part of the structure of the database"
Isn't a field existing in the database and requiring it (in let's say, a model if we're talking MVC) - two completely separate things? In other words, just because a field exists in the database, doesn't mean you need to require it?
Apologies if I'm missing something, but would you mind elaborating there? I'm just not following how a field existing in the database forces you to use it.
The decision to force those fields to exist was the wrong one. Most people are not going to be using those default fields for their use cases, and it just clutters the UI and worsens the user experience. It was driving me crazy when I couldn't figure out how to remove those unused fields. It took me so long to realize that 1Password had in fact disabled the ability to do so.
They should absolutely be removable.
@chadbush is 100% on point with this comment: "I would just like to add that in my example use case, I am in fact using this template exactly for the purpose for which it was built — namely, for storing data about how to access a server — but the template is preconfigured in a way that lacks certain fields I need, and contains fields I do not need."
I'd wager that 95%+ of users fit into that comment right there.
Please refactor this.
0
