We would expect that when an eligible approver selects “Approve” for the request, the request would be moved to the “History” tab and out of the “To Review” tab. We would also expect that the updates contained in the action would apply once the request is approved.
Actual behavior
Selecting “Approve” on the request does nothing. It does not get cleared from the “To Review” tab and the updates contained in the action do not get made. However - clicking “Reject” on the request does in fact clear it, but when we tried to make the necessary update in the action afterwards, we faced the same issue with the request not getting approved.
I’m currently investigating this, but I’m currently not able to reproduce this issue.
Would you mind sharing your project name so I can check what’s happening on our end?
Also, do you have any error toastr/in the network tabs of your browser console ?
Could you share with us how you defined your smart action please?
More information like your project name could help us too
Do you know when this error appears in the console (when you approve it? when you load the page? …)
Does the “Update institution” action still exist on your collection?
Hi @Guillaume_Cisco ! Thanks for your help and sorry for the delay.
The project name is woodpecker. The error that I detailed in my last post appears when trying to approve the request. And yes, the “Update Institution” action still exists on the collection.
Here is how we are defining our Update Institution action:
where getValuesUpdateInstitution() gets the institution given the context.
This action is working as expected except for when trying to approve the request.
I am wondering how this call to https://api.forestadmin.com/api/custom-actions/... can be done as there is no such route on the Forest Admin API.
Could you share a screencast of your browser, with the network tab of your developer console opened, while trying to approve an approval request?
It would help a lot to understand what is happening here.
Your issue appears to be very strange! Let’s try to finally find where it comes from.
To sum up:
This action exists for a while
It always works when not used with the approval flow
It always works when used with the approval flow if the same user self approve its request
It never works when used with the approval flow if a user tries to approve someone else request
This problem occurs only for this specific action
Am I correct?
I’ve tried to reproduce your error with the same settings for my action but no luck.
It’s pretty hard to tell where it could come from.
Sorry but would you mind to share your network again (in the failing scenario), and clean everything before your final click on “approve”. It should look like something like this:
From this, hopefully we will be able to understand what call is missing / wrong and identify your problem.
Side note: it is something possible for you and your team at some point to remove this action and put it live back again and see if the problem persists?
The content of the response of the query on /action-approval/:id? In your screenshot we only see the headers, and I would like to know the actual JSON sent by the server
In the same way, you’ll find calls when loading an environment, on https://api.forestadmin.com/api/renderings/[yourProject]/[yourEnv]/[yourTeam], and I would like to know the extract of the received json:
I would like to know the content of an object in the included property, corresponding to your custom action.
I suspect that there is a mismatch between the two ids, that leads to your error. Can you find this info and share them with us?
The action is called ‘Update Institution’ on the Institutions collection – I am seeing it on the production environment while I am on the IE - Administrators team.
We are not able to try that solution because we would have to release without the action and then wait until another release window before we are able to put it back.
This is the url that I used in order to get the action object from the included array, as suggested in a another post:
Is this a bug that will be fixed on your end, and if so is there an estimate for when it will be done? Or is there not a plan to fix it, but instead the goal is to migrate to the new role system?
In addition to fixing this bug, our new Roles system will provide you more security and flexibility with your users’ permissions. So that’s definitely something we could consider in this situation.
The migration is pretty smooth and easy to run.
Would you be available in the following days to give you a quick demo and help you migrate to our new Roles system?