Upgrading to Liferay 7.4 has caused existing code that called the JSONWS add-user-with-workflow call to fail

We just upgraded from Liferay CE 7.3 to Liferay CE 7.4 and now find that an app that calls the add-user-with-workflow is failing. The Liferay log did not provide error details, nor were there any in the response body. The call is made from a Java HTTP Client, and here is the URL it calls from a test execution (captured by logging just before the call):

https://[hostname]/api/jsonws/user/add-user-with-workflow?
companyId=10157&
autoPassword=true&
-password1=&
-password2=&
autoScreenName=true&
-screenName=&
emailAddress=liferay.api.prod10%40mcintoshes.com&
-locale=&
firstName=Scott&
-middleName=&
lastName=McIntosh&
prefixId=0&
suffixId=0&
male=true&
birthdayMonth=0&
birthdayDay=0&
birthdayYear=0&
jobTitle=%7B%22isBatch%22%3A%22true%22%7D&
-groupIds=&
organizationIds=77377&
-roleIds=&
-userGroupIds=&
sendEmail=true

This is actual URL from the log, except the hostname is removed and I broke the parameters into separate lines to make it easier to read.

I then took this a ran it using Postman, and got the following response.

{
    "exception": "No JSON web service action with path /user/add-user-with-workflow and method GET for null",
    "throwable": "com.liferay.portal.kernel.jsonwebservice.NoSuchJSONWebServiceException: No JSON web service action with path /user/add-user-with-workflow and method GET for null",
    "error": {
        "message": "No JSON web service action with path /user/add-user-with-workflow and method GET for null",
        "type": "com.liferay.portal.kernel.jsonwebservice.NoSuchJSONWebServiceException"
    }
}

I checked and a service with these parameters still exists (looking at the services in the /api/jsonws UI).

Using POST instead of GET makes no difference.

Can anyone shed any light on this or have the same experience?
Perhaps the -parameter syntax to denote a null value is no longer supported?
As I stated in the beginning, this works perfectly in Liferay 7.3.

Update:
There is also an API call performed to get a user from their email address. This call's parameters seem OK as it doesn't throw a "No JSON Web Service" error, but instead throws an access denied error:

{
    "exception": "Access denied to com.liferay.portal.kernel.service.UserService#getUserIdByEmailAddress",
    "throwable": "java.lang.SecurityException: Access denied to com.liferay.portal.kernel.service.UserService#getUserIdByEmailAddress",
    "error": {
        "message": "Access denied to com.liferay.portal.kernel.service.UserService#getUserIdByEmailAddress",
        "type": "java.lang.SecurityException"
    }
}

So now I'm wondering if something more fundamental is wrong. So I started checking, and found the Service Access Policy section in the admin console. There are two entries, SYSTEM_DEFAULT and SYSTEM_USER_PASSWORD. SYSTEM_DEFAULT is set to allow getCountries and getRegions - and indeed when I test those they do work (they're the only calls to work so far). SYSTEM_USER_PASSWORD is set with * for 'Service Class' containing * and 'Method Name' is blank. This indicated that authenticated users should have access to all services.

I'm sure it's not an issue passing credentials, as the service testing UI at api/jsonws doesn't work either (other than for getCountries and getRegions). It doesn't return an error, it just returns "{}" for every service method I try. Yes, I'm logged in when using the service tester.

Is there a new portal property in 7.4 that I'm missing?

Solution

You might want to try if this problem appears on a new installation as well. I've seen LPS-159746, which is in a different context, but requires to configure API access in upgraded systems.

As you already mention the /api/jsonws API browser: That would be the ideal place to check if the API access is configured correctly. Once you've configured API access: Please validate if you're sending all parameters that are required (I'm not sure if newer versions added extra parameters)