3 Replies Latest reply on Mar 13, 2012 4:15 AM by karenpeacock

    Copy Rules from Raise User not working after 7.5 Upgrade

    rjpchadwick Rookie

      I have performed an upgrade from 7.4 to 7.5. Mostly gone OK but the Copy Rules from Raise User are not working any more on my incident windows. Other copy rules do such as those from Configuration Items. I have checked the handlers, recreated the rules, checked copy related and copy related object are set to true, interestingly they weren't on the CI but the copy rule worked anyway. Have have trawled the forums but cannot find anything like this. Completely stumped now, can anyone help?

        • 1. Re: Copy Rules from Raise User not working after 7.5 Upgrade
          rjpchadwick Rookie

          Answered my own question after a bit more digging, the fields I was copying to were privelegabled. set "Is Priveligable" to  False and tried again and the values copy across. Not sure why the priveleges changed during the upgrade but it's working now.

          • 2. Re: Copy Rules from Raise User not working after 7.5 Upgrade

            Nice work - window copy rules should still have worked even if the attribute was privilegable.  I'd call that a bug, but I suspect you will be asked to raise an ER if you were to comment on it.

            • 3. Re: Copy Rules from Raise User not working after 7.5 Upgrade
              karenpeacock SupportEmployee



              Yes this could be a bug.  It does depend though on what you have set under "Default Privileges".  When you set the "Is Privilegeable?" to True a popup window appears that asks you to specify the privilege types (Read and/or Modify).  If you cancelled out of this dialogue or OK'ed without selecting anything then you can end up seeing the problem that you described.  If you suspect this is a bug then can I encourage you to please raise it with your support provider so they can work with you to get all the details to replicate it and then we can raise a problem record.  We review all new or updated problem records weekly with the Development team.


              In general: Something that stops working (regression) or that is functionality that doesn't work as documented then it is a bug.  If something is not yet implemented in the product then it needs to be raised as an ER.  When it is raised as an ER we can get more customer input on it (votes) so we ensure that we use our Development teams to implement the ERs that mean the most to our customers.  Without this it could be difficult to get this right, because of the configurable nature of Service Desk.  Sometimes the size of the work to get the ERs implemented means that they don't fit into the next release but it doesn't mean that they aren't on the radar to be done.  I know, for example, that as we speak we currently have developers working on one of the most popular ERs.


              In this case though, this definitely sounds like a configuration issue or a bug.


              Best wishes