EmpBasic.LaborRate

Yahoo Archive
1
Too bad, then Field Security doesn't seem very useful if that's the case.

We use SQL Server, and all reports use stored procedures where I pick exactly what fields are exposed. No one has ODBC connection.

I do not believe that the empbasic table was designed to store anything sensitive, unlike prempmas.
We don't use that field, at any rate.

Sorry I couldn't help.









________________________________
From: saab_barracuda <chris.clunn@...>
To: vantage@yahoogroups.com
Sent: Monday, November 17, 2008 8:45:25 AM
Subject: [Vantage] Re: EmpBasic.LaborRate


This might keep it from showing on the Shop Employee Tracker but
probably wouldn't keep the individual labor costs from printing out on
the Production Detail Report. Field Security definitely wouldn't
change anything for the ODBC connection.

--- In vantage@yahoogroups .com, Tony Hughes <thughes281@ ...> wrote:
>
> would Field Security work for you?
>
> System Management > Security Maintenance > Field Security, you can
set field by field security.
>
>
>
>
>
> ____________ _________ _________ __
> From: adam.whipp <adam.whipp@ ...>
> To: vantage@yahoogroups .com
> Sent: Friday, November 14, 2008 4:10:29 PM
> Subject: [Vantage] Re: EmpBasic.LaborRate
>
>
> We are on 8.03.405A
>
> --- In vantage@yahoogroups .com, Tony Hughes <thughes281@ ...> wrote:
> >
> > what version of Vantage?
> >
> >
> >
> >
> >
> >
> > ____________ _________ _________ __
> > From: adam.whipp <adam.whipp@ ...>
> > To: vantage@yahoogroups .com
> > Sent: Friday, November 14, 2008 9:15:10 AM
> > Subject: [Vantage] Re: EmpBasic.LaborRate
> >
> >
> > Thanks for the input Jeff. However, what I am concerned about is
> > people connecting through ODBC for Crystal. If I am not mistaken,
> if
> > we set a user up to connect through ODBC with Cystal, that user can
> > write reports against any table in the database. Is there any way
> to
> > prevent that? I don't know of a way to limit access to certain
> > tables through ODBC. Thanks in advance,
> >
> > Adam
> >
> > --- In vantage@yahoogroups .com, "jplehr" <jlehr@> wrote:
> > >
> > > --- In vantage@yahoogroups .com, "adam.whipp" <adam.whipp@ >
> wrote:
> > > >
> > > > Hello,
> > > >
> > > > In our company, we keep everyone's actual pay rate in the
> > > > EmpBasic.LaborRate field. This of course is a security risk
> > > because
> > > > anyone can report against the EmpBasic table and find out
> > someone's
> > > > true labor rate. I was wondering how other companies handle
> this
> > > field
> > > > to keep it more secure. I have heard of some companies using
> an
> > > > average based on job function (e.g. all welders could be
> $10.00,
> > > > brazers $11.00, etc). Does anyone have any other suggestions?
> > > Thanks,
> > > >
> > > > Adam Whipp
> > > >
> > >
> > > Adam,
> > >
> > > We use the average practice based on job function. Plus, I don't
> > > have anyone esle with the ability to get to these tables unless
> > they
> > > were a part of the appropriate Security Group.
> > >
> > > Jeff
> > >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>






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

In our company, we keep everyone's actual pay rate in the
EmpBasic.LaborRate field. This of course is a security risk because
anyone can report against the EmpBasic table and find out someone's
true labor rate. I was wondering how other companies handle this field
to keep it more secure. I have heard of some companies using an
average based on job function (e.g. all welders could be $10.00,
brazers $11.00, etc). Does anyone have any other suggestions? Thanks,

Adam Whipp
3
--- In vantage@yahoogroups.com, "adam.whipp" <adam.whipp@...> wrote:
>
> Hello,
>
> In our company, we keep everyone's actual pay rate in the
> EmpBasic.LaborRate field. This of course is a security risk
because
> anyone can report against the EmpBasic table and find out someone's
> true labor rate. I was wondering how other companies handle this
field
> to keep it more secure. I have heard of some companies using an
> average based on job function (e.g. all welders could be $10.00,
> brazers $11.00, etc). Does anyone have any other suggestions?
Thanks,
>
> Adam Whipp
>

Adam,

