Can't add part
Describe the bug Can't add Part
To Reproduce Add category Add part to category Expected behavior Part is added.
Screenshots If applicable, add screenshots to help explain your problem.
Server Side Docker container
Doctrine\ORM\ORMInvalidArgumentException:
Entity has no identity, therefore scheduling for update cannot be performed. TC2164-3.3VDBTR
at vendor/doctrine/orm/lib/Doctrine/ORM/ORMInvalidArgumentException.php:153
at Doctrine\ORM\ORMInvalidArgumentException::entityHasNoIdentity(object(Part), 'scheduling for update')
(vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1402)
at Doctrine\ORM\UnitOfWork->scheduleForUpdate(object(Part))
(src/Security/EntityListeners/ElementPermissionListener.php:175)
at App\Security\EntityListeners\ElementPermissionListener->preFlushHandler(object(Part), object(PreFlushEventArgs))
(vendor/doctrine/orm/lib/Doctrine/ORM/Event/ListenersInvoker.php:94)
at Doctrine\ORM\Event\ListenersInvoker->invoke(object(ClassMetadata), 'preFlush', object(Part), object(PreFlushEventArgs), 1)
(vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:661)
at Doctrine\ORM\UnitOfWork->computeChangeSet(object(ClassMetadata), object(Part))
(vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:525)
at Doctrine\ORM\UnitOfWork->computeScheduleInsertsChangeSets()
(vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:845)
at Doctrine\ORM\UnitOfWork->computeChangeSets()
(src/EventSubscriber/LogSystem/EventLoggerSubscriber.php:139)
at App\EventSubscriber\LogSystem\EventLoggerSubscriber->onFlush(object(OnFlushEventArgs))
(vendor/symfony/doctrine-bridge/ContainerAwareEventManager.php:68)
at Symfony\Bridge\Doctrine\ContainerAwareEventManager->dispatchEvent('onFlush', object(OnFlushEventArgs))
(vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:3473)
at Doctrine\ORM\UnitOfWork->dispatchOnFlushEvent()
(vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:399)
at Doctrine\ORM\UnitOfWork->commit(null)
(vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:398)
at Doctrine\ORM\EntityManager->flush(null)
(var/cache/demo/ContainerWFjhUkO/EntityManager_9a5be93.php:137)
at ContainerWFjhUkO\EntityManager_9a5be93->flush()
(src/Controller/PartController.php:300)
at App\Controller\PartController->new(object(Request), object(EntityManager_9a5be93), object(Translator), object(AttachmentSubmitHandler), null)
(vendor/symfony/http-kernel/HttpKernel.php:152)
at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), 1)
(vendor/symfony/http-kernel/HttpKernel.php:74)
at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), 1, true)
(vendor/symfony/http-kernel/Kernel.php:202)
at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
(vendor/symfony/runtime/Runner/Symfony/HttpKernelRunner.php:35)
at Symfony\Component\Runtime\Runner\Symfony\HttpKernelRunner->run()
(vendor/autoload_runtime.php:35)
at require_once('/var/www/html/vendor/autoload_runtime.php')
(public/index.php:5)
Gave myself full permissions - this problem existed. Put myself in the admin group, problem solved.
Hmm, in Principle it should not make a difference from where you get the permissions (and the direct permissions of a user have higher priority than group perms).
As the whole issue seems to be a permission problem, i have an idea where this is coming from: Part-DB is currently doing some ugly things during hydration and dehydration of database data. If a user does not have full permissions, the created entity get detached from the doctrine IdentyMap (and should later in theory be reattached), which causes your original problem.
This whole procedure is pretty unsupported by doctrine and causes many problems (and it kills performance for long part tables). My goal is to rework the permission system to a better solution, soon.
After the big changes to the permission system, this should not happen anymore.