Any recommendations for how to make it blatantly obvious to users that they are working in pilot and not live? In the past I have changed the color of the URL on the top right of pilot to be red, but with the copy from live to pilot last night, it switched back to looking exactly like live, and I’m forgetting how I changed it last time. 
I would hate to have some of our users doing their jobs in pilot and thinking they are in live. Any suggestions would be much appreciated!
My Procedure for a pilot refresh:
Company Maintenance:
Change Company Name: Acme Pilot DB 10/05/23
All my reports print the company name on the top.
Change Content Bar: Red
Theme Maintenance
Change in Theme default to: Inspired
Our default for Live is Office2007 (Blue), Inspired changes all screens to Brown.
Now all screen look very different.
1 Like
Thanks Patrick. Where specifically in Kinetic 2023 are you able to modify the theme?
If using Chrome browser this I found is really useful : URLColors - Chrome Web Store
For me this in the setup differentiates the 2 environments and isn’t re-set when we take a backup from Production into test:
Production, Red
Sandbox, Green
Only really helpful for me - but I spend most of my time these days flicking back and forth between production & test
2 Likes
No sure, were stuck in classic for now.
You can try going into settings > appearance. You also have the option to load images.
Then mess around in here. We’ve had mixed results with this but at least it’s a starting point for you.
Hope this helps.
-B
Yeah, every time I get a new pilot database, I go right in there and go to Advanced Settings to change the background colors. I change all the various shades of grey to various shades or red. so as long as my screen is red I know I am in pilot. You have to do this every time Pilot gets updated from Live.
Most of your users shouldn’t be in Pilot anyway. We only have two folks at our company that really use Pilot.
We have a color/theme document that describes each environment too and use those colors everywhere we can. We set the colors and theme in the DB after a refresh with a script that uses the dbname to determine which colors and themes to apply from an external data source. It’s all automagicated
Here is the part of the script I can share that doesn’t contain any urls. I’m too lazy to cleanse the whole thing it’s real long.
ALTER PROCEDURE [dbo].[PostRestoreUpdates] AS
BEGIN
-- Setup variables for the remainder of the script
DECLARE @AppServerName NVARCHAR(50) = DB_NAME();
DECLARE @AppServerTheme NVARCHAR(50);
DECLARE @AppServerColor NVARCHAR(50);
DECLARE @Hostname NVARCHAR(50);
DECLARE @MaxSysDate DATE;
DECLARE @ddlSql NVARCHAR(MAX);
-- Store current hostname for later use
SELECT @Hostname = CAST(SERVERPROPERTY('MachineName') AS NVARCHAR(50))
-- Check if the @AppServerName is 'Prod', the don't be a dumbass saver
IF @AppServerName = 'Prod'
BEGIN
RAISERROR('The Database cannot be "Prod". Terminating the script.', 16, 1);
RETURN;
END
-- Create appserver reference info
CREATE TABLE #AppServerInfo (DatabaseName NVARCHAR(50), KineticColor NVARCHAR(10), ThemeID NVARCHAR(50));
INSERT INTO #AppServerInfo (DatabaseName, KineticColor, ThemeID) VALUES
('Prod', '#008BD1', 'Live'),
('Prob', '#1BA400', 'Problem'),
('Dev', '#FF2D2D', 'Dev'),
('Test', '#FE7F00', 'Testing'),
('Demo', '#962DFF', 'Demo');
-- Get the values from the temp table based on the @AppServerName
SELECT @AppServerColor = KineticColor, @AppServerTheme = ThemeID FROM #AppServerInfo WHERE DatabaseName = @AppServerName
-- Drop the temp table
DROP TABLE #AppServerInfo;
-- Select the max SysDate from Erp.PartTran and store it in the variable
SELECT @MaxSysDate = MAX(SysDate) FROM Erp.PartTran;
-- Set company and environment info
UPDATE Ice.SysCompany SET Name = CONCAT('**', Company, ' - ', @AppServerName, '|', @MaxSysDate, '**'), KineticColor = @AppServerColor, IsLive = 0
UPDATE Erp.Company SET Name = CONCAT('**', Company, ' - ', @AppServerName, '|', @MaxSysDate, '**')
-- Attempt update of Admin Console config settings
UPDATE Ice.SysConfig SET InstanceDefinition = REPLACE(REPLACE(InstanceDefinition, '"IsProductionInstance":true', '"IsProductionInstance":false'), '"IsLive":true', '"IsLive":false') WHERE InstanceDefinition <> '' AND Key2 NOT LIKE '%PRODUCTION%'
UPDATE Ice.SysLicense SET IsProductionInstance = 0
-- Set default ThemeID [Live | Problem | Dev | Testing | Demo]
UPDATE Ice.Theme SET DefaultFlag = 0
UPDATE Ice.Theme SET DefaultFlag = 1 WHERE ThemeID = @AppServerTheme
.
-- Do Dcheduled Task Deletion
.
-- Setup EBIZ Sandbox
.
-- Setup PLC Custom Dev Values
.
-- Setup 'readonly' User
.
-- etc. etc. etc
END
7 Likes
Best quote I’ve seen this year!
1 Like
Having an environment dedicated to bug fixes / troubleshooting is a great idea. I’m stealing it. I normally use my dev environment but that can be trouble when in the middle of actively developing something.
Yeah Problem stays offline most of the time but if I have a issue report for data that was corrupted and I need to restore to a specific minute that’s the place we dump it knowing it’s highly volatile do not develop in it at all.
1 Like
I have styles that came from E9 and layouts that are from 10 for dev, test, pilot and sandbox. Once you get them set then import them into production, so they come along with each restore. Then in the script which I am pretty sure came from here reset during the restore.
E11 restore EpicorPilot.sql (3.4 KB)
1 Like
Oh snap
1 Like
Can this be done in the kinetic cloud environment or do I have to access from the client?
Yes. The screenshots I posted are from a local client installed for a cloud based environment.
In my personal experience that Appearance setting only seems to change color theme of classic menus, not the new kinetic menus.
1 Like
We use a different color on the top content bar to make Kinetic menus look different for our Pilot environment.
Navigation: System Setup > Company/Site Maintenance > Site Maintenance > Main Plant
For Classic we use a theme that is set for all users which changes the top/bottom areas to green
In both Kinetic and Classic we have to redo this after each upgrade or anytime we request Pilot to be refreshed.
2 Likes
Let’s make that automatic.
Edit to your own liking.
Ice.BO.Plant.GetList gets called when Kinetic loads.
We can do a check then, and make changes if needed.
Needs a refresh after the first time to see, but all subsequent will be correct.
//Pre-Processing on Ice.BO.Plant.GetList
string urlMatchString = "pilot";
bool isProduction = !Session.AppServerURL.ToLower().Contains(urlMatchString);
if(isProduction == false)
{
CallService<PlantSvcContract>(plant =>
{
string plantPrefix = "PILOT - ";
string kineticColor = "#3ED257";
PlantTableset plantTableset = plant.GetByID(Session.PlantID);
bool changed = false;
PlantRow plantRow = plantTableset.Plant.FirstOrDefault();
if(plantRow.Name.StartsWith(plantPrefix) == false)
{
plantRow.Name = plantPrefix + plantRow.Name;
changed = true;
}
if(plantRow.KineticColor != kineticColor)
{
plantRow.KineticColor = kineticColor;
changed = true;
}
if(changed)
{
plantRow.RowMod = "U";
plant.Update(ref plantTableset);
}
});
}
3 Likes
Y’all can obviously expand on this with some of the other ideas in this thread.
When anyone logs into Kinetic, you can do checks and changes that persist.
Does yours still work for 2023.2 on the cloud? Mine throws a error now. Used to work though.
1 Like