Loss of Page Customization Upon Logout

We have noticed that the persistent user modifications on pages stored in cookies are lost when a user is logged out intentionally or not. This is not ideal when users who do not have page editing privileges are spending their timing customizing their views. This is directly affecting our Shotgun adoption rate within the studio.

We are sure that you are aware of this issue and that this choice might be deliberate on your end, but as it is affecting our users' experience.

We definitely want our pages to be curated and avoid having artists create their own as it will disconnect them from the ones we provide. Of course, we are trying to design these pages to satisfy everyone's needs, but there are always edge cases. That is when the user cookie stored modifications come into play. Users understand and love this mechanism that gives them some control over what they see and the ability to revert their changes at any time. On the other hand, having those modifications dropped when logged out, always comes as confusing and has been described so far as a "Shotgun Bug".

If the goal of the cookie drop on logout is to provide a feature to force artists to lose their local changes, then it should probably be implemented as an administrator Action Menu Items on pages and not automatically enforced. This would allow administrators to be in control over when they want this to happen instead of having it forced on the users.

6 comments

Thanks for the detailed breakdown of your use case! I can see how this is frustrating for some of your users.

The way the system currently works is any changes made to a page which are not saved are temporary and tied to that user's login session. This means they do not persist when that user logs out.

Like you noted, there are always edge cases to this where users need to tweak and modify things more to their liking. To account for this sort of workflow, users can take any page and perform a "Save As" operation to save their own copy of it which they can modify (and save) to their heart's content. This way they can get their persistent changes without impacting the page you've carefully designed for the rest of the studio.

Let me know if that helps explain how the system currently works or if you need any further clarification.

Thanks for your comment Brandon. I think the only problem we have with the "Save As" approach is that it disconnects the users entirely from our curated pages, ending in a maze of user-created pages that end up being confusing in other ways. Talking to the support team it seemed that dropping the page customization cookies upon user login out was a deliberate choice and not a technical limitation. I maintain the idea that I find this a strange default behavior.

Totally agree with Douglas' assessment, we have exactly the same issues. Our hundreds of users want to start from our carefully constructed pages that represent default studio workflow, and occasionally riff on those pages while always being able to get back to the default AND stay current with new changes (filter adjustments, new columns, etc). They don't want to go off the reservation, they just want their personalized settings to persist.

It's frustrating because I know the per-user customizations are being stored in the database in PageSetting entities, not just with cookies. I understand that dropping a PageSetting via log-out can be one way for a user to "recover" if they've totally messed-up a page and can no longer get to the Revert Page option -- but maybe there's a better solution that could ensure a user can *always* get to Revert Page to recover, in which case logging-out doesn't have to be conflated with "fix / revert", and thus saving per-user customization PageSettings could persist across log-in/log-out sessions.

Obviously, it's easy for me to toss such ideas from out here in the peanut gallery. Please just take this as a user-story / constructive feedback. Cheers!

Thanks for the added info guys. You're correct, the current system was a deliberate choice with the "save as" functionality serving as the solution for users who felt like they needed their own custom view of a shared/public page. That all being said, this was implemented many many years ago, and there is always room for improvement to the experience.

@Douglas - It sounds like your main concern is these users getting disconnected from the curated pages. How would you expect a user who has customized a curated page to continue to receive updates (i.e. stay connected) to that curated page if we always persist the changes that user has made? Would you want some sort of Admin ability to forcibly push changes out to override customizations on demand? Or just always leave it up to the user to decide when they want to "revert" to the default layout? I'm trying to crystalize an ideal workflow to "stay connected" while also maintaining personal changes.

Simply storing the changes the user made seems like the more elegant solution. For instance, if someone added a couple columns, Shotgun would be able to reference the curated pages and simply add the two columns regardless of the changes to the curated page.

Alternatively, if a more general approach is chosen where the entire state of the page is stored in the cookies as soon as there is a change, then the ability for Administrator to force users to lose their customization on a specific page will start to matter.