7.3B5 Breaks link between Alfred and 1Password

ppochobradsky

Version 7.3B5 breaks quick-open link between Alfred PowerPack and 1Password, Entering the 1p + URL string in Alfred produces no results. Version 7.2.5 works correctly.

---

1Password Version: 7.3
Extension Version: Beta5
OS Version: OS X 10.14.4
Sync Type: Not Provided

HRD

Hi @ppochobradsky,

I concur with your comment - needs an urgent fix

2dois2be

Yeah! 7.3B5 doesn't work with Aflred! It worked w/ 7.3B4

amocko

Happening for me as well.

ag_kevin

Hi @ppochobradsky @HRD @2dois2be @amocko ,

I've tested the latest with Alfred 3.8.1 (build 961, March 13th 2019) and it seems to work fine. We also have not changed anything regarding the metadata files in the latest beta.

One thing to check is if your 1Password metadata is still present. It is located in the following location:
~/Library/Containers/com.agilebits.onepassword7/Data/Library/Caches/Metadata/1Password

If should have a folder for each vault, and filled with a file for each item. If that is not there, try going into 1Password's Advanced Preferences and toggling "Enable Spotlight…" off and on again, and waiting a few seconds.

You should then see it repopulate. If you find the files go missing, check to see if you have an "app cleaner" or similar utility that may be deleting the files. That could be the source of the issue.

If the files were there all along, I recommend checking with Alfred's support. Once 1Password puts the files there, it's up to Alfred, Spotlight, and others read and use them.

Cheers,
Kevin

ppochobradsky

Kevin,
The data is populated correctly. Again, as soon as I install the beta 5, the link is broken. If I reinstall last non-beta version, everything works correctly immediately.

ag_kevin

Hi @ppochobradsky,

I did a little more testing and here's what I found out. Originally I was searching on an item with a matching title. When I searched for an item using part of the url that is not in the title, it didn't work, just like you found.

However, I noticed the URL in this item was not saved with https://. I was just www.test.com. I then edited the item, and changed the URL to put https:// in front of it so it was saved as https://www.test.com. After restarting Alfred, searching for that URL worked fine. So basically, the current version of Alfred will search any URLs with a scheme (whatever://) in front, but not one that is missing the scheme.

This looks like Alfred is having an issue indexing URLs without a scheme at the front. As we haven't changed our metadata format recently, this really looks like an issue with Alfred.

If you want to try it yourself:
1. Find an item where searching for the URL in Alfred won't work. Verify you can find the same item in Alfred by typing its title.
2. Check to see if the URL has a scheme in front. If not, edit it, and add https://.
3. Restart Alfred.
4. Try to search using the URL. It should work this time.

Cheers,
Kevin

amocko

@ag_kevin Well, I got hopeful with your first suggestion because as you suspected, for some reason, my metadata was gone. It's been repopulated now, but I'm still having the same issue. Moreover, all of the URLs I've been trying to open are start with https:// so no luck on the second suggestion either.

HRD

Hi @ag_kevin

The metadata is present.

You have clearly introduced a bug.

I was part of the private beta before this went public and Alfred worked perfectly.

HRD

Hi @ag_kevin

Fixed in Beta 6 that proves my point above.

amocko

Also fixed for me in the latest version. Seeing the release notes I wonder if mine wasn’t due to the Safari tab issue referenced.

ag_kevin

Hi all,

We haven't made any changes to metadata, but perhaps the upgrade triggered a refresh of the metadata files and Alfred picked up on it. Either way, glad to hear it's working.

Cheers,
Kevin

HRD

Hi @ag_kevin,

The notes clearly state the bug has been rectified. Why are you being so defensive about this?

AGAlumB

He's not. He's offering an explanation. At any rate, I'll close this discussion since it sounds like things are working for you now. Take care. :)

ag_kevin

Hi @HRD,

I'm sorry I didn't explain myself properly. A bug was fixed in regard to a SHA not being included in the URL: Fixed an issue where 3rd Party App Integration could fail to open an item if a URL SHA wasn't included. - which would affect those that searched and found a URL in Alfred but 1Password wouldn't open it.

That bug is not related to those that could not find the item in Alfred at all, as that is not 1Password code that is doing the search.

I hope that explains these better. Sorry for the confusion.

Cheers,
Kevin