[Michael Blyckaerts]

Hello,
I try to develop a cloudapp which would allow our librarians to import data from an API to fill automatically the “register new user” form with conform data for our organization.

For this purpose, I firtsly tried to modify directly the form “register new user” by interract with javascript getElementById from the cloudapp, but I wasn’t able to access the DOM of alma from the cloudapp.

It seems to be a limitation of angular and the webworker.

So, I decided to use another approch. To rebuild a part of the form in the cloudapp and to write the data in alma with a Post call on the alma API.

My form is ok, my Get calls to the organisation API for the data’s are ok, but…
I’m not able to perform the Post call to alma.
I tried a Get call to alma, and it’s working, so it’s only the Post.
When I try it, I receive an unauthorized error.

I have the feeling that it is because it works only on read-only mode like with the guest sandbox, and not on read/write mode like in our sandbox or production.

For information, I’m using the CloudAppRestService.

So, my questions are :
– How to test my Post call with cloudAppRestService if it doesn’t work in localhost ? Because I need to be sure it’s work before sending it to validation and prod.
– Is it possible to change this read-only mode to read-write
– If yes, it would write on the production env, or the sandbox env ? (I would prefer on the sandbox to perform some tests)
– or maybe am I wrong and it’s depending of users access (but with the access and permissions of this user, I am able to manually register a new user, so I guess it should work also with the cloudAppRestService)

I hope you’ll be able help me,
Have a nice day 🙂

[Jørgen Jegsen]

Hi Michael.

My experience is, that Posts works perfectly fine.

Running the Cloud App from a local environment will affect the sandbox.

If you have access rights to the API console, you might be able to check the call from there?

/Jorgen

• This reply was modified 1 month, 2 weeks ago by Jørgen Jegsen.

[Michael Blyckaerts]

Hi, thank you for your answer !

The api console help to test calls with api’s key, if I understand it well.

And I would like to use the cloudAppRestService which works without them.
This service is based on the permissions of the user.
( https://developers.exlibrisgroup.com/cloudapps/docs/api/rest-service/ )

[Michael Blyckaerts]

To be sure, I tried the post call for user in the api console, like you suggest, with a key allowing permission read/write on users for sandbox, and this is the result :

Code Details
400 Error: Bad Request
Response headers
connection: close
content-encoding: gzip
content-length: 598
content-type: application/octet-stream;charset=UTF-8
date: Thu, 25 Feb 2021 08:41:01 GMT
p3p: CP=”IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT”
server: Apache/2.4.6 (CentOS) PHP/7.4.9
x-exl-api-remaining: 99307
x-powered-by: PHP/7.4.9 ”

Alas, I don’t understand this error. :/

The is also this on the top of the api console page :

Resolver error at paths./almaws/v1/users.post.requestBody.content.application/json.schema.properties.researcher.properties.user_identifiers.$ref
Could not resolve reference: Not Found
Resolver error at paths./almaws/v1/users.post.requestBody.content.application/xml.schema.properties.researcher.properties.user_identifiers.$ref
Could not resolve reference: Not Found
Resolver error at paths./almaws/v1/users.post.responses.200.content.application/json.schema.properties.researcher.properties.user_identifiers.$ref
Could not resolve reference: Not Found
Resolver error at paths./almaws/v1/users.post.responses.200.content.application/xml.schema.properties.researcher.properties.user_identifiers.$ref
Could not resolve reference: Not Found
Resolver error at paths./almaws/v1/users/{user_id}.get.responses.200.content.application/json.schema.properties.researcher.properties.user_identifiers.$ref
Could not resolve reference: Not Found

It is a bit confusing… :/

[Josh Weisman]

Hi Michael and Jørgen. You’re right that API requests made in Cloud Apps are in the context of the logged-in user. So there is no API key involved. The 401 means that the logged in user doesn’t have rights to create a user.

To create users, you need one of the following roles:
* General Administrator
* User Administrator
* User Manager Full

To update users,
* User Administrator
* User Manager Full
* General Administrator
* Circulation Desk Manager
* Circulation Desk Operator
* Repository Manager

I understand that the logged-in user is able to create users in the Alma interface. Which user were you trying to create a user with?

And thanks for the note on the error in the Console- we’ll definitely take a look at that.

Thanks.

[Michael Blyckaerts]

Hi, thanks for your reactivity,

I tried with the user “utest” which only have “Circulation Desk Operator” and “patron” role.

Manually, he can pass by fulfillment > manage patron service > register new user to create a user.

But, if I understand, with restService, he can’t create an user because he doesn’t have one of theses role :
* General Administrator
* User Administrator
* User Manager Full

So, why “circulation desk operator” is enough manually, and not with restService ?

[Michael Blyckaerts]

I made a test by giving “user manager” role to user “utest2”, and the call with restService work perfectly, indeed.

But, the librarians for which we are making this cloudapp don’t have this role.
They need to be able to create users (the clients of the library), but they don’t have to manage theirs roles.

So, how can I do ? 🙂

[Josh Weisman]

Thanks for your question and your confirmation that it works well with the listed roles. We’ll confirm that the circulation operator and manager can create new users, and if so we can add those roles to the API. In the meantime you should be able to develop by testing with a user with the listed roles.

[Josh Weisman]

Hi Michael. We’ve consulted with our team and it seems that the ability for a circulation operator to create new users is limited in the Alma user interface, while in the API it is unlimited. That makes it difficult to enable that role for that create user API without implementing similar restrictions in the API.

There are other work-arounds that we can suggest, such as providing an external REST service for your Cloud App to call which does the user creation, even if the logged-in user doesn’t have the required role. If this would be relevant we can provide some more guidance here.

We appreciate your feedback and will try to accommodate your use case as much as possible.

[Michael Blyckaerts]

Hello Josh, thank you for your investigations. 🙂

And, about the way of working of the API, could you tell me if you figure to change this and make it evolve for something more flexible in the future ? For this kind of use case ?

As a workaround, I could make a form in “configuration” where I could enter the url and the api key for a post call to alma ?
Next, I could add a condition in the cloudapp to check if the user is a desk operator and only allow it for them.

If it seems a good workaround for you, could you tell me the number for this role ? Or maybe tell me where I could find this information ?

And could you tell me a bit more about the solution you suggest, i would like to evaluate the differents possibilities.

Have a nice day,

[Jørgen Jegsen]

A part of the solution might be to whitelist (a number of) users with create rights in configurations, and then show/hide the create functionality according to this…

• This reply was modified 1 month, 1 week ago by Jørgen Jegsen.
• This reply was modified 1 month, 1 week ago by Jørgen Jegsen.
• This reply was modified 1 month, 1 week ago by Jørgen Jegsen.

[Josh Weisman]

Thanks for your questions and suggestions. Do to the complexities and restrictions involved, I’m not sure we can add user creation to roles other than user User Manager/Administrator in the future. Role IDs can change per environment so I suggest you retrieve a user record to confirm. But in my environment they are:
21- User Manager
50- User Administrator

I would recommend against storing an API key in Configuration, as it would be viewable in Developer Tools when a request is made from the Cloud App. My suggestion is to use an external proxy to make the API call for restricted users. A blog post which shows a possible implementation is available here:
https://developers.exlibrisgroup.com/blog/cloud-apps-retrieving-data-from-other-institutions/

Your scenario is simpler as you can hard code the API key for a single institution in your proxy environment.

Hope this is helpful.

[Michael Blyckaerts]

Thank you for your suggestion. 🙂
We’ll think about what is the more convenient for us.

I think it’s a bit unfortunate that the restService doesn’t allow this use case.

And could you tell me how to process to find the number associated to a role ? Or maybe tell me the number associated to “circulation desk operator” and “circulation desk manager” ?

Have a nice day 😉

[Josh Weisman]

Hi Michael. If you call the retrieve user API for a user record who has those roles, you can view the roles in the API response, for example (Circulation Desk Operator = 32, Circulation Desk Manager = 221):

{
"status": {
"value": "INACTIVE",
"desc": "Inactive"
},
"scope": {
"value": null,
"desc": null
},
"role_type": {
"value": "32",
"desc": "Circulation Desk Operator"
},
"parameter": []
},
{
"status": {
"value": "INACTIVE",
"desc": "Inactive"
},
"scope": {
"value": null,
"desc": null
},
"role_type": {
"value": "221",
"desc": "Circulation Desk Manager"
},
"parameter": []
},

[Michael Blyckaerts]

Thank you for your help, and have a nice day 🙂

[Author]

Posts