How to debug a workflow?

Hi everyone! I am using NextCloud 19, with all apps updated.

The primary use we give the system is to allow users to connect to shared resources in samba.

I am interested in using the workflow, but there is very little documentation that I found. Specifically, my idea was to give users the possibility to identify the documents, and that the nextcloud convert them to pdf.

For this purpose I installed the “Automated PDF conversion” app. At the same time, I have the libreoffice installed and running. That I tested locally, from the console, without a graphical interface, and I can convert the documents to PDF.

Thanks to this, I can now create a flow with the plugin. However, it does not work, and does not generate any log.

Basically the same thing happens to me to all those who have reported N bugs of the same in the app’s github.


Specifically, does anyone have this working? Does it really work?

Tnxs in advance.

1 Like

Hi,

Can you show your rule set for the PDF conversion here?
In case used rely on Tags für the conversion, please also verify the correct Tags are assigned to the files you wish to automatically convert to PDF.

Same issue for me. I tried with an other flow like sending messages in talk for a specific tag and it work fine.

On a old installation of Nextcloud upgraded to 18, there is a log showing this

I investigated and found nothing other that configuring the preview_libreoffice_path with the one on the sample config file. The only thing that this does it just simply remove the error from the logs but nothing happends.

I also tried on a new installation of Nextclout 19 on docker and the talk flow works well, but no logs and nothing is happening for the PDF conversion.

Hi @vinid223

Could you please show your rule set for the PDF conversion?
A screenshot will do.

Here it is

image

The rule set looks good actually.
So you have the config.php entry like:

'preview_libreoffice_path' => '/usr/bin/libreoffice',

and the binary given in that parameter is existing?

When you configured that config.php parameter, did you change the original docx file in any way, like “update” or “rename” (as this is part of the rule set)?

Hello @Schmu,

Yes the entry is well configured. I had to install the libreoffice binary into the docker image to have it and it is well installed. I can also use the “libreoffice” command anywhere in the image since it is configured to run in the path.

I did change the docx file a lot of time to test each changes I could have done. Even restart the docker container for nextcloud. I might add that I am using Linuxserver.io image for my nextcloud installation, but the issue is still the same with the official Nextcloud image when I did my testings.

I’ve configures a flow to send messages to Talk to be sure that the flow cron updates did actually worked to be sure I didn’t messed with this feature. It did sent a message into a conversation each time I did something that fits the creteria of the PDF converter, which I copied into my other flow for talk message.

I was also curisous to find if it was something else I have done with my installation so I’ve looked at the source code for the extension to convert to PDF and here is what I found.

The extension code should be able to detect my libreoffice installation in this method https://github.com/nextcloud/workflow_pdf_converter/blob/6951eb123e0618b125c2aba1f15791345ae2d41e/lib/BackgroundJobs/Convert.php#L130

The first step check if the configuration you have specified is documented which I have, but by default it is not. So normally, the next step check for the binary location with the command shell_exec('command -v libreoffice'); on line 136 of the Convert.php file in the BackgroundJobs folder of the lib directory.

It seems that the shell_exec just doesn’t work well in PHP in the docker installation. When I manually run the command command -v libreoffice in the bash of the docker image, I just want to add that I did try that in the Linuxserver.io image as well as in the official Nextcloud image, the command did return the /usr/bin/libreoffice path to the binary (more like a symlink to the binary) of libreoffice.

So I don’t know what the issue is really. Is it because the /usr/bin/libreoffice is a symlink to a binary of the libreoffice installation inside the container? Is it because it is inside a docker container and there is something wrong between PHP shell_exec command and the docker environment?

Thats why I just went into the help forums. I can find a lot of issues all around for that feature simply not working. Even on the github repo there is issues for that problem, but not updates for a long time.

If you need more details, I will be happy to help.

It is really easy to replecate to be honest. Simply use a new instance of Nextcloud 18 or 19 docker image and add the app and it just doesn’t work at all.

Thanks you for your time.

vinid223.

Hello @Schmu ,

I wanted to go further to do some more testing to prove the thing is not working. Here is what I did.

Setup:

  • Virtual Machine with Ubuntu server 20.04
  • Installed Nextcloud 19.0 with snap
  • Installed Libreoffice (tested the command command -v libreoffice to check the path returned and it did return the right path
  • Installed the PDF Conversion APPS image
  • Did the following configuration
  • Installed the collabora core and apps to help me edit a docx file

When I update a file, the talk message is well received

But when I check to see if there is a PDF generated, nothing is happening. I looked at the logs and this is what is returned.

After looking again at the source code, it might just be the shell_exec that always return a non 0 return code and never continues the save process. This might be the reason the array of reason is empty. I could debug the code, but I don’t really want to go that deep since I can reproduce the error with a fresh install of Nexcloud on docker or in a VM.

Hope this helps.

Let me know of any updates and if you need anything else just keep me posted.

Vinid223.

@Schmu

Any updates?

Hi @vinid223

I can’t help unfortunately. I tried to get automatic PDF creation to work when the new workflow was released (18.0.4 I think). After trying everything I stopped and first tried again after the update 18.0.5.
I noticed a logical mistake in my rule set which happened when I just tried everything in the first place and when I fixed it, suddenly PDF creation worked. I thought it was the update solving the problem and though maybe someone else put a mistake in the rule set.
Your rules are good though and when I check my server again to compare your findings with my system I noticed, that PDF creation didn’t work anymore.

I haven’t changed anything except the update to 18.0.6 and system updates, but nothing more.
I’m stuck again, just like you are :frowning:
And you already dig deeper than I did.
Could you maybe update the Github issue and provide your findings to the developers? They don’t read the threads here and it seems the community cannot help at this point here.