We use the average practice based on job function. Plus, I don't
have anyone esle with the ability to get to these tables unless they
were a part of the appropriate Security Group.

Jeff
4
Thanks for the input Jeff. However, what I am concerned about is
people connecting through ODBC for Crystal. If I am not mistaken, if
we set a user up to connect through ODBC with Cystal, that user can
write reports against any table in the database. Is there any way to
prevent that? I don't know of a way to limit access to certain
tables through ODBC. Thanks in advance,

Adam

--- In vantage@yahoogroups.com, "jplehr" <jlehr@...> wrote:
>
> --- In vantage@yahoogroups.com, "adam.whipp" <adam.whipp@> wrote:
> >
> > Hello,
> >
> > In our company, we keep everyone's actual pay rate in the
> > EmpBasic.LaborRate field. This of course is a security risk
> because
> > anyone can report against the EmpBasic table and find out
someone's
> > true labor rate. I was wondering how other companies handle this
> field
> > to keep it more secure. I have heard of some companies using an
> > average based on job function (e.g. all welders could be $10.00,
> > brazers $11.00, etc). Does anyone have any other suggestions?
> Thanks,
> >
> > Adam Whipp
> >
>
> Adam,
>
> We use the average practice based on job function. Plus, I don't
> have anyone esle with the ability to get to these tables unless
they
> were a part of the appropriate Security Group.
>
> Jeff
>
5
Yes, that is correct Adam. That is why when we installed V8, we did
not give anyone the ODBC drivers. No one in our organization will be
able to write a Crystal Report using ODBC because the drivers are not
on anyone's computer. Everyone will have to use Crystal with BAQ
Reports and hence the Vantage security is already in place for
everyone. When you use BAQ Reports the way Epicor intended, you
never need worry about people seeing report data for which they have
no privileges.

Lynn


--- In vantage@yahoogroups.com, "adam.whipp" <adam.whipp@...> wrote:
>
> Thanks for the input Jeff. However, what I am concerned about is
> people connecting through ODBC for Crystal. If I am not mistaken,
if
> we set a user up to connect through ODBC with Cystal, that user can
> write reports against any table in the database. Is there any way
to
> prevent that? I don't know of a way to limit access to certain
> tables through ODBC. Thanks in advance,
>
> Adam
>
> --- In vantage@yahoogroups.com, "jplehr" <jlehr@> wrote:
> >
> > --- In vantage@yahoogroups.com, "adam.whipp" <adam.whipp@> wrote:
> > >
> > > Hello,
> > >
> > > In our company, we keep everyone's actual pay rate in the
> > > EmpBasic.LaborRate field. This of course is a security risk
> > because
> > > anyone can report against the EmpBasic table and find out
> someone's
> > > true labor rate. I was wondering how other companies handle
this
> > field
> > > to keep it more secure. I have heard of some companies using
an
> > > average based on job function (e.g. all welders could be
$10.00,
> > > brazers $11.00, etc). Does anyone have any other suggestions?
> > Thanks,
> > >
> > > Adam Whipp
> > >
> >
> > Adam,
> >
> > We use the average practice based on job function. Plus, I don't
> > have anyone esle with the ability to get to these tables unless
> they
> > were a part of the appropriate Security Group.
> >
> > Jeff
> >
>
6
> Thanks for the input Jeff. However, what I am concerned about is
> people connecting through ODBC for Crystal. If I am not mistaken, if
> we set a user up to connect through ODBC with Cystal, that user can
> write reports against any table in the database. Is there any way to
> prevent that? I don't know of a way to limit access to certain
> tables through ODBC. Thanks in advance,

Yes you can. You can create a new database user with its own password and
grant only the tables that are required. I have an ODBCUSER that does not
contain any sensitive tables and I only granted SELECT access to those
tables. That prevents users from "accidentally" updating them if use Access
or some other SQL tool.

The ODBC kit shows how to create a user and which tables are granted access.
You just need to modify this for your needs. You can add several different
database users for your different requirements.

Mark W.
7
We also use labor rates based on average pay rate by job title.
Keeping labor rates separate from pay rates seems practical and easy
enough to implement. If you have the Payroll Module, only Payroll
Managers that have the proper Payroll Class access should need access
to the real pay rates.

Also, I agree about the security risks of ODBC if you don't have the
ODBCUSER setup with read-only and restricted table access. I wouldn't
let anyone use ODBC as the SYSPROGRESS user.


