E9 Dangerous Issue with Favorites

Here is a solution from Epicor:
Summary: TECH Favorites on a copied DB point to the live DB and
caused data corruption
Book: Support Solutions
Page: 11422MPS

PROBLEM DESCRIPTION:
Restored a copy of my live database into the test slot and users going
in did not notice that when they clicked on their favorites, they had to
log on again. They then proceeded to alter inventory. Unfortunately,
this altered data in the live database and caused some serious issues.
Is there a way to avoid this in the future?

PROBLEM RESOLUTION:
PLEASE NOTE:
The detailed information provided below is an example. The idea is that
this will be modified or changed by the customer to fit their business
needs. The examples we provide have not been through a standard QA
process and are provided "as-is". These modifications should be
evaluated and tested thoroughly in a test environment prior to
implementation in a production environment. Further assistance may be
necessary to build from this example or implement it. If this example
goes beyond the scope of what the customer is comfortable with and what
is handled in Epicor Technical Support, we can assist the customer in
contacting our custom programming group (their services are billable).

Purpose: Change Favorites to point to current environment
Business Object: SysAgent
Method: Update
Directive: Pre Processing

After restoring the database backup into a new environment, log into the
restored database and:
1) Navigate to the Method Directives program (System Management >
Business Process Management > Setup > Method Directives)
2) Click Method Code
3) Select the Business Object dropdown and choose SysAgent
4) Click search
5) Select Update and click OK
6) Click the Pre -processing tab and Click the New icon
7) Directive Name = Change Favorites to point to current environment
8) Click the actions Button
9) Click the Add Action Button (New icon)
10) Select the Dropdown under UserText
11) Choose the action "synchronously execute ABL"
12) Click on blue underlined 'code'
13) When the 4GL action window displays, check the Execute code below
14) For the 4GL code body: paste code that follows these steps
14) Click OK
15) Click OK (Exiting the actions dialog)
16) Check the Enabled box and then click Save
17) Navigate to System Management > Utilities > System Agent
18) Change the appserver ports to reflect the current environment and
press save - all user favorites should now be pointing to current
environment


/*
Purpose: Change Favorites to point to current environment
Business Object: SysAgent
Method: Update
Directive: Pre Processing
*/

find first ttSysAgent where ttSysAgent.Rowmod = 'u'.
for each favitems where favitems.AppServerURL <>
ttSysAgent.MfgsysAppServerURL and favitems.AppServerURL <> '':
if avail favitems then assign favitems.AppServerURL =
ttSysAgent.MfgsysAppServerURL.
end.


VERSION: 9.04

keywords:
favorites
BPM
restore database


--- In vantage@yahoogroups.com, Mark Wonsil <mark_wonsil@...> wrote:
>
>
>
> >It sounds as this would be a constant monitoring situation because a User could create a Favorite at any time
> > throughout the day. I don't know if it is this easy but if you could somehow trigger a warning if the path for the
> > Favorite created does not match the path for the current login. That would at least warn the User that they are
> > about to make FUBAR.
>
> The user will get a Login Form if they click on a favorite that crosses databases and that's a pretty good warning.
>
> However, does it do it for every launch of that program or is one login good for the other Favorites?
>
> Mark W.
>
We had a user who claimed he created a cycle count in our test database, and it showed up in Live. We certainly hoped this was just user error, but after further investigation we found that the issue is in how E9 (9.04.505 at least) handles favorites.

Favorites are stored in the FavItems table. In this table there is a field called appserverurl. This field contains the servername and the port of the app server it was created on. This means if I take a backup of my production db and restore it to a test server, If users click on their favorites, they will be connected to the live DB for that module.

Craig
And this will still happen after you change the port numbers in the TEST
environment?



Thanks,

Blake Clemens

IT Systems Engineer

Delmarva Millwork Corporation

(800) 360-2364 x132

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of craig_weiss
Sent: Tuesday, March 23, 2010 11:30 AM
To: vantage@yahoogroups.com
Subject: [Vantage] E9 Dangerous Issue with Favorites





We had a user who claimed he created a cycle count in our test database,
and it showed up in Live. We certainly hoped this was just user error,
but after further investigation we found that the issue is in how E9
(9.04.505 at least) handles favorites.

Favorites are stored in the FavItems table. In this table there is a
field called appserverurl. This field contains the servername and the
port of the app server it was created on. This means if I take a backup
of my production db and restore it to a test server, If users click on
their favorites, they will be connected to the live DB for that module.

