Agreed, this is a useful feature!  We've just added two new features to the file manager:

• a filter, and
• a "delete all" button

The button only deletes the files currently included by the filter. So, e.g., if you want to delete all .pdf files you could filter by "pdf" (or "pdf$" to be sure that only files ending in pdf will be included), and then hit delete all.

I hope this addresses your need. Please let me know how it goes, especially if you run into any issues using this.

Thanks for the suggestion.

Hi Adam,

Yes you are correct. As described in https://bibbase.org/help#customizationoptions a second colon indicates the beginning of regular expression flags, e.g., to indicate case-insensitive matching (i). But since filters are regular expressions, you can still filter by keywords with colon simply by replacing the color by a dot ('.'), which indicates "any character" in regular expressions.

In your case, I don't see any publications with the "Data Sources: EIG Tax" keyword right now, so I cannot send you a sample link that shows it, but in theory it would be 

https://bibbase.org/show?bib=https://bibbase.org/f/nKAPSyp34A9azBzJd/GCWealthProject.bib&sort=title&filter=keywords:Data%20Sources.%20EIG%20Tax

Glad to hear, thanks for the update!

Hi Adam,

Thanks for reaching out about this! We have been trying to diagnose the slowdown all morning. It turns out that we never tested the case you describe of bulk-uploading a lot of larger files and hence didn't realize that there was a bug that hogs resources when that happens. This is what brought things to a crawl today. The system got back on its feet when I delete the files again -- I was under the impression that that would help you.

We've now also deployed a fix for the bug that caused this, so you should be able to upload the files again and this time it should be much faster and not cause any issues. It may still be safer to try and upload them in batches of 10 or so at first. Please let me know if you have any more issues.

Thanks,

Christian

Yes, it's on their end. Without them exposing this information in some way, we won't be able to display it. But you always have the option to use a shared Zotero account of which you can import the "My Library" into BibBase -- that will include pdf links. That said, bibtex files, either self-hosted, on github, or directly on BibBase, is always the most versatile option.

Thanks for changing your group settings. I was now able to find the "fulltext"s for your group library, however when I retrieve them they are just text (not PDF), e.g.:

> curl https://api.zotero.org/groups/4501563/items/KJVQ337I/fulltext | head
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0{
    "content": "IFN Working Paper No. 1088, 2015\nThe National Wealth of Sweden, 1810–2014 Daniel Waldenström\nResearch Institute of Industrial Economics P.O. Box 55665\nSE-102 15 Stockholm, Sweden info@ifn.se www.ifn.se\n\nThe National Wealth of Sweden, 1810–2014*\nDaniel Waldenström† Uppsala University, IZA, CEPR and IFN\nSeptember 29, 2015\nAbstract This study presents a new database, the Swedish National Wealth Database (SNWD), which contains annual data on pr

So this doesn't really solve this problem, the PDFs added to Zotero are still not exposed by their API this way.

I've investigated this more. The fulltext feature Zotero describes in the link I posted doesn't seem to work very well. When I try it on a group with an item that has an attached PDF, I get "{}" (i.e., it doesn't find any). If I try it on your group I get:

> curl https://api.zotero.org/groups/4501563/fulltext

Forbidden

This is probably because your group is not public. We could try again after you make it "public closed", but so far this doesn't look promising.

Thanks. From the picture I was able to see that this is using a different account from the one under your name. Looking at that other account I found the problem. It was actually a bug on our end, regarding a corner-case in the zotero workflow. This is fixed now and your library now shows up:

https://bibbase.org/show?bib=https%3A%2F%2Fbibbase.org%2Fzotero%2Fmh_lenguyen&msg=embed#

(no need to use a collection)

Thanks for reporting this!

Christian

PS: link updated. (https://bibbase.org/service/zotero)

Hi Huong,

I've looked at your account but I don't see any Zotero credentials on it. What happens when you click this link: https://bibbase.org/service/zotero ? Could you send me a screenshot of what you see after you click that?

Thanks,

Christian