Item(s) Not Found

#1

A user account with Site Administrator role added three new Items to our install (1.4.0) but each of them results in an error of Omeka\Api\Exception\NotFoundException: Omeka\Entity\Item entity with criteria {"id":"7208"} not found in /var/www/html/application/src/Api/Adapter/AbstractEntityAdapter.php:623

I don’t have direct db access. Is there another way to address this, preferably by scrubbing the offending Item records?

Remainder of stack trace:

#0 /var/www/html/application/src/Api/Adapter/AbstractEntityAdapter.php(351): Omeka\Api\Adapter\AbstractEntityAdapter->findEntity(Array, Object(Omeka\Api\Request))
#1 /var/www/html/application/src/Api/Manager.php(230): Omeka\Api\Adapter\AbstractEntityAdapter->read(Object(Omeka\Api\Request))
#2 /var/www/html/application/src/Api/Manager.php(115): Omeka\Api\Manager->execute(Object(Omeka\Api\Request))
#3 /var/www/html/application/src/Mvc/Controller/Plugin/Api.php(136): Omeka\Api\Manager->read('items', '7208', Array, Array)
#4 /var/www/html/application/src/Controller/Admin/ItemController.php(62): Omeka\Mvc\Controller\Plugin\Api->read('items', '7208')
#5 /var/www/html/vendor/zendframework/zend-mvc/src/Controller/AbstractActionController.php(78): Omeka\Controller\Admin\ItemController->showAction()
#6 /var/www/html/vendor/zendframework/zend-eventmanager/src/EventManager.php(322): Zend\Mvc\Controller\AbstractActionController->onDispatch(Object(Zend\Mvc\MvcEvent))
#7 /var/www/html/vendor/zendframework/zend-eventmanager/src/EventManager.php(179): Zend\EventManager\EventManager->triggerListeners(Object(Zend\Mvc\MvcEvent), Object(Closure))
#8 /var/www/html/vendor/zendframework/zend-mvc/src/Controller/AbstractController.php(106): Zend\EventManager\EventManager->triggerEventUntil(Object(Closure), Object(Zend\Mvc\MvcEvent))
#9 /var/www/html/vendor/zendframework/zend-mvc/src/DispatchListener.php(138): Zend\Mvc\Controller\AbstractController->dispatch(Object(Zend\Http\PhpEnvironment\Request), Object(Zend\Http\PhpEnvironment\Response))
#10 /var/www/html/vendor/zendframework/zend-eventmanager/src/EventManager.php(322): Zend\Mvc\DispatchListener->onDispatch(Object(Zend\Mvc\MvcEvent))
#11 /var/www/html/vendor/zendframework/zend-eventmanager/src/EventManager.php(179): Zend\EventManager\EventManager->triggerListeners(Object(Zend\Mvc\MvcEvent), Object(Closure))
#12 /var/www/html/vendor/zendframework/zend-mvc/src/Application.php(332): Zend\EventManager\EventManager->triggerEventUntil(Object(Closure), Object(Zend\Mvc\MvcEvent))
#13 /var/www/html/index.php(21): Zend\Mvc\Application->run()
#14 {main}
#2

(They don’t all result in an error with the same Item ID, of course.)

#3

This is happening at what time, when trying to go to the show page (and if so, just as a direct link)? As what role of user (or not logged in)?

You’d get an error like this with “development” mode (error display turned on) just by going to the page for an item marked Private with a lower-role or anonymous user… it’s basically a verbose error explaining why a 404 error is occurring.

If that’s what’s happening, it shouldn’t really be an issue: any other “admin” level user, or the creator themselves, should be able to see, delete, or mark as Public the item(s) in question. If something else is going on, please provide additional details about the problem.

#4

This is happening when trying to edit the Item. Trying to delete (including Item’s creator and me [with Global Admin role]) just pops up the confirm sidebar with “Something went wrong.” Trying to add the Item to a Page as an Item with Metadata block throws no error, but doesn’t attach anything either.

#5

So, that indicates that there’s something going on wrong in between browse (which presumably correctly includes these problematic items) and show/edit/delete, which are being rejected.

