Feature request: item and data linking
This affects both mac/windows
Right now, if I set up a server record, I either have to put up with having two records (one Server Account, one Login), or I have to do a whole bunch of ultimately unnecessary mouseclicks etc instead of being able to ctrl-\ on a control panel.
When on a page that matches a Server Account's "Admin Console URL", offer those credentials for that page.
Alternatively, add the ability to have a URL matching list in any record type.
Alternatively alternatively (and perhaps most flexibly), add functionality to create a login that keeps the URL(s) and form field names, but can take the actual credentials or other data for those form fields from another 1password record.
At the very least, allow me to search for non-login record data from the browser plugin.
1Password Version: 4.6.0.592
Extension Version: 4.4.3.90
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:"admin console url"
Comments
-
Greetings @Hatclub,
A little odd but I thought I would address these in reverse order. The search feature in 1Password mini will return any matching item it finds regardless of the category but this is specific to searching rather than URL matching. If searching isn't returning what you expect there are two possibilities that spring to mind.
- Is the item showing at all in 1Password mini? If it isn't it might be worth checking the display setting for that item in case it has been changed from the default setting of Always to Never display in browser.
- If you're searching based on information stored in a the major fields (I'll have to ask what these may be for items outside Login items) then you may want to alter the depth of the search by altering one of 1Password mini's settings. Open 1Password mini, click on the cog icon in the top right hand corner and then change the search behaviour to Search All Fields.
I'll have to ask regarding the other requests. I know a lot of the behaviour we still see today is based on the design decisions made in 1Password 3 and the Agile Keychain. For example a Login item has a mandatory username and password field that cannot be deleted and these are the ones used in filling. A Server item has a number of fields set up by default but all can be deleted. As I don't know the code intimately I don't know if this is problematic or not. The developers will know :smile:
If it were myself wanting a working approach now I would probably use the same approach that I take with my email accounts. As you know we have an Email Account category but like the server item that won't fill if you're trying to use a webmail login page. What I do is I store all the pertinent details for setting up a proper email client in the Email Account item and then maintain a single Login item that stores my username and password so that I can both log in whenever needed and only have a single item to update when required. Tags then allow me a way of visually seeing that I consider items linked, something I keep intending to do for my credit cards and sites that store the details (so I know which need updated when a card expires).
I don't know if my approach will be of any use to you, it may not match your preferred workflow at all in regards to 1Password but I offer it as a suggestion just in case :smile:
0 -
I don't know if this is relevant to the answers to your questions, but I use the old vault format specifically because I want/need 1password anywhere for occasional use on Linux systems, and I use windows predominantly and so do not have 1Password Mini to hand (the vast difference in slickness between the mac and windows versions of the software in this regard are another considerable bugbear with no obvious underlying reason)
The browser plugin (even when searching) never returns anything other than objects of type "Login". Never has, as far as I know. I can't see any options on objects in 1password itself controlling whether or not they are displayed in the browser.
I don't have anything that aligns with your instructions in either the browser plugin or 1password itself under windows.
I have resigned myself to creating two entries for the time being, it's just not a particularly elegant solution to have to maintain twice as many records - especially as I'll create the server record first, generate passwords in there, etc - it's just not very elegant atm at all.
0 -
I've just tried this on a mac and, in fact, it works exactly as I would want it to on the Mac. So I guess this is a windows (which is still languishing on v4) specific problem.
0 -
At the very least, allow me to search for non-login record data from the browser plugin.
@Hatclub: Indeed, 1Password for Mac version 5 is 'newer' than 1Password for Windows version 4, and both receive regular updates. And of course that means that the Windows version won't magically 'catch up', since they're both moving right along!
I guess I'm not sure why you have two items for the same thing in the first place. Personally, I'd use a Login item and take advantage of custom sections and fields to set it up the way I wanted. But of course that's a matter of preference.
We'll definitely continue to work on improving consistency between platforms going forward though, and I'd be interested to hear any other feedback you have. :)
0 -
Hi @brenty -
If that is the response then my counter argument would be "why have any of the extra item types at all?" and the answer, of course, is because it saves time over re-inventing the wheel each time you want to save something similar to an existing item (or unnecessarily maintaining your own templates).
As Mac v5 doesn't treat non Login items as second class citizens I guess I'll hope for PC to catch up, though it feels like you're suggesting that it cannot be taken for granted that both products will develop in the same direction... which makes no sense whatsoever. Are you suggesting that it is not a given that every single improvement that Mac v5 made is not on the roadmap for PC?
0 -
If that is the response then my counter argument would be "why have any of the extra item types at all?" and the answer, of course, is because it saves time over re-inventing the wheel each time you want to save something similar to an existing item (or unnecessarily maintaining your own templates).
@Hatclub: Actually, the answer is that many of them server specific functional (rather than simply organizational) purposes: Logins, Identities, Credit Cards, etc.
While you should do what makes the most sense for you, anything I'm going to use to login to something is, well...a Login item, both from a functional perspective and also because my brain goes there expressly because of my intended use.
though it feels like you're suggesting that it cannot be taken for granted that both products will develop in the same direction... which makes no sense whatsoever.
Nope. They just can't be the same, by definition. The code is different; the underlying OS and its frameworks are different. So while we'll continue to work to make them more similar in many ways, it isn't possible (or appropriate) for a Windows app to work exactly the same way as a Mac app.
Are you suggesting that it is not a given that every single improvement that Mac v5 made is not on the roadmap for PC?
Absolutely. As an example, Quick Look is an OS X feature. We can't use it on Windows, though we'd love to! There are also things like that which we try on one platform, but it turns out to be problematic even there. Vaults are a great example. They work differently on both platforms (one at a time on Windows versus multiple on Mac), and I can, on any given day, have an incredibly thoughtful discussion with a 1Password user on both sides of this debate. And these are just two quick examples of the top of my head.
My point is that we're not going to put 1Password for Mac on hiatus while 1Password for Windows 'catches up' to version 5; and when 1Password for Windows version 5 is developed, we'll have the benefit of learning from experience and feedback. After all, nothing is perfect, and it would be silly of us to try to simply duplicate 1Password for Mac 5.0 in 1Password for Windows 5.0 (or expect that we even could), because we can put knowledge to good use, and perhaps also take advantage of OS-specific things at that time. If we simply make 1Password for Windows version 5 the same as its OS X counterpart, we're squandering an opportunity to innovate and come up with something that we might want to add to another platform later on. :)
0 -
Actually, the answer is that many of them server specific functional (rather than simply organizational) purposes: Logins, Identities, Credit Cards, etc.
Right, and Server Accounts serve the purpose of recording Server Accounts, and they have a box specifically for "Control Panel URL" so it's not a stretch to imagine that data being used when evaluating items for matches in the browser plugin. Like Mac v5 does.
though it feels like you're suggesting that it cannot be taken for granted that both products will develop in the same direction... which makes no sense whatsoever.
Nope. They just can't be the same, by definition. The code is different; the underlying OS and its frameworks are different. So while we'll continue to work to make them more similar in many ways, it isn't possible (or appropriate) for a Windows app to work exactly the same way as a Mac app.
I'm really not talking about functionality or behaviour that is platform specific. I don't think offering/searching of items in browser plugins/mini should differ between the platforms and I reject any characterisation of efforts to unify that behaviour being stymied by platform-dependent framework availability.
Are you suggesting that it is not a given that every single improvement that Mac v5 made is not on the roadmap for PC?
Absolutely. As an example, Quick Look is an OS X feature. We can't use it on Windows, though we'd love to!
Okay, my fault for not being specific when talking to a developer, but, again, I'm talking about behavioural improvements/differences in the application code you have written. Not platform specific framework gimmicks (and it's not like Quick Look behaviour couldn't be re-implemented on anything - it's entirely understandable that it's probably not worth anyone's time to do so, however).
Vaults are a great example. They work differently on both platforms (one at a time on Windows versus multiple on Mac)
What's the framework or platform reason for not supporting multiple concurrent vaults on Windows?
My point is that we're not going to put 1Password for Mac on hiatus while 1Password for Windows 'catches up' to version 5;
I wasn't asking you to
After all, nothing is perfect, and it would be silly of us to try to simply duplicate 1Password for Mac 5.0 in 1Password for Windows 5.0 (or expect that we even could), because we can put knowledge to good use, and perhaps also take advantage of OS-specific things at that time. If we simply make 1Password for Windows version 5 the same as its OS X counterpart, we're squandering an opportunity to innovate and come up with something that we might want to add to another platform later on. :)
I'm not sure why the concept that you would shoot for a consistent application logic behaviour on two desktop platforms is considered "silly", though I think you've fixated on "visual" features at this stage... But if you don't take application changes and improvements from one platform to the other (because it's 'silly' to aim for unity), how exactly are the innovations that are made in windows v5 going to make it back to another platform?
The difference in underlying frameworks is not really a substantive reason to not make efforts to align the application's behaviour between the two platforms for the benefit of your users who work on both platforms (something you clearly are aware of through offering the two platforms in a bundle deal) even if visually they might look different.
0 -
The difference in underlying frameworks is not really a substantive reason to not make efforts to align the application's behaviour between the two platforms for the benefit of your users who work on both platforms (something you clearly are aware of through offering the two platforms in a bundle deal) even if visually they might look different.
@Hatclub: We are absolutely making efforts. As I said originally,
We'll definitely continue to work on improving consistency between platforms going forward though, and I'd be interested to hear any other feedback you have. :)
But of course there are imitations, and no matter what, it takes time. Ultimately anything like this needs to be viewed pragmatically, which is why I mentioned using a Login item for login filling. I can't say for certain if or when we'll make the changes you're asking for, but I'd love to hear if you have any other feature requests. :)
0
