Home› Analyst Portal

WorkItem Table empty after Truncate

Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭
in Analyst Portal

We are running version 11.6 of the portal.

Today we encountered a problem - The affected user of an Incident was only able to see the incident as it was archived. Which is a bit strange, as I thought the affected user always has scoped access to his/her work items.


The real problem started, when I truncated the LastModified and WorkItem Table + restarted the Cachebuilder. Although the cachebuilder logs shows no errors and the "Running WorkItemCommand Update" is running, the WorkItem table stays completely empty. So all workitems are shown as archived abd cannot be edited. They exist in the SCSM database though.

This is really critical as we want to go productive next week - Has anyone encountered such a problem before?

Answers

  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭

    Hi @Simon_Zeinhofer

    Are the work items Resolved or Closed?

    If they are Closed then the user will not have access to edit them anymore as they are closed off.

    if the item is Resolved, then it's saying that the service desk thinks the issue is done but are waiting either confirmation or a set period of time to see if it re-occurs. If it does, then the end user can open the ticket and make additional comments ready for the ticket to be re-opened or Closed (Archived)

    Check the status of the work items to make sure they are actually active or not.

    Hope this helps

    Brett

  • Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭
    edited July 2022

    @Brett_Moffett They are active - That's why it seems so strange.

    Is it necessary to give all users read rights to all incidents, so they also have access to these where they are affected users? Because we do not have that atm.


    Do you have an idea for the second issue with the workitem table?

    I have to add: New workitems are synced, so it seems like the lastmodified has no effect

  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭

    @Simon_Zeinhofer

    You are right that an affected user, by default, has scoped access to their own work items. You should NOT need to give end users access to all work items.

    The WorkItem table in the ServiceManagement DB should have items in it.

    If it doesn't then the portal would not be able to show any items in any grid view as that is where the My Work, Team Work and the like.

    Turn up the logging for Cache Builder and you should see it copying Work Items over to the database.

    If that doesn't show anything, log a support call. It should be working better than that.

    Brett

  • Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭

    @Brett_Moffett

    We tested it with a new incident and it works without any problems. So maybe there are some issues with the workitem table sync, which also led to this behaviour.

    I activated the cachebuilder logging and unfortunately, only those workitems are copied, which are CREATED after the TRUNCATE of the table. It seems like truncating the lastmodified table has no effect. The last modified for the workitems also gets immediately set after the cachebuilder restart - is that as it shouold be?

    I already opened a support case some minutes ago, I just thought maybe someone in the community has seen that before :)

    Thank you for for help!

  • Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭

    @Brett_Moffett The issue has been solved by Justin Workman - Stopping the cachebuilder for 2 minutes, truncating the last modified table and afterwards starting the CB again did the trick.


    I also read about the cachebuilder needing some time to really shut down in another community thread, but it would be amazing if you could add that inside a KB article :)

Sign In or Register to comment.