The mechanism Omeka S uses to check permissions is actually exactly the same between those two places, so this shouldn’t be possible in the core. It could be for a module, possibly, or some other odd explanation. Deactivating modules to see if they are related could be a way to go, but I’m not personally aware of any that mess around in the permissions in such a way that would cause this kind of problem.

The system really isn’t set up to give you an escape hatch here, though: if global admins can’t read the item, then fixing the issue or database editing would be the only solutions.

#6

Well, blergh. :slight_smile:

These things happen, and I’ll see if I can’t find out the circumstances under which the Items got added. Maybe there’s an identifiable pattern.

#7

Dunno if this is what my colleague was doing, but I found a way to make the CSV Import module bork:

Omeka 1.4.0
CSV Import 2.0.0
CSV data and import settings JSON in https://yale.box.com/v/omeka-s-private-import-test

  • Import the CSV in that folder with the settings from that folder
  • The result should be a report of success and the appearance of the data as an Item
  • However, going to act on the item gives the stack trace above.

Caveat: The CSV is only one record (+headers), and I haven’t tested with multiple records.

#8

Sent too early. The key is that setting Visibility to Private seemed to be the trigger for the behavior. I haven’t tested on all variations, but that seems to be the sticking point. I may be unable to see interactions among settings that may be the true issue.

Happy to file this in GitHub if it’s better.

#9

You could file it at Github or leave it here.

It’s just setting visibility to private at all, or specifically through CSV Import, that’s causing the problem? Especially if it’s the former, I’m having the feeling this is a pretty installation-specific issue… it’s certainly not something I can reproduce, and setting visibility to private is such a common action, we’d have to be seeing it far more widespread, I think.

It’s possible it’s an issue with Omeka S 1.4 that’s since been fixed in 2.0 and up… but I don’t recall any reports along these lines from when the 1.x series was current, either.

#10

It was only through CSV Import that it was a problem. But just now I set up a fresh install of Omeka S 1.4.0 & CSV Import 2.0.0 on Reclaim and didn’t have the problem. I’ll move on to module conflict testing.

#11

Well this is fun. Couldn’t repro the problem on the fresh install, even adding modules in one by one. To boot, on the install where it was happening, it’s not happening now and the Items that were borking have miraculously unborked.

/me backs away slowly

#12

Hi all,

I’m experiencing a similar problem where, as a global admin (or any other user), I cannot access the items I’ve created where I have set the visibility to ‘private’.
Using version 2.1.0, but problem occurred with previous version as well. Just updated.

Omeka\Api\Exception\NotFoundException: Omeka\Entity\Item entity with criteria {“id”:“3152”} not found in /var/www/html/omeka-s/application/src/Api/Adapter/AbstractEntityAdapter.php:627
Stack trace:
#0 /var/www/html/omeka-s/application/src/Api/Adapter/AbstractEntityAdapter.php(354): Omeka\Api\Adapter\AbstractEntityAdapter->findEntity(Array, Object(Omeka\Api\Request))
#1 /var/www/html/omeka-s/application/src/Api/Manager.php(230): Omeka\Api\Adapter\AbstractEntityAdapter->read(Object(Omeka\Api\Request))
#2 /var/www/html/omeka-s/application/src/Api/Manager.php(115): Omeka\Api\Manager->execute(Object(Omeka\Api\Request))
#3 /var/www/html/omeka-s/application/src/Mvc/Controller/Plugin/Api.php(136): Omeka\Api\Manager->read(‘items’, ‘3152’, Array, Array)
#4 /var/www/html/omeka-s/application/src/Controller/Admin/ItemController.php(62): Omeka\Mvc\Controller\Plugin\Api->read(‘items’, ‘3152’)
#5 /var/www/html/omeka-s/vendor/zendframework/zend-mvc/src/Controller/AbstractActionController.php(78): Omeka\Controller\Admin\ItemController->showAction()
#6 /var/www/html/omeka-s/vendor/zendframework/zend-eventmanager/src/EventManager.php(322): Zend\Mvc\Controller\AbstractActionController->onDispatch(Object(Zend\Mvc\MvcEvent))
#7 /var/www/html/omeka-s/vendor/zendframework/zend-eventmanager/src/EventManager.php(179): Zend\EventManager\EventManager->triggerListeners(Object(Zend\Mvc\MvcEvent), Object(Closure))
#8 /var/www/html/omeka-s/vendor/zendframework/zend-mvc/src/Controller/AbstractController.php(106): Zend\EventManager\EventManager->triggerEventUntil(Object(Closure), Object(Zend\Mvc\MvcEvent))
#9 /var/www/html/omeka-s/vendor/zendframework/zend-mvc/src/DispatchListener.php(138): Zend\Mvc\Controller\AbstractController->dispatch(Object(Zend\Http\PhpEnvironment\Request), Object(Zend\Http\PhpEnvironment\Response))
#10 /var/www/html/omeka-s/vendor/zendframework/zend-eventmanager/src/EventManager.php(322): Zend\Mvc\DispatchListener->onDispatch(Object(Zend\Mvc\MvcEvent))
#11 /var/www/html/omeka-s/vendor/zendframework/zend-eventmanager/src/EventManager.php(179): Zend\EventManager\EventManager->triggerListeners(Object(Zend\Mvc\MvcEvent), Object(Closure))
#12 /var/www/html/omeka-s/vendor/zendframework/zend-mvc/src/Application.php(332): Zend\EventManager\EventManager->triggerEventUntil(Object(Closure), Object(Zend\Mvc\MvcEvent))
#13 /var/www/html/omeka-s/index.php(21): Zend\Mvc\Application->run()
#14 {main}