Craig



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.791 / Virus Database: 271.1.1/2764 - Release Date: 03/23/10
03:33:00



[Non-text portions of this message have been removed]
It is hard coded in the favorite record. It is not looking at the system configuration to determine the server and port. I experienced the same type of issue with Vantage 8, in that it hard coded the MRP log file path. If you run a baq against the table that contains scheduled processes, you can see where the log file has an explicit path, rather than a relative path. This seems to be the same type of situation.

On a related note, Favorites are now plant specific in certain cases. If you create a favorite for job entry, it will always open job entry in the plant you were in when you created the favorite. I can understand this technically, but it is a departure from Vantage where it would open job entry for whichever plant you were in at the time.
CW

--- In vantage@yahoogroups.com, "Blake Clemens" <blake.clemens@...> wrote:
>
> And this will still happen after you change the port numbers in the TEST
> environment?
>
>
>
> Thanks,
>
> Blake Clemens
>
> IT Systems Engineer
>
> Delmarva Millwork Corporation
>
> (800) 360-2364 x132
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of craig_weiss
> Sent: Tuesday, March 23, 2010 11:30 AM
> To: vantage@yahoogroups.com
> Subject: [Vantage] E9 Dangerous Issue with Favorites
>
>
>
>
>
> We had a user who claimed he created a cycle count in our test database,
> and it showed up in Live. We certainly hoped this was just user error,
> but after further investigation we found that the issue is in how E9
> (9.04.505 at least) handles favorites.
>
> Favorites are stored in the FavItems table. In this table there is a
> field called appserverurl. This field contains the servername and the
> port of the app server it was created on. This means if I take a backup
> of my production db and restore it to a test server, If users click on
> their favorites, they will be connected to the live DB for that module.
>
> Craig
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.791 / Virus Database: 271.1.1/2764 - Release Date: 03/23/10
> 03:33:00
>
>
>
> [Non-text portions of this message have been removed]
>
This is not good if it really works this way after changing the Port ID's. I just can't see updating every Favorites path for every user.
Has this been reported to Epicor?
 Sincerely,


Stephen

[Non-text portions of this message have been removed]
SCR 64700: Favorites still point to original DB after a restore.

In our case, only new Favorites added under E9 have the issue, not old ones created under V8.

--- In vantage@yahoogroups.com, Stephen Schaefer <sschaefer323@...> wrote:
>
> This is not good if it really works this way after changing the Port ID's. I just can't see updating every Favorites path for every user.
> Has this been reported to Epicor?
> Â Sincerely,
>
>
> Stephen
>
> [Non-text portions of this message have been removed]
>
Here is the response I just got from Epicor:
Summary: PERS: When a Favorite is selected in E9, why do you need to login into the DB?
Book: Support Solutions
Page: 8386ESC

ISSUE: The Epicor9 DB called Epicor904 (the LIVE DB) was backed up, then restored to a new Epicor9 DB called TEST. If you log into the new TEST DB and you select an existing Favorite, you are prompted for a login. Why?

After logging in, the process is loaded (for example, PO Entry). If you pull up an existing PO, make a change and then file the change, the changes are stored in the LIVE DB instead of the TEST DB. Why?

Note: If you use the menus to access PO Entry, the changes are stored to the TEST DB.

RESOLUTION: Epicor9 was enhanced and this is how Favorites now work.

In Epicor9, the Main Menu now supports multiple Companies and lists all Companies a User has been granted access, even if the Company is on another AppServer (DB). So when a Favorite is now created in Epicor9, the AppServer info as to where that Company's DB can be found, is stored in the Favorite (For example, your LIVE DB). If you log to another Company on another AppServer (for example, the TEST DB), then select the Favorite that was created in the other AppServer (the LIVE DB), you will get a login screen for the other AppServer and any changes will be stored to that AppServer's DB.

If you don't want this, deleted the favorite that was created in the LIVE DB and re-create the favorite in the TEST DB.


--- In vantage@yahoogroups.com, "chris_robisch" <bluewine@...> wrote:
>
> SCR 64700: Favorites still point to original DB after a restore.
>
> In our case, only new Favorites added under E9 have the issue, not old ones created under V8.
>
> --- In vantage@yahoogroups.com, Stephen Schaefer <sschaefer323@> wrote:
> >
> > This is not good if it really works this way after changing the Port ID's. I just can't see updating every Favorites path for every user.
> > Has this been reported to Epicor?
> > Â Sincerely,
> >
> >
> > Stephen
> >
> > [Non-text portions of this message have been removed]
> >
>
We had the same issue in 503B and still have it in 505C.

