Skip to main content
March 23, 2023
Solved

No Security Access Validation Message

  • March 23, 2023
  • 5 replies
  • 0 views

Hi, I am testing V 7.2.3 in our Dev environment. Production is still on 6.5. The security and user groups, data sources, and workflow profiles are identical between the two. I am able to import and validate TB's in the workflow, but several others are not able to Validate in the Dev environment. Has anyone else experienced this?  The validation message is "No Security Access", but the workflow profile and security groups are idential to prod.

 

Thanks!

Best answer by PMancoll

We found an answer to this.  In our case, the issue was that the user in question needed to be a member (directly or indirectly) of
the "ModifyData_Security" accessGroup,  which is the one that had the application security role of "ModifyData".   It was not immediately intuitive that one would need access to the ModifyData role in order to do or see validation messages, but I guess it makes some sense.  

5 replies

March 24, 2023

Hello!
How did you migrate your application from PROD to DEV?
Did you do an Application appzip extract? Did you all extract all System security groups?
Thanks

March 24, 2023

Hi, thanks for the response!

OneStream copied over the Dev environment with our current Prod. The security roles and groups are identical.

March 24, 2023

Hey! OS probably did an SQL dump of your app. It will be a perfect clone.
Now regarding the SYSTEM, i do not think they do an SQL dump of PROD to DEV. The Security Groups are, however, stored under the system. They might have done a copied the SYSTEM > SECURITY using the XML.
To be honest if all is the same, you should not have this issue. I would probably try to recopy the groups. And check if the users who have the issue are part of the same groups than in prod. 

June 12, 2023

I am having the same issue but not on version 6.6.  Did you ever get an answer on this issue?

PMancollAnswer
January 17, 2025

We found an answer to this.  In our case, the issue was that the user in question needed to be a member (directly or indirectly) of
the "ModifyData_Security" accessGroup,  which is the one that had the application security role of "ModifyData".   It was not immediately intuitive that one would need access to the ModifyData role in order to do or see validation messages, but I guess it makes some sense.