This question might have two different answers, one being a customization and the other being a setting in Time Management I haven’t found.
We just purchased Time Management so that we can approve all time detail records to be compliant with a DCAA audit. Part of the requirement is that Supervisor/approvers can’t delete or adjust the time record. This will require each employee to have access to Time & Expense Entry to make any needed adjustments. However, they can only have access to their time records and not other employee’s records.
In the Time Management settings, you can restrict access for entering/editing time transactions for other employees. However, that does not stop someone from being able to look at others records.
So I thought I would remove the employee search button from the T&E Entry form and make the EmpID fields read-only; however, there is still the search button in the tool bar that allows you to search…
Is there a setting I’m missing? Or is there a way through Screen customizations to disable the search button in the tool bar?
I think you should be able to use Form Event Wizard and beforeToolClick and handle that button. I don’t know off the top of my head how to determine what tool clicked but once you find out:
You will need to add a using statement (using Infragistics.Win.UltraWinToolbars;). I have used this to disable delete, etc. but not this exact toolbar item.
@nhutchins Below are the code snippets you can add so that when someone right-clicks the employee field in Time and Expense entry it will disable the Open With… context menu.
1. Add the following to the method public void InitializeCustomCode()
private void EpiContextToolsManager_AfterBuildContextMenu(object sender, ContextToolEventArgs e)
{
foreach (Infragistics.Win.UltraWinToolbars.ToolBase tool in e.ContextMenuPopup.Tools)
{
/* Looks for the caption that states Open With... and the called from Control (txtEmpNum) */
if (tool.SharedProps.Caption == "Open With..." && e.ContextBinding.Control.Name == "txtEmpNum")
{
tool.SharedProps.Enabled = false;
}
else
{
tool.SharedProps.Enabled = true;
}
}
}
3. Add the following to the method public void DestroyCustomCode() EpiContextToolsManager.AfterBuildContextMenu -=new ContextToolHandler(EpiContextToolsManager_AfterBuildContextMenu);
under user account maint (company tab) there are two tick boxes that grant access to be able to change time/expenses for all employees. I would assume if these are not ticked then they should not have access to do so… never tried it as this option is not widely available at my company
Great to hear @nhutchins. I am curious about one thing, just for my own sanity. Was txtEmpID a custom control you added or was this from the standard form? The reason I ask is that I checked 10.1.400 - 10.1.600 and the control name was txtEmpNum.
oops, you are correct. I forgot that I had added the custom control when I was tried to make the standard field read-only. I actually don’t need the custom one anymore.
Because of the way T & E entry works you can make the Employee ID field read-only, but only if you associate users - employees (one to one). If you have this association the screen could load and default in the employee number and make the field as read-only. This would prevent an employee from viewing other records. The customization involved to do this would be minor as you would need to trap an event on EpiViewNotification/LaborEquip view, I believe, to get read-only on this field to stick.
OK, just thinking out loud here. In the trace, determine the business objects used to search time (Labor.getRows, whatever.) and either do a pre-process BPM that alters the where-clause to add a selection that filters for the current employee ID. Next, create a security group that says “If not member of group…” then add your admins/supervisors to the group to be able to see all employee activity. The bonus will be it will work regardless of the user interface (web or smart client, REST, service connect, …)
The only bit of hesitation I would have with any approach is how the employee - user relationship is setup. Sometimes I have seen a single user setup (i.e.shopfloor) and all production employees use that account as their login and do not really have a unique associated user. This could cause a headache because you could not determine the current employee id. I also have had issues with unintended collateral damage with some of the methods within the T & E process since, for example, an employee may want to use some of the functionality in Shop Tracker which does use some of the same methods as T & E. You may, whether desired or not, prevent this. This seems like it could have the potential to become much larger.
Good points Dan. For our MES users, we indeed use shared user logins. But then again, they’re not in TE as the problem indicates.
Would not employee setup be an issue for the Customization solution as well? How will Epicor know the employee ID of the user running TE Entry?
And a big yes, one must check the downstream events a directive may cause! That is always an issue when using Business Process Management or Security settings at an object or field level. One might be able to limit the action by passing a context so the BPM only executes when run from TE Entry.
Again, excellent thoughts. It’s why I really enjoy this group!