At the time, Epicor sent a note out to all of their consultants for them to warn customers.

We had somebody check parts out to an eco group and they went through favourites which meant they were actually checking them out in live.

We also had someone who did AP Invoices on what she thought was test, but went through favourites so they were on live.

As a rule of thumb, if you get a turquoise log in screen pop up when you are already logged in, it is likely that you will be logging on to a different version.


Â



________________________________
From: craig_weiss <cweiss@...>
To: vantage@yahoogroups.com
Sent: Tue, 23 March, 2010 15:39:29
Subject: [Vantage] Re: E9 Dangerous Issue with Favorites

Â
It is hard coded in the favorite record. It is not looking at the system configuration to determine the server and port. I experienced the same type of issue with Vantage 8, in that it hard coded the MRP log file path. If you run a baq against the table that contains scheduled processes, you can see where the log file has an explicit path, rather than a relative path. This seems to be the same type of situation.

On a related note, Favorites are now plant specific in certain cases. If you create a favorite for job entry, it will always open job entry in the plant you were in when you created the favorite. I can understand this technically, but it is a departure from Vantage where it would open job entry for whichever plant you were in at the time.
CW

--- In vantage@yahoogroups .com, "Blake Clemens" <blake.clemens@ ...> wrote:
>
> And this will still happen after you change the port numbers in the TEST
> environment?
>
>
>
> Thanks,
>
> Blake Clemens
>
> IT Systems Engineer
>
> Delmarva Millwork Corporation
>
> (800) 360-2364 x132
>
> From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf
> Of craig_weiss
> Sent: Tuesday, March 23, 2010 11:30 AM
> To: vantage@yahoogroups .com
> Subject: [Vantage] E9 Dangerous Issue with Favorites
>
>
>
>
>
> We had a user who claimed he created a cycle count in our test database,
> and it showed up in Live. We certainly hoped this was just user error,
> but after further investigation we found that the issue is in how E9
> (9.04.505 at least) handles favorites.
>
> Favorites are stored in the FavItems table. In this table there is a
> field called appserverurl. This field contains the servername and the
> port of the app server it was created on. This means if I take a backup
> of my production db and restore it to a test server, If users click on
> their favorites, they will be connected to the live DB for that module.
>
> Craig
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.791 / Virus Database: 271.1.1/2764 - Release Date: 03/23/10
> 03:33:00
>
>
>
> [Non-text portions of this message have been removed]
>







[Non-text portions of this message have been removed]
I reported it but I dont know it was logged by them as a call.

We have been thoroughly testing 505C on a new server - thankfully we told all of our users about this issue. If we hadnt, it could have been a catastrophe with orders, invoices, credits, jobs etc all being issued when they should have only been issued in a test environment.




________________________________
From: Stephen Schaefer <sschaefer323@...>
To: vantage@yahoogroups.com
Sent: Tue, 23 March, 2010 16:49:01
Subject: [Vantage] E9 Dangerous Issue with Favorites

Â
This is not good if it really works this way after changing the Port ID's. I just can't see updating every Favorites path for every user.
Has this been reported to Epicor?
 Sincerely,

Stephen

[Non-text portions of this message have been removed]







[Non-text portions of this message have been removed]
I searched the tables for the appServerURL field in 9.04.504B and there are four tables that have it:

SystemAgent
ExtCompany
FavItems
MenuTab

SystemAgent makes sense since the Agent needs to know which appServer to connect. ExtCompany makes sense too for multi-plant operations. FavItems and MenuTab are personalizations.

I understand Epicor's point on why it's there. The question is how to handle it when copying the database to another for testing. One option would be to create a customization on the SystemAgent program that displays a warning whenever the appServerURL changes. I might not use a BPM because those are stored outside the database and you'd have to make sure it was in the target database's BPMExec folder.

Instead of a warning, one could craft some code that would prompt to delete FavItems and MenuItems that had the old appServerURL value or even do a Find | Replace for the old and new values. I'm not sure that this would work if you were truly multi-plant/company and that you might not change the wrong records accidentally. That would take some further research from those who have those capabilites.

Mark W.
If you can update the database, clear it out. It's just too dangerous otherwise. After a restore to Pilot/Test:

