View Only
  • 1.  Avoid overwriting user's custom view when publishing new view

    Posted Aug 09, 2012 01:07 PM
    Unknowingly, some users have customized their default view of the Project object, but at the same time we received requests for additional fields and updated field names in the default view of the Project object's filter list, project list, and project properties. This required to do a "publish" so that all users could see the updated fields. This had the undesirable side-effect of overwriting the customized views of some users that they had saved. This seems like a design flaw in the way views are updated unless I am missing something. Is there a way to publish views without compromising any customized views that users already have in place? Or are we forced to ask them to reconfigure their view every time something changes?

  • 2.  RE: Avoid overwriting user's custom view when publishing new view
    Best Answer

    Posted Aug 10, 2012 06:37 AM
    Short answer: If you want users to have the choice on whether to accept the changes you make or continue using their own configurations, then this is the approach you'd need: "... ask them to reconfigure their view every time something changes?"

    Here's the thing - users who haven't yet personalized their views are already using the system (administrator configured via Studio) version of the view. If you change the configuration of that view in Studio under the Admin Tool, all those users will automatically get those new changes without any publish taking place.

    Only the users who have configured their own versions of the view (and so now are using a 'user' version of the view) will not see them - UNLESS you publish or they themselves Restore to Defaults, which essentially is an action to remove their custom view so that they fall back to the system view you (recently) configured and everyone else is using.

    So it sounds to me like you just need(ed) to make the changes, and then advise users to either pick up the new fields in their own custom views if they want them, or they can selectively choose to Restore to Defaults by themselves in order to do an isolated form of publish. Then any users who just prefer to keep their own custom changes will be left alone.

    This only works to a point; if you make fundamental changes to existing fields (deactivating or otherwise changing their definitions such as making them hidden/required in filters), that might necessitate a Publish since the old format of the attribute would not be compatible with the user's current filter and list views, and so the custom ones need to be dropped. Adding and configuring new attributes though wouldn't enforce that action.