2 of 2 people found this helpful
Of course make a backup before attempting any such change in the backend.
Solutions are housed in the _SOLUTION_ table. When they are created and saved to the database, it commits the transaction with a value in the field _GROUP_.
Therefore, if a technician is a member of more than one group, whichever role they are logged into Track-It! at the time, will determine what value is populated into the _GROUP_ field.
By default, there are two groups created: SYSTEM ADMINISTRATION (1) and HELP DESK (2). These are in the _GROUPS_ table.
So if a technician is logged into Track-It! with the SYSTEM ADMINISTRATION role and creates a solution, then the record will write the _GROUP_ field with 1, and the LASTUSER field with their LOGIN. If someone logged in with another role (e.g. HELP DESK) and edited this solution, then the LASTUSER would update with their LOGIN but the _GROUP_ would stay at 1 (and not change to 2).
I would suggest if you are to test this, then just change one record first. And if successful, then update the rest or roll back. Once again, make a back up before making any changes.
Perfect. Since our DBAs are consumed on other work right now, I opted to go another route. While reading through your solution, it dawned on me that the group permissions could be altered in the segregation utility.
It does not fix the issue, like your solution, but it makes it workable for now. I used the segregation tool and I updated the groups that I didn't want to see the solutions created by the SysAdmin.
This handled my immediate needs, and I've put your solution in the DBAs queue for when they can get to it.
Thank you very much,
Many thanks for the update and feedback.
I'm delighted that you have a workable solution in place and that the solution I provided will enable your DBA team to review and hopefully implement.