Hi all,

We are on 2019.1 since last week, but already now I can see the practial problems of only having role authorisation in the SF and no longer in IAM. Before certain endusers could tweak some rolesettings in IAM for production applications, which in the end, was fine… As soon as a new version was ready for deployment (via an Acceptation environment) roles would get synchronised first from production, to get the latest settings. After Acceptation back to production and for the coming months the enduser could fix little authorisation issues in production.

Now it all has to be done in de SF and after fixing a (role) synchronisation is necessarry. This is all a already quit hassle, but when there is already a new version in development things get even more messy, as changes would have to be done in two versions. Also the “enduser” would need access to the SF to fix little authorisation issues (in what version???).

Testing roles in the SF for certain new pieces in a next version is fine for the developer, but in the end a set of roles assigned to a group cannot be testet by simulating them in the SF; only one role at a time can be simulated, which is not a reprensentation of the real world.

In short: get the ability to make (minor) role authorisation changes back in IAM, because this is not working for me and I can't imagine I am the only one having issues with this.

I have run into simular problems. After deploying a specific project version, rights sometimes have to be altered. This is due to the fact that end users can not test their rights before deploying a version onto IAM. Therefor I’am required to alter the rights after deploying this version. After altering the rights, I have to redeploy the entire version, which seems a little overkill, especially when your project is quite large.

I do see the issue: when you've add objects to the model which cannot be mapped in IAM. This will lead to a model conflict.

All I’am asking for is a solution for this, which ever works bests. Thanks in advance.

Hey everyone,

I don't really see what the root problem is. The script does a merge to check whether or not to update/insert the model. So if the model is the same, no records should be effected. Can someone further explain what the main problem is;  Is it the size of the file? Or the speed of the synchronization? Or just the feeling of overkill because we didnot explain correctly what the script does?

Thanks in advance.

When a customer asks for just a little adjustment in role authorisations don't want to spend more then 1 minute on this and indeed it gives me the feeling of an overkill of unneeded processing.

Actually I am not so sure if the move of roles from IAM to SF really is an improvement.

@Harm Horstman , I agree. It's fine to give a developer the initial “power” to change or arrange rights to roles. But on a daily base it should be an application manager (e.g. Enduser with no access to the SF) to make adjustments where needed.

The idea that roles now can be tested in the SF does not reflect the real world, where a user sees things based on a set of roles, handed out to one or more groups where he/she is member of.

Hello Harm and Henry,

Did you read our blogs about the subject? (https://community.thinkwisesoftware.com/blogs-21/roles-in-sf-considerations-and-possibilities-373 and https://community.thinkwisesoftware.com/blogs-21/re-design-your-roles-367). Here we explain how roles should look like and some advantages about the move. When your roles are to big, then I can understand how this would work against you.

I heard about a lot of real-world situations where a user or developer is given the ability to changes the rights directly on a production IAM without proper testing and then some features don't work anymore because that role needed some underlying procedures or tasks as well. So, you can see this as a setback, but I see it as a step forward in making the development process more stable and professional.

But maybe this is a bit off the original topic. I think it's basically the same as when a customer asks for a little change in a default value. Hopefully, you would change this in the template in the SF and not on the default procedure on the database, even though that would be way faster. I understand that for now, there is a transition period where this sounds a lot of work for a small change, but after you (and your users) are used to it, I think it will be worth the stability and quality of the end products. Wouldn't you agree?

Hi Ester,

Yes, but not 100%. Of course I like to be proffesional, but the business rules and often they just require a quick solution. 

And I am in the process of changing roles step-by-step. Is see some benifits here. But some improvements in role setup could help. 

In 2021.2 made some caching-improvements to make the synchronization less heavy. This leads to big performance improvement when synchronizing an existing project version. We think that this will solve the problem behind the idea without implementing the suggested solution.

When you are working with 2021.2 and find that this is not the case, please let us know so we can re-open this idea.