--- In vantage@yahoogroups.com, "adam.whipp" <adam.whipp@...> wrote:
>
> Hello,
>
> In our company, we keep everyone's actual pay rate in the
> EmpBasic.LaborRate field. This of course is a security risk because
> anyone can report against the EmpBasic table and find out someone's
> true labor rate. I was wondering how other companies handle this field
> to keep it more secure. I have heard of some companies using an
> average based on job function (e.g. all welders could be $10.00,
> brazers $11.00, etc). Does anyone have any other suggestions? Thanks,
>
> Adam Whipp
>
8
what version of Vantage?






________________________________
From: adam.whipp <adam.whipp@...>
To: vantage@yahoogroups.com
Sent: Friday, November 14, 2008 9:15:10 AM
Subject: [Vantage] Re: EmpBasic.LaborRate


Thanks for the input Jeff. However, what I am concerned about is
people connecting through ODBC for Crystal. If I am not mistaken, if
we set a user up to connect through ODBC with Cystal, that user can
write reports against any table in the database. Is there any way to
prevent that? I don't know of a way to limit access to certain
tables through ODBC. Thanks in advance,

Adam

--- In vantage@yahoogroups .com, "jplehr" <jlehr@...> wrote:
>
> --- In vantage@yahoogroups .com, "adam.whipp" <adam.whipp@ > wrote:
> >
> > Hello,
> >
> > In our company, we keep everyone's actual pay rate in the
> > EmpBasic.LaborRate field. This of course is a security risk
> because
> > anyone can report against the EmpBasic table and find out
someone's
> > true labor rate. I was wondering how other companies handle this
> field
> > to keep it more secure. I have heard of some companies using an
> > average based on job function (e.g. all welders could be $10.00,
> > brazers $11.00, etc). Does anyone have any other suggestions?
> Thanks,
> >
> > Adam Whipp
> >
>
> Adam,
>
> We use the average practice based on job function. Plus, I don't
> have anyone esle with the ability to get to these tables unless
they
> were a part of the appropriate Security Group.
>
> Jeff
>






[Non-text portions of this message have been removed]
9
We are on 8.03.405A

--- In vantage@yahoogroups.com, Tony Hughes <thughes281@...> wrote:
>
> what version of Vantage?
>
>
>
>
>
>
> ________________________________
> From: adam.whipp <adam.whipp@...>
> To: vantage@yahoogroups.com
> Sent: Friday, November 14, 2008 9:15:10 AM
> Subject: [Vantage] Re: EmpBasic.LaborRate
>
>
> Thanks for the input Jeff. However, what I am concerned about is
> people connecting through ODBC for Crystal. If I am not mistaken,
if
> we set a user up to connect through ODBC with Cystal, that user can
> write reports against any table in the database. Is there any way
to
> prevent that? I don't know of a way to limit access to certain
> tables through ODBC. Thanks in advance,
>
> Adam
>
> --- In vantage@yahoogroups .com, "jplehr" <jlehr@> wrote:
> >
> > --- In vantage@yahoogroups .com, "adam.whipp" <adam.whipp@ >
wrote:
> > >
> > > Hello,
> > >
> > > In our company, we keep everyone's actual pay rate in the
> > > EmpBasic.LaborRate field. This of course is a security risk
> > because
> > > anyone can report against the EmpBasic table and find out
> someone's
> > > true labor rate. I was wondering how other companies handle
this
> > field
> > > to keep it more secure. I have heard of some companies using
an
> > > average based on job function (e.g. all welders could be
$10.00,
> > > brazers $11.00, etc). Does anyone have any other suggestions?
> > Thanks,
> > >
> > > Adam Whipp
> > >
> >
> > Adam,
> >
> > We use the average practice based on job function. Plus, I don't
> > have anyone esle with the ability to get to these tables unless
> they
> > were a part of the appropriate Security Group.
> >
> > Jeff
> >
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
10
would Field Security work for you?

System Management > Security Maintenance > Field Security, you can set field by field security.





________________________________
From: adam.whipp <adam.whipp@...>
To: vantage@yahoogroups.com
Sent: Friday, November 14, 2008 4:10:29 PM
Subject: [Vantage] Re: EmpBasic.LaborRate


We are on 8.03.405A

