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

multiupload bypasses the asynchronous publisher

    Details

      Description

      using the multiupload button to publish new objects does not trigger the asynchronous publisher.

      test:

      • enable the async cript from the command line
      • on frontend, log in to enable the toolbar
      • create a new gallery
      • async script shows the "processing item" message
      • navigate to the test gallery
      • click on the multiupload button and upload some files
      • all objects are published as gallery's children, but the asun script is not triggered.

        Issue Links

          Activity

          Hide
          Bertrand Dunogier added a comment -
          Show
          Bertrand Dunogier added a comment - Pull-request https://github.com/ezsystems/ezmultiupload/pull/11 .
          Show
          Bertrand Dunogier added a comment - https://github.com/ezsystems/ezmultiupload/pull/11 merged to master@6e93798f . BC note documented in https://github.com/ezsystems/ezpublish-legacy/pull/941 and merged to master.
          Hide
          Bertrand Dunogier added a comment -

          @doc the BC break should be mentioned in upgrade docs, right ?

          Show
          Bertrand Dunogier added a comment - @doc the BC break should be mentioned in upgrade docs, right ?
          Hide
          Pedro Resende (Inactive) added a comment - - edited

          Bertrand Dunogier:I'm having a strange behaviour, if I stop the asynchronous publisher daemon and try to upload content using mutiupload apparently I get the message that all the files are received.
          Shouldn't there be a message informing that the content couldn't not be sent ? I'm asking this since there is no way to know that the daemon is dead.

          Show
          Pedro Resende (Inactive) added a comment - - edited Bertrand Dunogier :I'm having a strange behaviour, if I stop the asynchronous publisher daemon and try to upload content using mutiupload apparently I get the message that all the files are received. Shouldn't there be a message informing that the content couldn't not be sent ? I'm asking this since there is no way to know that the daemon is dead.
          Hide
          Bertrand Dunogier added a comment -

          Well, that's the decision we made. We assume that the daemon will be done publishing shortly after the upload, which makes no difference to the user.

          Show
          Bertrand Dunogier added a comment - Well, that's the decision we made. We assume that the daemon will be done publishing shortly after the upload, which makes no difference to the user.
          Hide
          Bertrand Dunogier added a comment -

          And to clarify: the fact that the daemon's dead doesn't mean content wasn't sent. It means it wasn't published. When the daemon is restarted, content will be published.

          Remember how this was before this patch:

          • content wasn't published asynchronously at all
          • content ran through an interrupted workflow (approval, etc) wouldn't be previewed at all by the multiupload interface

          So yes, it isn't perfect, but it's meant to be a bugfix, not a major improvement.

          Do we agree ?

          Show
          Bertrand Dunogier added a comment - And to clarify: the fact that the daemon's dead doesn't mean content wasn't sent. It means it wasn't published . When the daemon is restarted, content will be published. Remember how this was before this patch: content wasn't published asynchronously at all content ran through an interrupted workflow (approval, etc) wouldn't be previewed at all by the multiupload interface So yes, it isn't perfect, but it's meant to be a bugfix, not a major improvement. Do we agree ?
          Hide
          Bertrand Dunogier added a comment -

          The problem is just an EOL in the .override.ini file. patch -l works fine, no problem here, and we won't repatch.

          Show
          Bertrand Dunogier added a comment - The problem is just an EOL in the .override.ini file. patch -l works fine, no problem here, and we won't repatch.
          Hide
          Pedro Resende (Inactive) added a comment -

          Tested and approved by Q.A.

          Show
          Pedro Resende (Inactive) added a comment - Tested and approved by Q.A.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Time Spent - 1 day, 4 hours Remaining Estimate - 3 hours
                3h
                Logged:
                Time Spent - 1 day, 4 hours Remaining Estimate - 3 hours
                1d 4h