disable triggers for load of favitems.
for each favitems where favitems.appserverurl ne "". assign
favitems.appserverurl = k
favitems.companyid = k
favitems.plantid = k.
end.
--- In vantage@yahoogroups.com, Mark Wonsil <mark_wonsil@...> wrote:
>
>
> I searched the tables for the appServerURL field in 9.04.504B and there are four tables that have it:
>
> SystemAgent
> ExtCompany
> FavItems
> MenuTab
>
> SystemAgent makes sense since the Agent needs to know which appServer to connect. ExtCompany makes sense too for multi-plant operations. FavItems and MenuTab are personalizations.
>
> I understand Epicor's point on why it's there. The question is how to handle it when copying the database to another for testing. One option would be to create a customization on the SystemAgent program that displays a warning whenever the appServerURL changes. I might not use a BPM because those are stored outside the database and you'd have to make sure it was in the target database's BPMExec folder.
>
> Instead of a warning, one could craft some code that would prompt to delete FavItems and MenuItems that had the old appServerURL value or even do a Find | Replace for the old and new values. I'm not sure that this would work if you were truly multi-plant/company and that you might not change the wrong records accidentally. That would take some further research from those who have those capabilites.
>
> Mark W.
>
Sorry. Replace k with "". Or add
def var k as char no-undo.

--- In vantage@yahoogroups.com, "chris_robisch" <bluewine@...> wrote:
>
> If you can update the database, clear it out. It's just too dangerous otherwise. After a restore to Pilot/Test:
>
> disable triggers for load of favitems.
> for each favitems where favitems.appserverurl ne "". assign
> favitems.appserverurl = k
> favitems.companyid = k
> favitems.plantid = k.
> end.
> --- In vantage@yahoogroups.com, Mark Wonsil <mark_wonsil@> wrote:
> >
> >
> > I searched the tables for the appServerURL field in 9.04.504B and there are four tables that have it:
> >
> > SystemAgent
> > ExtCompany
> > FavItems
> > MenuTab
> >
> > SystemAgent makes sense since the Agent needs to know which appServer to connect. ExtCompany makes sense too for multi-plant operations. FavItems and MenuTab are personalizations.
> >
> > I understand Epicor's point on why it's there. The question is how to handle it when copying the database to another for testing. One option would be to create a customization on the SystemAgent program that displays a warning whenever the appServerURL changes. I might not use a BPM because those are stored outside the database and you'd have to make sure it was in the target database's BPMExec folder.
> >
> > Instead of a warning, one could craft some code that would prompt to delete FavItems and MenuItems that had the old appServerURL value or even do a Find | Replace for the old and new values. I'm not sure that this would work if you were truly multi-plant/company and that you might not change the wrong records accidentally. That would take some further research from those who have those capabilites.
> >
> > Mark W.
> >
>
I just had a chance to test this situation. I don't personally use shortcuts - being from the consulting world - old habits, so I had to find a user that i could test this with.
We are still on Vantage 8.03.408B.
We have our LIVE and TEST databases on two separate servers.
When I used a shortcut in our TEST database - it looked at only the TEST database. I thought we should be safe and it's a big sigh of relief on my part.
I am not in IT, so please forgive me if this sounds dumb, but I want to be sure...if we keep a similar setup of two separate servers if and when we upgrade to Epicor 9 -- we should still be safe, right?

Sincerely,
Stephen Schaefer

Abrams Airborne

--- In vantage@yahoogroups.com, "chris_robisch" <bluewine@...> wrote:
>
> Sorry. Replace k with "". Or add
> def var k as char no-undo.
>
> --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> >
> > If you can update the database, clear it out. It's just too dangerous otherwise. After a restore to Pilot/Test:
> >
> > disable triggers for load of favitems.
> > for each favitems where favitems.appserverurl ne "". assign
> > favitems.appserverurl = k
> > favitems.companyid = k
> > favitems.plantid = k.
> > end.
> > --- In vantage@yahoogroups.com, Mark Wonsil <mark_wonsil@> wrote:
> > >
> > >
> > > I searched the tables for the appServerURL field in 9.04.504B and there are four tables that have it:
> > >
> > > SystemAgent
> > > ExtCompany
> > > FavItems
> > > MenuTab
> > >
> > > SystemAgent makes sense since the Agent needs to know which appServer to connect. ExtCompany makes sense too for multi-plant operations. FavItems and MenuTab are personalizations.
> > >
> > > I understand Epicor's point on why it's there. The question is how to handle it when copying the database to another for testing. One option would be to create a customization on the SystemAgent program that displays a warning whenever the appServerURL changes. I might not use a BPM because those are stored outside the database and you'd have to make sure it was in the target database's BPMExec folder.
> > >
> > > Instead of a warning, one could craft some code that would prompt to delete FavItems and MenuItems that had the old appServerURL value or even do a Find | Replace for the old and new values. I'm not sure that this would work if you were truly multi-plant/company and that you might not change the wrong records accidentally. That would take some further research from those who have those capabilites.
> > >
> > > Mark W.
> > >
> >
>
Here's one of the culprit records:

