IBX-11038: Content rendering in BO fails after deleting user that created the content#1796
IBX-11038: Content rendering in BO fails after deleting user that created the content#1796
Conversation
ibexa-workflow-automation-1
bot
requested review from
Steveb-p,
ViniTou,
adamwojs,
alongosz,
barw4,
ciastektk,
konradoboza,
mikadamczyk,
tbialcz and
wiewiurdp
and removed request for
a team
|
| { | ||
| $parameters['creator'] = null; | ||
| $ownerId = $contentInfo->getOwner()->getUserId(); | ||
| $ownerId = $contentInfo->ownerId; |
There was a problem hiding this comment.
Did you figure out why is it different than getOwner()->getUserId()? We avoid magic whenever possible and that was also the intention behind this change. //POV ping @alongosz.
There was a problem hiding this comment.
No I didn't dig too deep, just saw we have used $contentInfo->ownerId and we don't have a getter for the ownerId either so I have just reverted to this.
There was a problem hiding this comment.
This supposed to be an equivalent, that's why I ask. I will let Andrew give his cents though.
There was a problem hiding this comment.
Should we even put userId for deleted user here? I would say that we should revert back to getOwner() (its probably not populated due to missing user object, and ownerId is just int thats still stored in db) and just handle gracefully not existing user.
Does that alsmo kmeans that typehint at \Ibexa\Contracts\Core\Repository\Values\Content\ContentInfo::$owner
protected User $owner;
is wrong?
|
|
Since playing around initializing the lazy proxy didn't quite work out I decided to use try catch for the problematic user |
| $ownerId = $contentInfo->getOwner()->getUserId(); | ||
|
|
||
| try { | ||
| $ownerId = $contentInfo->getOwner()->getUserId(); |
There was a problem hiding this comment.
for me, this is not proper solution - there is no information for end users that simple get can cover proxy object and throw not found exception.
As said, this whole fix should be about adding nullable owner for contentInfo, and handling that case.
This way, you only fixed in in one place, and we dont even know how many getOwner() are scattered around our codebase and our partners.
5 participants
Description:
This is a regression coming from #1697
authorinVersionInfomust be nullable so we can still display content of some deleted user.I have also reverted in
AuthorsTabretrievingownerIdto be directly accessed fromcontentInfoinstead of quering the owner as it might be no longer in the database.