Has anyone experienced the condition where in Employee Maintenance, the User Name binding, under the Production Info tab, does not stick? You can choose one, save. No errors. Go to a different tab or refresh and that field becomes unset again (“None Selected”). I have not encountered this before and cannot find any issues within say the config file for this particular appserver.
We are currently experiencing the same issue. It only seems to be happening on one User Name but the others seemed to save correctly. Were you ever able to resolve this issue?
Hi Chia,
I cannot remember exactly. I do not have access to those records any longer either - changed employer.
Perhaps it was for a new user and so it came down to deleting the userID and starting again. The only other user-specific issues I’ve dealt with ‘in system’ have been with personalizations, but I cannot think of a correlation in practice
to Employee and UserID based-personalizations…
Review that too and see if you can see a personalization related to MES or one of the other Employee production tools (remove it)?
I am sorry I cannot remember further.
Best,
Henry
We had the same problem with one of our users. Interestingly, right clicking the username dropdown list and selecting “Refresh List” showed the correct user, but that reverted back to “None Selected” on a reload.
What worked for us was changing some other employee details (we used the employee name), saving, changing it back, and saving again.
I tried your steps and it still did not save and reverts back to None Selected. Other employees can select the username and it works. The employee can select other usernames and it works except that one.
Is this just a display issue or is the value for user ID not being saved in EmpBasic at all?
It seems to be a display issue because when I did a BAQ against the EmpBasic table, it displays correctly. I would have expected it to happen to all other usernames but it seems to be an issue with this specific username for this employee.
I’m afraid I don’t have anything else. We saw all the behaviour that you’re noticing, and the save trick was the only thing that worked (data model regen didn’t work, couldn’t reproduce this in a replicated environment). It was chalked up to a DB glitch, and by saving some other data in EmpBasic, it “refreshed” the DB.
We found out that we needed to make a change in the Username ID instead, save it and then repull it into Employee Maintenance the Person ID again in order for it to default in correctly to be saved. For some reason, the DB needed to be refreshed from the Username ID being resaved. Thanks!
I’m an idiot. It’s like you saw, the change needs to be made to the user, not the employee. This is what I get for relying on my memory lol
1 Like
Hey Tanesh,
You solved it and reported back at least - thank you! I’m the one who forgot how I fixed it.
Funny long story short - a coworker was encountering this same peculiar issue, searched EpicUsers, found my post and came and harassed me (in jest) about how to fix his issue with a set of users/employees and I still couldn’t remember. He figured it out as we discussed it, and I was returning here to finally fill in the answer , and I find you beat me to it! So I am very glad you persisted and found the trick that breaks this issue free - Make any small change to the UserID in User Account Security Maintenance and then try to bind again the EmployeeID to the UserID and it works as normal.
I would love to know how this gets bound up under the surface in the DB if anyone ever determines that part of this issue.
FWIW, support didn’t know why this happened either when we raised the issue all those years ago. There’s an article somewhere on EpicCare that describes the problem with the same fix you mentioned, but there was no root cause listed last I checked.