Hi Ken,
Thanks for responding to my issue, but I'm afraid none of your suggestions worked!
I'll respond to both of your comments here to keep the responses concise.
-------------------------------------------------------------------------------------
Scopes show openid profile email
**** Add to those the following
URL:
https://www.googleapis.com/auth/drive
and the only way I have been able to get it to work with doc conversions is to have a system account.
Even if you are not using Google Authentication.
And path to ghostscript OK? Have you tested conversion of a .doc or whatever to .pdf using ghostscript from command line?
https://www.ghostscript.com/doc/current/Use.htm
-------------------------------------------------------------------------------------
The other Google Cloud Platform accounts do not have "
https://www.googleapis.com/auth/drive" added to the list of "Scopes for Google APIs" on the "Oauth Consent Screen", they only have the default "Email", "Profile", and "OpenID" attributes and their relevant Moodle LMSs do not have issues with converting non-PDF files to PDF via the AnnotatePDF function, so I fail to understand why I need to add this scope to fix this issue.
I have connected a system account to the Google OAuth 2 services within the Moodle platform (as per the first screenshot in my
OP with the connected system account's details redacted for privacy reasons. This was done in accordance with the two
Moodle Docs you mentioned at the time the Google integration was set up (ages before I created the OP).
Ghostscript works and the path is valid. However, we do not want to use Ghostscript due to its glaringly horrendous performance while under stress (our Moodle platform uses the AnnotatePDF function frequently, and we noticed that Ghostscript was not able to keep up the pace to suit demand). Path to Ghostscript is irrelevant, as the whole point of using Google's API is to use Google Drive converter as an alternative to the Ghostscript service.
-------------------------------------------------------------------------------------
and a follow up ...
https://docs.moodle.org/38/en/Google_Drive_converter
https://docs.moodle.org/38/en/OAuth_2_Google_service
and the section on app verification ...
where one sets up credentials
privacy policy url and terms of service url
Those pages I'd suggest making statically if your entity
doesn't already have them.
Google, like every service provider like them, ups the bar from time to time and really doesn't notify users (at least I've not found something to subscribe to that does).
Also, when users first access google via your Moodle they will or should be prompted with a permissions screen where the service account set up for this is given access to files ... wish they phrased that differently ... might warn users service account cannot be used to hack their stuff/edit files/upload files, etc. Service account is sort of a 'pass through' and exist so there is some accountabiliy.
If your entity has also a Google for Schools domain might x-check about things in there admin of that might have to allow all users to do, etc.
-------------------------------------------------------------------------------------
I have followed the Google Drive converter and Google Oauth 2 setup as per the articles you refer to when setting up this account and other accounts (I am very familiar with them, especially over the last few months), but the issue still persists in this single Moodle LMS, despite even moving it to another Google Cloud Platform account that manages other Moodle LMSs of a similar version (all v3 and higher), and it continues to be the only Moodle LMS that experiences this issue converting files to PDF.
We don't have any privacy policy or ToS URLs configured, as the articles you mentioned does not require it. We do not have these configured in any other Google Cloud Platform account, so they are also not needed here. Therefore, the issue is not with my Google Cloud Platform configurations, but with the Moodle LMS itself, thus my delve into the PHP errors in my last post.
I have looked at the problematic account today for the first time since Christmas, and I have noticed it was called successfully 44 times, but I continue to experience the same non-converting issue mentioned in my OP, both with existing assignment submissions (test ones dating back to September 2019) and test attempts conducted today.