"CRobisch" 1 23 "MfgSysProgram" "GLRP4040" "Book Listing" "" "GLRP4040" "" 21 "fda53f43-a691-3582-df11-021f76ee7733" 100520000 "AppServerDC://EPIC2:9001" "BMS26627" "MfgSys" 0

You'll note it has our server-name:port, EPIC2:9001, so NO, you're not okay. It'll prompt for a name/password and if the user enters it, they're in Live city!

--- In vantage@yahoogroups.com, "Snake" <sschaefer323@...> wrote:
>
> I just had a chance to test this situation. I don't personally use shortcuts - being from the consulting world - old habits, so I had to find a user that i could test this with.
> We are still on Vantage 8.03.408B.
> We have our LIVE and TEST databases on two separate servers.
> When I used a shortcut in our TEST database - it looked at only the TEST database. I thought we should be safe and it's a big sigh of relief on my part.
> I am not in IT, so please forgive me if this sounds dumb, but I want to be sure...if we keep a similar setup of two separate servers if and when we upgrade to Epicor 9 -- we should still be safe, right?
>
> Sincerely,
> Stephen Schaefer
>
> Abrams Airborne
>
> --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> >
> > Sorry. Replace k with "". Or add
> > def var k as char no-undo.
> >
> > --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> > >
> > > If you can update the database, clear it out. It's just too dangerous otherwise. After a restore to Pilot/Test:
> > >
> > > disable triggers for load of favitems.
> > > for each favitems where favitems.appserverurl ne "". assign
> > > favitems.appserverurl = k
> > > favitems.companyid = k
> > > favitems.plantid = k.
> > > end.
> > > --- In vantage@yahoogroups.com, Mark Wonsil <mark_wonsil@> wrote:
> > > >
> > > >
> > > > I searched the tables for the appServerURL field in 9.04.504B and there are four tables that have it:
> > > >
> > > > SystemAgent
> > > > ExtCompany
> > > > FavItems
> > > > MenuTab
> > > >
> > > > SystemAgent makes sense since the Agent needs to know which appServer to connect. ExtCompany makes sense too for multi-plant operations. FavItems and MenuTab are personalizations.
> > > >
> > > > I understand Epicor's point on why it's there. The question is how to handle it when copying the database to another for testing. One option would be to create a customization on the SystemAgent program that displays a warning whenever the appServerURL changes. I might not use a BPM because those are stored outside the database and you'd have to make sure it was in the target database's BPMExec folder.
> > > >
> > > > Instead of a warning, one could craft some code that would prompt to delete FavItems and MenuItems that had the old appServerURL value or even do a Find | Replace for the old and new values. I'm not sure that this would work if you were truly multi-plant/company and that you might not change the wrong records accidentally. That would take some further research from those who have those capabilites.
> > > >
> > > > Mark W.
> > > >
> > >
> >
>
As Chris stated, putting test on a seperate server will not resolve the issue. The server name, and port is hard coded in the favorite record.
We are getting a couple of different stories on this from Epicor. On one hand we have been told that favorites will change drastically in 9.05, and this won't be an issue. On the other hand, we have been told that development won't be changing this. We were told last night that they will be adding a conversion that will need to be run everytime you restore the db to your test environment. The conversion will either replace the path in the favorites, or delete them all together. WE BETTER NOT FORGET TO RUN THAT CONVERSION!
Craig

