What the actual Frank is going on? How can a disabled directive fire?
And, anyone have any ideas on how to better disable or block directives programmatically? I’m thinking maybe unticking “enabled” does more than just setting the database field.
@jgiese.wci many thanks for pointing this out. I suppose it should be obvious but anyhow, it’s exactly right. Once I re-enabled and then disabled my directives, they don’t fire. So my approach in disabling them via powershell is not valid.
If I had time I suppose I could use a REST call from powershell but it strikes me, there are already widgets for conditions like “if this is in Production” - probably for a reason.
I see you have the answer… but as @jgiese.wci suggested, I would also implement a standard in your BPMs to look at a place in the database to determine if this is a live or test/dev environment. There is a relatively new field in company maintenance that you can check… and if it is not true, then don’t run, or, at least make the BPM do something different in LIve vs Dev.
Problem is in a restore from prod situation this comes along for the ride as live. The built in live flags can get screwed up when restoring from other DBs. I wish it were just in the web config “This is my production app server” tied directly to IIS. The production flag in admin console isn’t solely tied to the app server either. My understanding is for cloud customers that’s not a solution either, but having the live flag stored in the DB is only so so helpful.
More recently I’ve been coding in a “debug mode” based on detecting this.session.AppServerURL and then taking different actions based on whether the server is A or B or the AppServer name is Production, Pilot, DEV, etc.
I wasn’t doing that back when we built this. I can see the “Is Live” flag being useful for devops teams but in this case it’s just me and the bots. And everything Dev restored from Prod.