#13

Interesting… we never were able to reproduce the problem mentioned in this thread.

Since the issue just mysteriously disappeared in the previous report, I wonder if it could have been an issue of server-side caching or something along those lines. This is just a stab in the dark, but does restarting PHP-FPM and/or Apache change anything about your issue?

#14

Yes! apache restart did the trick.
Thanks for thinking about this.
T

#15

Well, that’s good to hear at least.

Maybe there’s something in common between these two servers that indicates why they’re uniquely experiencing this issue? Seeing the System Information page might be interesting in trying to track that down.

#16

On one hand, I don’t mind sharing our System Information page, but I’m wondering whether there’s a reason (not coming to mind) that putting that in public here is a problem. Or were you thinking of PMing it to you?

#17

I don’t think there is any issue sharing it.

A PM is fine as well, if you’re concerned, though.

#18

There is also a bug with the advanced search and Omeka 2.1. See the issue on github

#19

Apparently the same problem reoccurs after some time…
System information:

Omeka S
Version 2.1.0
PHP
Version 7.2.24-1+ubuntu16.04.1+deb.sury.org+1
SAPI apache2handler
Memory Limit 128M
POST Size Limit 8M
File Upload Limit 2M
Garbage Collection Yes
Extensions apache2handler, apcu, calendar, Core, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gettext, hash, iconv, imagick, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, Phar, posix, readline, Reflection, session, shmop, SimpleXML, sockets, sodium, SPL, standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, Zend OPcache, zlib
Disabled Functions , pcntl_alarm, pcntl_async_signals, pcntl_exec, pcntl_fork, pcntl_getpriority, pcntl_get_last_error, pcntl_setpriority, pcntl_signal, pcntl_signal_dispatch, pcntl_signal_get_handler, pcntl_sigprocmask, pcntl_sigtimedwait, pcntl_sigwaitinfo, pcntl_strerror, pcntl_wait, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifcontinued, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig
MySQL
Server Version 5.7.29-0ubuntu0.16.04.1
Client Version mysqlnd 5.0.12-dev - 20150407 - $Id: iguessthisshouldn’tbeshared $
Mode ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION
OS
Version Linux 4.4.0-170-generic x86_64

#20

@dan The issue you’re mentioning here isn’t related to this problem. The fix for that issue is done and should be released relatively soon.

@Tobias Thanks for sending the server information. Checking on a couple things:

  • You’re unable to access items that you yourself have set to private? If so, does this happen immediately upon creating them, or is there some delay?
  • When the problem reoccurs, is it happening to newly-created items only, or to the same private items as before?