Possible bug: locked widgets on user dashboard "disappear" after 10.1.x upgrade

Hi there,

One of our users invested considerable time adding content to her user dashboard page (not the default global one) with Generic Content widgets in our 10.0.2 installation. At some point, she locked all of these widgets. I can only assume she thought doing so would help preserve them, making this all the more ironic. 

Following an upgrade to 10.1.4 last week, none of the customized widgets on her user dashboard page could be displayed when viewing or editing the page layout. 

My question: during an upgrade, is permanent hiding of locked widgets on customized user dashboard pages by design or is this a potential bug?

After comparing to a known good user dashboard page, I was able to restore her "lost" widgets by updating widget records for her "common-home" page in the cs_ConfiguredContentFragments table, where the IsLocked column was changed from "1" to "0". While I was there, I spotted 20 other users with the same configuration who will likely experience the same hiding behavior.

Thanks for listening!

Parents
  • My question: during an upgrade, is permanent hiding of locked widgets on customized user dashboard pages by design or is this a potential bug?

    The locking behavior is by design, but the effect that it had on your users is not. When we render a contextual page (vs. a default page), we merge the contextual page onto the default page. This is when locked widgets are ensured to be on the contextual page and only locked widgets from the default page are forced onto the contextual page. If there are locked widgets on the contextual page that do not exist on the default page, they are now removed because the assumption is that the reason the widget would have been present is removed (the widget is no longer locked on the default page).

    What is odd is that, in your user's situation, the user was able to lock the widgets at all. In the page editing experience, locking is not exposed when editing anything but the default version of the page (headers/footers are slightly different in that they also support locking contextually to apply to child themes... but the content of pages does not support contextual locking).

    In short, while the end result was as designed, I'm unsure how your users got into the situation where they had locked widgets on their contextual version of the page when they never were using the default version of the page.

    Your workaround, unlocking the widgets manually in the database, is what I would have suggested to alleviate the issue. Note that contextual pages that have locked widgets that are also locked on the default page are valid.

    Is there anything I can do to help alleviate the issue? 

Reply
  • My question: during an upgrade, is permanent hiding of locked widgets on customized user dashboard pages by design or is this a potential bug?

    The locking behavior is by design, but the effect that it had on your users is not. When we render a contextual page (vs. a default page), we merge the contextual page onto the default page. This is when locked widgets are ensured to be on the contextual page and only locked widgets from the default page are forced onto the contextual page. If there are locked widgets on the contextual page that do not exist on the default page, they are now removed because the assumption is that the reason the widget would have been present is removed (the widget is no longer locked on the default page).

    What is odd is that, in your user's situation, the user was able to lock the widgets at all. In the page editing experience, locking is not exposed when editing anything but the default version of the page (headers/footers are slightly different in that they also support locking contextually to apply to child themes... but the content of pages does not support contextual locking).

    In short, while the end result was as designed, I'm unsure how your users got into the situation where they had locked widgets on their contextual version of the page when they never were using the default version of the page.

    Your workaround, unlocking the widgets manually in the database, is what I would have suggested to alleviate the issue. Note that contextual pages that have locked widgets that are also locked on the default page are valid.

    Is there anything I can do to help alleviate the issue? 

Children