Skip to main content
Z
ZbigniewK12-Amethyst
12-Amethyst
May 8, 2024
Solved

Timers/schedulers and user context

  • May 8, 2024
  • 1 reply
  • 1971 views

When creating a scheduler or timer, I do create a dedicated user for it. And it's local TWX user, no some Active Directory user, etc.

This user is given permissions for all Things/services which are required when scheduler/timer is triggered. 
Everything works perfectly at development server.

Unfortunatelly, during deployment, this user is not deployed to production server. Because user are never deployed. And I have no admin rights at production to create this user, and set permissions again.

I could set administrator as user context for timers/schedulers, because such user already exists at every server... but as far as I know it is recommended not to do so, for security reasons.

Is there any other solution to cope with that? 

Best answer by VladimirRosu_116627

Ref 2: If that statement is correct (I'm not sure where it's mentioned), then you should note that it's a recommendation, not a mandatory step. This means that in cases you find it valid, you can choose not to obey that recommendation. If it would have been mandatory then we would not have the capability to import Users.

Ref 3: that service will be executed by the Administrator. I find it hard to believe that the deployment itself is executed purely by an user that's not Administrator, right?

The idea is that the deployment process should not consist only in deploying (via Import/Export files or extension), but should include a "Post" install step, that will be execute by the actor doing the deployment (which can be either a human or an orchestrator like Azure DevOps workflows).

This "Post" install step should include all plumbing things like the one we discussed here.

Ref the last statement: the right way to look at this is the fact that you have APIs available for you to solve almost any possible situation that could arrive in production. The power of those APIs you use in your services is that they give you the power to build any sort of workflow you might think of. That same flexibility is almost impossible to re-create in a single UI (Composer) for all use-cases.

 

1 reply

V
19-Tanzanite
Velkumar19-Tanzanite
19-Tanzanite
May 8, 2024

Hi @ZbigniewK 

 

You can include user in your project and export / import in different environment along with Timer/Scheduler.

 

As a post deployment activity, you can create a service which will provide runtime permission to User for Timer / Scheduler.

 

This way you can avoid creating user manually in Production environment

 

/VR

 

 

Z
ZbigniewK12-AmethystAuthor
12-Amethyst
May 8, 2024

1. Yes, adding user to project was so obvious for me, that I even did not mention. I treat user as one of resources, all resources are assigned to project. 
2. As a developer, idea is I will be NOT allowed to import anything. And user will be not transfered during development. That's what my DevOp says. Because PTC does not recommend to deploy users. 
3.  Probably I could also create user via service. But... this service will need to have permissions, probably higher than my on Prod server, am I right?  So, will it work? 
Also,  if I have to set anything on Dev server graphical way, test it, then create service to do exactly this same but by code... so where's profit of using graphical, low-code enviroment as TWX?  

V
VladimirRosu_11662719-TanzaniteAnswer
19-Tanzanite
May 8, 2024

Ref 2: If that statement is correct (I'm not sure where it's mentioned), then you should note that it's a recommendation, not a mandatory step. This means that in cases you find it valid, you can choose not to obey that recommendation. If it would have been mandatory then we would not have the capability to import Users.

Ref 3: that service will be executed by the Administrator. I find it hard to believe that the deployment itself is executed purely by an user that's not Administrator, right?

The idea is that the deployment process should not consist only in deploying (via Import/Export files or extension), but should include a "Post" install step, that will be execute by the actor doing the deployment (which can be either a human or an orchestrator like Azure DevOps workflows).

This "Post" install step should include all plumbing things like the one we discussed here.

Ref the last statement: the right way to look at this is the fact that you have APIs available for you to solve almost any possible situation that could arrive in production. The power of those APIs you use in your services is that they give you the power to build any sort of workflow you might think of. That same flexibility is almost impossible to re-create in a single UI (Composer) for all use-cases.

 

    Terms & ConditionsCookie settingsAccessibility statement