Upgrade to RAML Module Builder 33.x

I've made the changes you suggested and that seems to have fixed all of the failing tests. Thank you.

It's confusing but yes, you are right it makes a request to users API. folio-custom-fields is an extension that could be included in any module and it requires user info for its work. Maybe there is could be some improvement done to remove this strange dependency but I don't think that this is a problem.

I don't think this is the cause of the issue. I was surprised that a library makes requests to an API without any indication that it is doing so. That was why I remarked upon it. And that we've had challenges with this kind of self-referential requests before (I think made changes to Okapi to help improve that).

About tests. You should replace x-okapi-token header with x-okapi-user-id header. Previously we got user-id from JWT token, but the okapi team tells are that it is a bad decision and we should use the user-id header instead.

Thank you for sharing that change with me. It's unfortunate that this change was made along with the RMB upgrade at the end of the development period for a release. Did this come up during that upgrade work?

Given that folks knew about this change and that mod-users needed to upgrade this library it could've been helpful for the team that did this work to either investigate the impact or inform the team expected to do the work about it.

Hey .

It's confusing but yes, you are right it makes a request to users API. folio-custom-fields is an extension that could be included in any module and it requires user info for its work. Maybe there is could be some improvement done to remove this strange dependency but I don't think that this is a problem.

About tests. You should replace x-okapi-token header with x-okapi-user-id header. Previously we got user-id from JWT token, but the okapi team tells are that it is a bad decision and we should use the user-id header instead.

Could it be down to this code which, if I'm understanding it correctly, will fail if the User ID header is not present (which is likely the case for the tests given it is generated by Okapi which isn't present)

Did this code change during the recent work?

Thank you for upgrading folio-custom-fields to RMB 33.0.0 (and vert.x 4.1.0.CR1). I've upgraded mod-users to use folio-custom-fields 1.5.3-SNAPSHOT as I believe that is the build these changes are included in.

Unfortunately, some of the tests relating to custom fields still fail and I'm hoping you can help me out.

As an example, when I execute CustomFieldsRemovalTest.shouldRemoveFieldIfNotAssignedToUser it fails reporting an unexpected 401 status code in the first step.

The test produces the following stack trace:

If I'm understanding this correctly, this is making a request to the users API whilst saving the custom fields. Am I following this correctly? Meaning that mod-users has a dependency on itself?