Andrea, Thanks for your help, you are brilliant! You hit it right away. The collection owner was authorized to edit items and inadvertently set some as 'private'. I investigated that function a while back and found it dangerous because it makes items invisible in DSpace, but still crawl-able by spiders that can increment accession numbers. I never use it and forgot about it. I failed to warn off this particular user. My policy has always been to make collections private or public and not try to control access at the item level.
Anyway, I'll have to do some work to find any other items that may have been set to private. I'll look to see if there is an option to turn off setting items private, which just seems like a bad idea. Thanks again, Mark On Wed, Mar 2, 2016 at 3:17 PM, Andrea Schweer <[email protected]> wrote: > Hi Mark, > > On 03/03/16 04:07, Mark Ludwig wrote: > >> After upgrading to DSpace 5.3 we have found about a dozen items that are >> not >> indexed. Of course, there may be many more. They are not searchable in >> any way and >> can only be retrieved with handle numbers. The items we have identified >> are in >> restricted collections and have many (more than 200) files on the items. >> > > Can you verify that the items in question are _not_ marked as private? > (discoverable=true in the database, or check that the edit item page offers > you an option to make the item private rather than an option to make the > item public). You mention a restricted collection, so depending on the > restriction was set up, this may well be it. If the restrictions are > handled solely via authorisation policies, these items should show up in > discovery for logged-in users with READ rights (either directly assigned or > obtained via group membership) for the item. > > We never noticed any missing items before upgrading to 5.3 and the >> discovery index. >> Has anyone run into this? Are there some limits in the discovery index? >> > > Yes, discovery indexing can fail when there are characters in the item > metadata / fulltext file that are invalid in XML. However, ... > > We get no error messages for these items when we run index-discovery. >> > > ...with the invalid characters, you'd get an error message in dspace.log > when you run index-discovery for that particular item. > > Regarding the 200+ files on the items, there is a bug in Discovery that > means only one extracted fulltext bitstream is ever indexed for discovery. > > And we get no messages about these items at all when running filter-media. >> > Do you see derived files on the items at all (eg .pdf.txt, .pdf.jpg, > .pdf.png or the like)? > > Can you try running filter-media with the -v flag, to get verbose > messages? It should write something to stdout even without -v if I remember > correctly, but with -v it will definitely write something. I'm not sure > whether it will write something to the dspace.log file. > > cheers, > Andrea > > -- > Dr Andrea Schweer > Lead Software Developer, ITS Information Systems > The University of Waikato, Hamilton, New Zealand > +64-7-837 9120 > > -- Mark Ludwig Director of Research Systems Development and Scholarly Communications Officer University Libraries SUNY at Buffalo Buffalo, NY 14260 716 645 5952 [email protected] [email protected] http://orcid.org/0000-0001-7527-4012 -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
