Clarity

  • 1.  Best Practices for Migrating Portlet Configurations

    Posted Jun 08, 2012 03:52 PM
    We have a desire to push out standard portlet configurations to users, so that the filters, column headings, and layouts are the same. What is the best way to do this, taking into account that we'd like to have these changes on our Dev, Test and Production instances?


  • 2.  RE: Best Practices for Migrating Portlet Configurations

    Posted Jun 11, 2012 11:57 AM
    Roberts,

    You can make the desired changes in Studio and "Publish", but this will wipe out all the personal configuration the users have configured for themselves.

    However, you can find out how many users have configured their portlets personally through backend.

    If the no one has configured it personally you are good to go.

    If very less number of users configured, you can either ignore them or request them to re-configure.

    If large number of users have personally configured then you have to take a stand.

    Regards,
    Mathan


  • 3.  RE: Best Practices for Migrating Portlet Configurations

    Posted Jun 11, 2012 12:01 PM
    What you have described is just doing the configuration straight in production. My question was more about migrating configurations between test and prod. Maybe it's just unnecessary. What do you all think?


  • 4.  RE: Best Practices for Migrating Portlet Configurations

    Posted Jun 12, 2012 02:50 AM
    "We have a desire to push out standard portlet configurations to users, so that the filters, column headings, and layouts are the same. What is the best way to do this, taking into account that we'd like to have these changes on our Dev, Test and Production instances? "

    Can you elaborate on the above ?

    My understanding would be - let's say you need to add a column to a portlet, which is used by the users (who have made different personal configurations). now you want the portlet to be available to the users, without disrupting their personalizations.

    Have you tried the following ? 1. xog out the portlet ... 2. change the query part ... 3. xog the portlet back in ... 4. make the desired header changes ... 5. just save (do not publish), this way, the newly added fields (if you have added new fields), will be available to the users, and you will not disrupt the user's configurations. The only hiccup would be if a newly added field needs to be made available by-default. In that case, you will have to publish the portlet (no other option)...

    My suggestion would be not to publish (if you are concerned about the users' personalisations)

    NJ


  • 5.  RE: Best Practices for Migrating Portlet Configurations

    Posted Jul 26, 2012 04:26 AM
    Hi,
    How can I find out who and how many have configured their portlets personally?

    Regards
    Jens-Erik


  • 6.  RE: Best Practices for Migrating Portlet Configurations
    Best Answer

    Posted Jul 26, 2012 04:38 AM
    You can use the "Views" functionality in the admin tool to see which portlets/views have been personalised, but that does not tell you who has personalised them.
    EDIT : actually I think that ^ is only for object Views not portlets - sorry! :*)

    --

    But if you look on the underlying database;

    Portlet LIST configurations are in the CMN_GRIDS table.
    Portlet FILTER configurations are in the ODF_VIEWS table. ( the code on that table is the portlet id)


  • 7.  RE: Best Practices for Migrating Portlet Configurations

    Posted Jul 26, 2012 08:37 AM
    Thanks :smile


  • 8.  RE: Best Practices for Migrating Portlet Configurations

    Posted Jul 26, 2012 08:47 AM
    You are getting dobule posts. Which browser are you using?

    Martti K.


  • 9.  RE: Best Practices for Migrating Portlet Configurations

    Posted Jul 26, 2012 08:53 AM
    IE9 with IE9 standard mode (F12)