Expected behaviour
Good morning folks,
I’ve currently implemented a smart action called Update units for our admin UI. I’m expecting this smart action to work across different teams. We have several teams at the moment but we want it to work for the Production Admin team and the Engineering team.
Actual behavior
At the moment, the smart action works with the following combinations:
- Works in the Engineering Team UI in Staging
- Works in the Engineering Team UI in Production
- Works in the Production Admins Team in Staging
- Fails in the Production Admins Team in Production
It is weird that the smart action seems to work everywhere except in the Production environment when I’m in the Production Admin teams UI. I’ve double checked the roles and I have all the relevant permissions for this smart action.
Here’s a screenshot of the error:
Looking for some help to see how to resolve this issue - I’m really stuck on this one!
Thankyou
- Package Version:
- express: “^4.17.1”,
- “forest-express-sequelize”: “^7.3.1”,
- Sequelize Version:
- Database Dialect: Postgres
- Database Version: Postgres:12
- Project Name: Oak National Academy
Hi @Mitchell_Lloyd 
Have you got any error logs on your browser console ?
Can you share with us the HTTP response of smart action call on your browser network tab console ?
Hey @Arnaud_Moncel
I’ve currently got this in the browser console:
After triggering the smart action in the UI, this is all I can see in the network tab:
What i can see you have an error in your CORS configuration linked to your smart action call
more precisely the headers configuration.
Please can you verify the allowed headers on your server ?
Hey there, the allowed headers are specified here:
I thought that we’re setting the “Access-Control-Allow-Origin” header in this snipper of code - is this not the case ?
Have you got the same headers error when you run your smart action with the Engineering team ?
No I don’t get a CORS error when I’m on the engineering team. I just see this in the console:
Hi @Mitchell_Lloyd !
Can you share with me what the action you are trrying to trigger does ?
What is the value of you CORS_ORIGINS environment variable ?
Hi @anon94532230 ,
The value of CORS_ORIGIN in production is http://prodhub.thenational.academy,https://prodhub.thenational.academy
Then the update units smart action allows a user to upload a csv file in order to update multiple units records. As well as updating multiple units it should also write a record into an audit table ( called logged_actions ) tracking the update and a record into unit_audits which allows us to link audits to the units table. My role has all the relevant permissions to write to these tables - indeed the smart action works when I’m on the Engineering team UI.
Hi @Mitchell_Lloyd,
Super weird indeed - the behavior should be the same between staging/production and accross your team with your configuration.
I’ll do a setup similar to your and let you know if I’m able to reproduce
Sorry for the delayed response and thanks for your patience 
1 Like
No problem @jeffladiray
Thankyou for helping with this strange issue
Sadly, I’m currently unable to reproduce this issue.
Would it be possible to get a screen (Or better, a video), of the HTTP request and response headers and content for the POST /forest/actions/update-units call that is failling?
Also, did you notice this issue recently (Today?) or do you know if this has been around for a while?
1 Like
No problem - at the moment, I can’t make a video right away. But I can try and sort that out for you tomorrow if you still need more info. However, I can share with you the request/response headers.
When I trigger the “Update units” smart action on the Production Admins team I get the following:
The above screenshots are taken when I’m in the Production Admins team and the Update units smart action doesn’t work. So I’m definitely getting a CORS error here.
However, when I switch my UI to Engineering then I get the following request/response headers:
It has to be a CORS error - the only obvious difference is that the server responds with the “Access-Control-Allow-Origin” header when the smart action is successful. But I don’t understand why the server is responding with different headers when I switch between the two different teams.
1 Like
I’ve only really noticed this issue recently - but it maybe I’ve only just spotted it too.
Hi @Mitchell_Lloyd,
It is a CORS issue indeed, but I still have no clue of why Access-Control-Allow-Origin is present for one team but not for the other.
However, I find it weird that the failing request header contains Origin where the second one does not. The Origin is mandatory for Access-Control-Allow-Origin to be sent back, so the issue seems to be here.
From what I can find, Origin should be automatically set by fetch() via your browser.
If that’s possible on your end, could you eventually try with another browser? I’m pretty sure it is un-related but that’s an easy test to do. On my end, I’ll keep trying to get a reproductible example and I’ll check if the code on our end responsible of calling the smart action hasn’t recently change.
Again, sorry for the delayed response but be sure I’m still on this topic 
EDIT: I did not get this right 
- Your
Production Admins have the origin header - but the response does not have the Access-Control-Allow-Origin header.
- Isn’t your second screenshot cropped? I can’t see the
origin header on it.
Also, I can see on my end (And via your CORS config) that you are using a custom-domain. Could you also try with the custom-domain instead of app.forestadmin.com?
Thanks in advance
Would it be possible to also share your smart action code and definition?
1 Like
Morning @jeffladiray
Here is a screenshot of the smart action definition:
I’ve also tried triggering the smart action using Chrome and I still get the same CORS issue. I’m going to try some of the other suggestions too to see if I can find a workaround.
Thanks Mitch
I can also confirm the Origin header definitely appears on the request headers when the smart action is triggered successfully in the Engineering UI.
As a last resort, I would also suggest to try logging the res.getHeaders() right before your res.send(...), just to check if that’s a forest-express-sequelize issue, or if it’s your host provider that removes this header (Based on a regexp?).
I worked on a pretty similar setup (Smart action + File field with a production deployment with multiple teams), and still, I’m not able to reproduce …
EDIT: Our forest-express changelog has an entry for a fix in CORS config. Could you eventually also try to upgrade forest-express-sequelize to 7.12.2 or higher ?
1 Like
