Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-21565

Workflow: restore object will cause fatal error

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: High High
    • Resolution: Duplicate
    • Affects Version/s: 5.0, 5.1
    • Fix Version/s: Customer request
    • Component/s: Legacy > Workflows
    • Labels:
      None
    • Environment:

      ezp with approval workflow created

      Description

      steps to reproduce:
      user A is editor and user B is approver.

      1 - setup an approval workflow
      2 - create and publish a content with user A
      3 - approve content with user B
      4 - remove content with user A - send to trash
      5 - restore content ( use original location) - fatal error is generated

      the error shows that:
      eZ runs publication operation when restoring (restore.php line 177)
      this publish triggerss the approval event, the content is not published and the main_node_id (line 192) is empty.
      eZ then tries to redirect to /content/view/full without any parameter ==> error page

        Issue Links

          Activity

          Hide
          Paulo Bras (Inactive) added a comment - - edited

          Hi Jérome,

          i was looking at just this one. the workflows are already handled, it's just the redirection that is being overriden.

          i took the code in kernel/content/restore.php:

              if ( ( array_key_exists( 'status', $operationResult ) && $operationResult['status'] != eZModuleOperationInfo::STATUS_CONTINUE ) )
              {
                  switch( $operationResult['status'] )
                  {
                      case eZModuleOperationInfo::STATUS_HALTED:
                      case eZModuleOperationInfo::STATUS_CANCELLED:
                      {
                          $module->redirectToView( 'trash' );
                      }
                  }
              }
          

          and just slapped it after the db->commit(), like this:

              if ( ( array_key_exists( 'status', $operationResult ) && $operationResult['status'] != eZModuleOperationInfo::STATUS_CONTINUE ) )
              {
                  switch( $operationResult['status'] )
                  {
                      case eZModuleOperationInfo::STATUS_HALTED:
                      case eZModuleOperationInfo::STATUS_CANCELLED:
                      {
                          $module->redirectToView( 'trash' );
                      }
                  }
              }
              else 
              {
                  $module->redirectToView( 'view', array( 'full', $mainNodeID ) );
              }
          

          i think the original writer wanted something like a module->redirect, commit, return sequence, but the last two bits got lost. as it is now, the whole if((array_key_exists... is useless, since that module redirection is always sent to space

          Show
          Paulo Bras (Inactive) added a comment - - edited Hi Jérome, i was looking at just this one. the workflows are already handled, it's just the redirection that is being overriden. i took the code in kernel/content/restore.php: if ( ( array_key_exists( 'status', $operationResult ) && $operationResult['status'] != eZModuleOperationInfo::STATUS_CONTINUE ) ) { switch( $operationResult['status'] ) { case eZModuleOperationInfo::STATUS_HALTED: case eZModuleOperationInfo::STATUS_CANCELLED: { $module->redirectToView( 'trash' ); } } } and just slapped it after the db->commit(), like this: if ( ( array_key_exists( 'status', $operationResult ) && $operationResult['status'] != eZModuleOperationInfo::STATUS_CONTINUE ) ) { switch( $operationResult['status'] ) { case eZModuleOperationInfo::STATUS_HALTED: case eZModuleOperationInfo::STATUS_CANCELLED: { $module->redirectToView( 'trash' ); } } } else { $module->redirectToView( 'view', array( 'full', $mainNodeID ) ); } i think the original writer wanted something like a module->redirect, commit, return sequence, but the last two bits got lost. as it is now, the whole if((array_key_exists... is useless, since that module redirection is always sent to space
          Hide
          Jérôme Vieilledent (Inactive) added a comment -

          That might do the trick indeed. I'll try and do the PR.
          Thanks for the hint!

          Show
          Jérôme Vieilledent (Inactive) added a comment - That might do the trick indeed. I'll try and do the PR. Thanks for the hint!
          Hide
          Jérôme Vieilledent (Inactive) added a comment -

          Actually it is not. The reason is that we have exactly the same problem than for EZP-20558, so the fix will be similar.

          Show
          Jérôme Vieilledent (Inactive) added a comment - Actually it is not. The reason is that we have exactly the same problem than for EZP-20558 , so the fix will be similar.
          Show
          Jérôme Vieilledent (Inactive) added a comment - PR: https://github.com/ezsystems/ezpublish-legacy/pull/763
          Hide
          Jérôme Vieilledent (Inactive) added a comment - - edited

          New PR: https://github.com/ezsystems/ezpublish-legacy/pull/767
          Much better approach by Bertrand Dunogier, which fixes the issue at root.

          Show
          Jérôme Vieilledent (Inactive) added a comment - - edited New PR: https://github.com/ezsystems/ezpublish-legacy/pull/767 Much better approach by Bertrand Dunogier , which fixes the issue at root.
          Hide
          Bertrand Dunogier added a comment -
          Show
          Bertrand Dunogier added a comment - Fixed in https://jira.ez.no/browse/EZP-21599 .

            People

            • Assignee:
              Unassigned
              Reporter:
              Paulo Bras (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: