Maybe someone knows and can help me with the following error:
When trying to edit a client from the list (Oauth Manager), different from the first, the edit form always shows the first one in the list.
I encountered the same issue while editing existing clients.
It seems this does not happen when using the 'admin' user, only for other users.
Thanks!But In my case, it happens with any user.Regards,
Never see that, what's version of OTK?
May be try to clear the cache of the browser?
The versión is OTK 4.0.00.2339
...and isn´t a caches problem!
I cannot reproduce the problem on OTK4.0, please open a support ticket to check further.
I have already created it before consulting this community... (01084399)
I'm also facing the same problem, it always shows the first client when trying to edit. Is it resolved in your case? Could you please let me know if there is any update
I reviewed the case 01084399, it seems the root cause is due to the current login user doesn't have admin role, please refer to the document below to add the current user as an administrator,
OTK User Role Configuration - CA API Management OAuth Toolkit - 4.2 - CA Technologies Documentation
Or, you may need to login /oauth/manager as default admin/pmadmin/administrator user
We don't want to give all the managers the admin role. Our oauth managers all work for different departments and each can create their own clients in the OTK manager. On login with the account created for them, they can only view and do CRUD operations on their own clients. When each user is assigned as an admin, they are able to change records not owned by them.
I don't share your opinion absence of the admin role is the root cause of returning the first record instead of the one selected for editing. This should be ok for each user granted access to the OTK manager.
From the docops page you are referring to; "The administrator role has a global view of clients, while the user role can see only their own clients."
The clients from the default otk schema/testdata sql files are all registered by admin, the other user will not be able to view them.
A new user has been created and I'm unable to edit the clients that are listed from the second row onwards using this new user log in. The clients are added by the logged in user only. the user has admin privileges but still unable to edit the clients. I've noticed that it allows to Edit from ListKeys page i.e. ListKeys -> Edit and save the changes. The saved changes are available in otk_db.oauth_client_key table but it doesn't update otk_db.oauth_client table
Any reason on why there are two tables ? I noticed that for few records the data in otk_db.oauth_client is older when compared to otk_db.oauth_client_key table. It might be because of the reason that it is allowing me to edit from ListKeys page.
I've debugged the issue to some extent and at this moment it appears to be the problem with L7 caching. Overall when tried to edit a client, the client_ident is passed from UI to the server and on server it first looks at cache and if not found then executes a DB query to return the client matching with client_ident. Now the problem is when it looks in L7 cache to retrieve the client it is currently returning all the available client records. The 'Edit Form' policy is then picking up the top record and prefills the fields on the page with top record details.
I tried to delete the L7 cache, the only way to do this is to set the expiry time to a lower timestamp, but it still says that cache is valid and returning all the records, I might be doing something wrong. (OTK Caching customization).
This is not about editing the default test clients. This is about editing clients created with the same user. It is not possible for a non admin user as all the client edit buttons lead to the first record shown on the page.
Again, this happens with any user, even with the admin user.But don't worry, I have solved it by updating the OTK version (4.0 -> 4.1), but the problem is there, a solution can not be version update. For the moment it's enough, but the problem is there ... I'll pray that it does not reappear because the versions to upload are over.
Well.. I'm on version 4.1 facing the same problem, it worked fine for few days and suddenly this problem appeared. Hope it won't apear for you.
So, we must resolve this together!!!
Just for know:
Do you use some version of the MAG?
If so...:Wich one?When was installed? Immediately after the OTK?Do you remember if the problem appears after this installation of the MAG?
Sounds like a bug, I would suggest to open a support ticket.
No, MAG is not installed, there was no change done on OTK except for the post installation tasks given in the documentation. This looks like a bug to me with L7 caching.
Retrieving data ...