Skip to main content
  • EN

Hi all,

What is the correct process to delete admins from FME Server. I deleted 3 fmeadmin users, testing before that any schedules or automations would be assigned to another user etc.

 

Today many of our schedules who are owned by a completely different user are not working. They also don't work if I do a manual trigger. Recreating the schedule does work. Re-adding the user doesn't.

 

I see in the Completed jobs that the schedules that ran before I deleted user have a reference to a Deleted user.

 

I think the only way to fix this is to manually try to trigger each of our 25 job and recreate the schedule on acceptance and production.

 

Any other ideas would be appreciated. And it would be interesting to know what is the correct procedure? Did I miss something?

 

We are using Server 2021 but this server has been upgraded with an old backup since approx 2015 version.

 

 

 

Looks like if I open each of the schedules and then save them they will then Trigger. Phew :)

Looks like if I open each of the schedules and then save them they will then Trigger. Phew :)

Phew indeed, I've had that happen to me with automations that were using schedules, although not with recent upgrades.

Hi @annette2​ ,

Perhaps this article helps:

https://community.safe.com/s/article/fme-server-troubleshooting-schedules

Krien

Thank you @annette2​  and @krien​ for reporting this and bringing it to our attention. I was able to reproduce this in different versions, which indicate that this behaviour was always the case. However I have filed a bug and included this behaviour in our Known Issues 2021.x and Known Issues 2022.x articles. I will update this post if there are any changes.

 

Kind regards,

Kezia

Update: The fix for this issue will be available in FME 2023.0 and newer!

Good to hear @keziaatsafe​ 

Hello, I am a colleague of Annette.

 

Recently we have removed another fmeadmin, and we see the exact behavior described by Annette with Automations as well: For Automations last saved/started by the deleted user the jobs are not triggered anymore. in the job history there is a reference to a Deleted user for previously run jobs.

We are using FME 2022.2

 

Is this known and fixed in FME 2023.0 as well?

Hello, I am a colleague of Annette.

 

Recently we have removed another fmeadmin, and we see the exact behavior described by Annette with Automations as well: For Automations last saved/started by the deleted user the jobs are not triggered anymore. in the job history there is a reference to a Deleted user for previously run jobs.

We are using FME 2022.2

 

Is this known and fixed in FME 2023.0 as well?

Hi @martyro​ ,

This is a known issue and the fix is currently planned for FME 2024.0. For internal reference purposes, the ticket is tFMEFLOW-21301].

In the meantime, the workaround is to stop and restart the automation under the user it was transferred to (e.g. Admin). I apologize for the inconvenience.

 

This issue has been reported in 2 other community posts. I'll link them here for reference.

 

Hope this information helps.

Kezia

Also related to the removal of a user, we want to report this undesired behavior:

 

When we delete a user, the API tokens of which this user is the owner are also permanently removed.

There is no prompt of this in the UI when you delete the user.

Also it is not possible to change the owner of an API token in the UI of FME Server.

 

This results in unpleasant surprises when deleting a user.

 

Is this issue known and is there a fix for it?

 

We are using FME Server 2022.2

Also related to the removal of a user, we want to report this undesired behavior:

 

When we delete a user, the API tokens of which this user is the owner are also permanently removed.

There is no prompt of this in the UI when you delete the user.

Also it is not possible to change the owner of an API token in the UI of FME Server.

 

This results in unpleasant surprises when deleting a user.

 

Is this issue known and is there a fix for it?

 

We are using FME Server 2022.2

Hi @martyro​ ,

Unfortunately, this is expected behaviour for security reasons. When a user is removed, the Flow Apps are disabled and the token is removed. The new owner will need to save the workspace app for a new token to be created and see a message when opening the disabled app.

Resave Workspace AppWe do have a ticket tFMEFLOW-22191] asking for ownership of tokens to be transferable but is not currently planned. I've added your comment above to the ticket for visibility. I agree that a prompt will be helpful when deleting users and have filed a ticket for this rFMEFLOW-22366].

Please feel free to add this as an Idea to our Community Ideas page here.

 

Kezia

Hi @martyro​ ,

Unfortunately, this is expected behaviour for security reasons. When a user is removed, the Flow Apps are disabled and the token is removed. The new owner will need to save the workspace app for a new token to be created and see a message when opening the disabled app.

Resave Workspace AppWe do have a ticket eFMEFLOW-22191] asking for ownership of tokens to be transferable but is not currently planned. I've added your comment above to the ticket for visibility. I agree that a prompt will be helpful when deleting users and have filed a ticket for this iFMEFLOW-22366].

Please feel free to add this as an Idea to our Community Ideas page here.

 

Kezia

Thanks @keziaatsafe.

For Flow Apps the behaviour is kind of mitigated with the notification at the Flow App itself, but you still need to look up those particular workspace apps.

 

The issue we also encountered concerned a Webhook token for an integration with an external application. For this situation there is no notification whatsoever in Flow that that Webhook token is deleted.

 

So a prompt of API tokens when removing a user and the ability to transfer ownership of tokens would be really helpful for these cases.

Reply


Community Stats

30,102
Posts
114,260
Replies
37,733
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.