--- In vantage@yahoogroups .com, Tony Hughes <thughes281@ ...> wrote:
>
> what version of Vantage?
>
>
>
>
>
>
> ____________ _________ _________ __
> From: adam.whipp <adam.whipp@ ...>
> To: vantage@yahoogroups .com
> Sent: Friday, November 14, 2008 9:15:10 AM
> Subject: [Vantage] Re: EmpBasic.LaborRate
>
>
> Thanks for the input Jeff. However, what I am concerned about is
> people connecting through ODBC for Crystal. If I am not mistaken,
if
> we set a user up to connect through ODBC with Cystal, that user can
> write reports against any table in the database. Is there any way
to
> prevent that? I don't know of a way to limit access to certain
> tables through ODBC. Thanks in advance,
>
> Adam
>
> --- In vantage@yahoogroups .com, "jplehr" <jlehr@> wrote:
> >
> > --- In vantage@yahoogroups .com, "adam.whipp" <adam.whipp@ >
wrote:
> > >
> > > Hello,
> > >
> > > In our company, we keep everyone's actual pay rate in the
> > > EmpBasic.LaborRate field. This of course is a security risk
> > because
> > > anyone can report against the EmpBasic table and find out
> someone's
> > > true labor rate. I was wondering how other companies handle
this
> > field
> > > to keep it more secure. I have heard of some companies using
an
> > > average based on job function (e.g. all welders could be
$10.00,
> > > brazers $11.00, etc). Does anyone have any other suggestions?
> > Thanks,
> > >
> > > Adam Whipp
> > >
> >
> > Adam,
> >
> > We use the average practice based on job function. Plus, I don't
> > have anyone esle with the ability to get to these tables unless
> they
> > were a part of the appropriate Security Group.
> >
> > Jeff
> >
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>






[Non-text portions of this message have been removed]
11
This might keep it from showing on the Shop Employee Tracker but
probably wouldn't keep the individual labor costs from printing out on
the Production Detail Report. Field Security definitely wouldn't
change anything for the ODBC connection.



--- In vantage@yahoogroups.com, Tony Hughes <thughes281@...> wrote:
>
> would Field Security work for you?
>
> System Management > Security Maintenance > Field Security, you can
set field by field security.
>
>
>
>
>
> ________________________________
> From: adam.whipp <adam.whipp@...>
> To: vantage@yahoogroups.com
> Sent: Friday, November 14, 2008 4:10:29 PM
> Subject: [Vantage] Re: EmpBasic.LaborRate
>
>
> We are on 8.03.405A
>
> --- In vantage@yahoogroups .com, Tony Hughes <thughes281@ ...> wrote:
> >
> > what version of Vantage?
> >
> >
> >
> >
> >
> >
> > ____________ _________ _________ __
> > From: adam.whipp <adam.whipp@ ...>
> > To: vantage@yahoogroups .com
> > Sent: Friday, November 14, 2008 9:15:10 AM
> > Subject: [Vantage] Re: EmpBasic.LaborRate
> >
> >
> > Thanks for the input Jeff. However, what I am concerned about is
> > people connecting through ODBC for Crystal. If I am not mistaken,
> if
> > we set a user up to connect through ODBC with Cystal, that user can
> > write reports against any table in the database. Is there any way
> to
> > prevent that? I don't know of a way to limit access to certain
> > tables through ODBC. Thanks in advance,
> >
> > Adam
> >
> > --- In vantage@yahoogroups .com, "jplehr" <jlehr@> wrote:
> > >
> > > --- In vantage@yahoogroups .com, "adam.whipp" <adam.whipp@ >
> wrote:
> > > >
> > > > Hello,
> > > >
> > > > In our company, we keep everyone's actual pay rate in the
> > > > EmpBasic.LaborRate field. This of course is a security risk
> > > because
> > > > anyone can report against the EmpBasic table and find out
> > someone's
> > > > true labor rate. I was wondering how other companies handle
> this
> > > field
> > > > to keep it more secure. I have heard of some companies using
> an
> > > > average based on job function (e.g. all welders could be
> $10.00,
> > > > brazers $11.00, etc). Does anyone have any other suggestions?
> > > Thanks,
> > > >
> > > > Adam Whipp
> > > >
> > >
> > > Adam,
> > >
> > > We use the average practice based on job function. Plus, I don't
> > > have anyone esle with the ability to get to these tables unless
> > they
> > > were a part of the appropriate Security Group.
> > >
> > > Jeff
> > >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>