Item(s) Not Found

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}

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

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.

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.

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.

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.

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

  • 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.

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.

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.

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.

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