--- In vantage@yahoogroups.com, "chris_robisch" <bluewine@...> wrote:
>
> Here's one of the culprit records:
>
> "CRobisch" 1 23 "MfgSysProgram" "GLRP4040" "Book Listing" "" "GLRP4040" "" 21 "fda53f43-a691-3582-df11-021f76ee7733" 100520000 "AppServerDC://EPIC2:9001" "BMS26627" "MfgSys" 0
>
> You'll note it has our server-name:port, EPIC2:9001, so NO, you're not okay. It'll prompt for a name/password and if the user enters it, they're in Live city!
>
> --- In vantage@yahoogroups.com, "Snake" <sschaefer323@> wrote:
> >
> > I just had a chance to test this situation. I don't personally use shortcuts - being from the consulting world - old habits, so I had to find a user that i could test this with.
> > We are still on Vantage 8.03.408B.
> > We have our LIVE and TEST databases on two separate servers.
> > When I used a shortcut in our TEST database - it looked at only the TEST database. I thought we should be safe and it's a big sigh of relief on my part.
> > I am not in IT, so please forgive me if this sounds dumb, but I want to be sure...if we keep a similar setup of two separate servers if and when we upgrade to Epicor 9 -- we should still be safe, right?
> >
> > Sincerely,
> > Stephen Schaefer
> >
> > Abrams Airborne
> >
> > --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> > >
> > > Sorry. Replace k with "". Or add
> > > def var k as char no-undo.
> > >
> > > --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> > > >
> > > > If you can update the database, clear it out. It's just too dangerous otherwise. After a restore to Pilot/Test:
> > > >
> > > > disable triggers for load of favitems.
> > > > for each favitems where favitems.appserverurl ne "". assign
> > > > favitems.appserverurl = k
> > > > favitems.companyid = k
> > > > favitems.plantid = k.
> > > > end.
> > > > --- In vantage@yahoogroups.com, Mark Wonsil <mark_wonsil@> wrote:
> > > > >
> > > > >
> > > > > I searched the tables for the appServerURL field in 9.04.504B and there are four tables that have it:
> > > > >
> > > > > SystemAgent
> > > > > ExtCompany
> > > > > FavItems
> > > > > MenuTab
> > > > >
> > > > > SystemAgent makes sense since the Agent needs to know which appServer to connect. ExtCompany makes sense too for multi-plant operations. FavItems and MenuTab are personalizations.
> > > > >
> > > > > I understand Epicor's point on why it's there. The question is how to handle it when copying the database to another for testing. One option would be to create a customization on the SystemAgent program that displays a warning whenever the appServerURL changes. I might not use a BPM because those are stored outside the database and you'd have to make sure it was in the target database's BPMExec folder.
> > > > >
> > > > > Instead of a warning, one could craft some code that would prompt to delete FavItems and MenuItems that had the old appServerURL value or even do a Find | Replace for the old and new values. I'm not sure that this would work if you were truly multi-plant/company and that you might not change the wrong records accidentally. That would take some further research from those who have those capabilites.
> > > > >
> > > > > Mark W.
> > > > >
> > > >
> > >
> >
>
That's it -- no more Favorites! Just kidding - my users would hang me if I said that, but I am thinking the long way may not be so bad after all.....Â

It sounds as this would be a constant monitoring situation because a User could create a Favorite at any time throughout the day.
I don't know if it is this easy but if you could somehow trigger a warning if the path for the Favorite created does not match the path for the current login. That would at least warn the User that they are about to make FUBAR.
Sincerely,


Stephen Schaefer
Abrams AirborneÂ

[Non-text portions of this message have been removed]
>It sounds as this would be a constant monitoring situation because a User could create a Favorite at any time
> throughout the day. I don't know if it is this easy but if you could somehow trigger a warning if the path for the
> Favorite created does not match the path for the current login. That would at least warn the User that they are
> about to make FUBAR.

The user will get a Login Form if they click on a favorite that crosses databases and that's a pretty good warning.

However, does it do it for every launch of that program or is one login good for the other Favorites?

Mark W.
Epicor has created a BPM procedure to address this issue and has published a
document explaining how the BPM works. You can contact Epicor 9 Technical
Support and request document 11422MPS or search for it on EPICweb.



Regards,
Scott



_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Mark Wonsil
Sent: Thursday, March 25, 2010 3:27 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] E9 Dangerous Issue with Favorites



>It sounds as this would be a constant monitoring situation because a User
could create a Favorite at any time
> throughout the day. I don't know if it is this easy but if you could
somehow trigger a warning if the path for the
> Favorite created does not match the path for the current login. That would
at least warn the User that they are
> about to make FUBAR.

The user will get a Login Form if they click on a favorite that crosses
databases and that's a pretty good warning.

However, does it do it for every launch of that program or is one login good
for the other Favorites?

Mark W.





[Non-text portions of this message have been removed]