Sage 100

 View Only
  • 1.  We had a client run into a disturbing situation re

    Posted 04-07-2016 12:34
    We had a client run into a disturbing situation recently. They had Assignee set up as a UDF in WT Class Maintenance and they had it being validated. They found with the validation turned on, it let them create a custom lookup when they did a lookup on Assignee in WT Entry. When looking at the fields for setting the custom lookup, they had access to pay rate fields. Needless to say, they WERE NOT happy. That made us go poking around and we found a similar situation when selecting employees for the Labor Report by Employee and the Employee Productivity Report. It also existed in Time Entry. They're running Sage 2015. JobOps support pointed the finger back to Sage but said they would fix it for us. Not sure how it's Sage's problem when all the screens are Jobops screens, but since I got a fix, I'll let it go. They ended up sending me 5 revised program files as well as a SW_LockPRALE utility that hid the custom lookup button on the report screens. Laura indicated they ""modified the standard Sage functionality of the Employee ALE lookup. For the 2015C and 2016B releases they created a Security Event in Role Maintenance for the JobOps module that allows customizations to employee lookup."" We also found we could create custom lookups and lock them through the Lookup Wizard that would hide the custom lookup button as well. It seemed we need to do that for both the PR_Employee Employee Master List-All and the PR_EmployeeLocked P/REmployee Masterfile, depending on where we kicked off the lookup wizard. It appears the Assignee issue didn't show up until 2015 but the issue existed with the reports back in 2014 as well. We're in the process of following up with the other clients who have payroll to make sure things get locked down.


  • 2.  RE: We had a client run into a disturbing situation re

    Posted 04-08-2016 09:30
    Good Information. Thanks for sharing. I have never come across this, probably because I don't have clients using JobOps and the Payroll Module together. And the majority of my clients use an Standard Cost Rate for Activity codes, not employee specific rates. Allowing someone to see employee pay rates from a JobOps lookup is a problem, but if the company is using Payroll. Allowing someone to see employee Social Security Numbers from a JobOps lookup is a bigger problem. Again, thanks for sharing.


  • 3.  RE: We had a client run into a disturbing situation re

    Posted 04-08-2016 13:07
    Too funny - **JobOps support pointed the finger back to Sage but said they would fix it for us.** This happened to me back in the day with another developer. I installed their enhancement one evening and the very next morning we encountered issues. So naturally, I called him first. He wanted to know why I thought it was his problem. ""Because it was working yesterday afternoon, I installed the enhancement and now it isn't working"" He flat out said it wasn't his problem and to call Sage. ""Really!!!"" So I called Sage and after spending an hour of frustration with them, THEY said it wasn't their problem either. So I called the MD back, told them what Sage said. He flat out denied that it was his problem but he would ""help"" me out. We connected, he looked around and it only took him five minutes to realize THEY didn't send the correct software.......... Why are programmers prone to denying they may have made a mistake??? Seems to be a genetic gene that they all have.