Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1-dev
    • Fix Version/s: 2.1-dev, 2.1
    • Component/s: Portlet Registry
    • Labels:
      None

      Description

      Preferences should be user-specific on all pages.
      If User A comes to page /roles/X/x.psml, and stores a pref P1 on portlet x1, and then User B comes to page /roles/X/x.psml, and also stores a pref P1 on portlet x1, the prefs for those two users should be different.

      I am considering making this feature optional, but the problem is that the semantics are intrinsic in the data model.

        Activity

        David Sean Taylor created issue -
        Hide
        David Sean Taylor added a comment -

        From Aaron Evans:

        Portlet Preferences are not stored on a user by user basis.

        Looking in the database, it looks as though the preferences are being associated with the fragment ID for the portlet of the psml page.

        I am pretty sure that the intention of the portlet spec is to enable the storing of preferences on a user by user basis. But apparently this is not possible in jetspeed unless the user creates a new portal page?

        The data I see in the DB seems to support this:

        I login as user A, and I have a portlet preference for one of my report portlets called reportTimeZone. By default is set to US/Eastern.

        User A edits his portlet preferences and sets the reportTimeZone to be US/Pacific.

        Looking in the prefs_property_value table, can see the newly created value. It has node ID 2875 and value US/Pacific. The property name is 0, I assume that this is the index in the array if it were multi-valued.

        I then look in the prefs_node table for a row with node_id=2875. The row is present and the full path of the node is:

        /portlet_entity/reports-3/no-principal/preferences/reportTimeZone/values

        Note that reports-3 is the fragment ID for the portlet fragment in the psml page.

        However, instead of 'no-principal', I would have expected to see the user name of user A.

        So now I log in as user B and go to edit my portlet preferences and the value of the reportTimeZone preference is set to US/Pacific, not the default US/Eastern I would have expected.

        So I then, as user B, set the reportTimeZone to US/Central and update my preferences.

        Sure enough, it overwrites the value in the prefs_property_value table to US/Central.

        So, in order to get the behaviour I need, I would have to generate portal pages for each user and vary the id of the portlet fragment? This does not seem like a good solution to me.

        Further, in my environment, users are not permitted to create their own pages and customize them. I am simply providing a form in the doEdit method of my portlet to allow users to customize the behaviour of the portlet.

        So, in my environment, imagine I had a weather portlet on a portal page. If someone sets their preferred city to be Bangkok, then all users will get weather for Bangkok!

        This does not seem right to me...

        Show
        David Sean Taylor added a comment - From Aaron Evans: Portlet Preferences are not stored on a user by user basis. Looking in the database, it looks as though the preferences are being associated with the fragment ID for the portlet of the psml page. I am pretty sure that the intention of the portlet spec is to enable the storing of preferences on a user by user basis. But apparently this is not possible in jetspeed unless the user creates a new portal page? The data I see in the DB seems to support this: I login as user A, and I have a portlet preference for one of my report portlets called reportTimeZone. By default is set to US/Eastern. User A edits his portlet preferences and sets the reportTimeZone to be US/Pacific. Looking in the prefs_property_value table, can see the newly created value. It has node ID 2875 and value US/Pacific. The property name is 0, I assume that this is the index in the array if it were multi-valued. I then look in the prefs_node table for a row with node_id=2875. The row is present and the full path of the node is: /portlet_entity/reports-3/no-principal/preferences/reportTimeZone/values Note that reports-3 is the fragment ID for the portlet fragment in the psml page. However, instead of 'no-principal', I would have expected to see the user name of user A. So now I log in as user B and go to edit my portlet preferences and the value of the reportTimeZone preference is set to US/Pacific, not the default US/Eastern I would have expected. So I then, as user B, set the reportTimeZone to US/Central and update my preferences. Sure enough, it overwrites the value in the prefs_property_value table to US/Central. So, in order to get the behaviour I need, I would have to generate portal pages for each user and vary the id of the portlet fragment? This does not seem like a good solution to me. Further, in my environment, users are not permitted to create their own pages and customize them. I am simply providing a form in the doEdit method of my portlet to allow users to customize the behaviour of the portlet. So, in my environment, imagine I had a weather portlet on a portal page. If someone sets their preferred city to be Bangkok, then all users will get weather for Bangkok! This does not seem right to me...
        Hide
        Terry Partridge added a comment -

        Yes, I also have a need to store user specific preferences without having to generate portal pages for each user.

        Show
        Terry Partridge added a comment - Yes, I also have a need to store user specific preferences without having to generate portal pages for each user.
        Hide
        Aaron Evans added a comment -

        Hey guys,
        Just wondering if this will make it into 2.1. I am really hoping it does. I have been running in production on 2.0 for a while now and have been waiting for 2.1 to upgrade, but this is one of my big requirements.

        cheers,
        aaron

        Show
        Aaron Evans added a comment - Hey guys, Just wondering if this will make it into 2.1. I am really hoping it does. I have been running in production on 2.0 for a while now and have been waiting for 2.1 to upgrade, but this is one of my big requirements. cheers, aaron
        Hide
        David Sean Taylor added a comment -

        Aaron, I haven't forgotten. Im involved in another project here.
        Behind schedule, usual. I will get this in for 2.1 release, just later than expected. My apologies for any inconvenience this has caused you.

        Show
        David Sean Taylor added a comment - Aaron, I haven't forgotten. Im involved in another project here. Behind schedule, usual. I will get this in for 2.1 release, just later than expected. My apologies for any inconvenience this has caused you.
        David Sean Taylor made changes -
        Field Original Value New Value
        Status Open [ 1 ] In Progress [ 3 ]
        David Sean Taylor committed 433925 (3 files)
        Reviews: none

        Implement preferences per user
        http://issues.apache.org/jira/browse/JS2-449

        Before JS2-449, all preferences were shared.
        With JS2-449, preferences are now stored 'per user'.
        The username is stored in the preferences FULL_PATH
        To turn on mergeSharedPreferences configure this property to true
        This will NOT turn off per user prefs, but instead merge with them, where user prefs override.

        New request context function to centralize retrieval of user subject per request

        David Sean Taylor committed 433927 (3 files)
        Reviews: none

        Implement preferences per user
        http://issues.apache.org/jira/browse/JS2-449

        Before JS2-449, all preferences were shared.
        With JS2-449, preferences are now stored 'per user'.
        The username is stored in the preferences FULL_PATH
        To turn on mergeSharedPreferences configure this property to true
        This will NOT turn off per user prefs, but instead merge with them, where user prefs override.

        New request context function to centralize retrieval of user subject per request

        Hide
        David Sean Taylor added a comment -

        Aaron, Ive checked in the initial implementation. Please test when you get a chance.
        Note that if you test with the Pick A Number portlet, it is using the session to cache prefs,
        so its not a good test of prefs, because of that other problem we discussed with session termination.
        Please let us know how your testing went...

        Show
        David Sean Taylor added a comment - Aaron, Ive checked in the initial implementation. Please test when you get a chance. Note that if you test with the Pick A Number portlet, it is using the session to cache prefs, so its not a good test of prefs, because of that other problem we discussed with session termination. Please let us know how your testing went...
        Hide
        David Sean Taylor added a comment -

        seems to be working for a while now

        Show
        David Sean Taylor added a comment - seems to be working for a while now
        David Sean Taylor made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Thorsten Berger added a comment -

        I'm a bit wondering why switching back to the old behaviour isn't configurable. At least I haven't found it and please correct me if I'm wrong.

        This seems to prevent one of my important use cases: the admin should be able to configure portlets on public portal pages.

        E.g. imagine that admin wants to put the Google Maps portlet on the (publicly viewable) start page and sets another location in the prefs than the default one. This results in only admin seeing the correct location, non-logged-in guests still have San Francisco. The same for RSS portlets etc.

        I tried to use the "mergeSharedPreferences" feature, but could not achieve this behavoiur. Furthermore there is always a preference node for the guest user created by just viewing the page and this overrides always the "no-principal" prefs (besides that one can't graphically edit "no-principal" prefs).
        Using the Portlet Application Manager to set default prefs is insufficient too, as they're saved per portlet definition, not per entity.

        Thanks in advance for any advice, Thorsten

        Show
        Thorsten Berger added a comment - I'm a bit wondering why switching back to the old behaviour isn't configurable. At least I haven't found it and please correct me if I'm wrong. This seems to prevent one of my important use cases: the admin should be able to configure portlets on public portal pages. E.g. imagine that admin wants to put the Google Maps portlet on the (publicly viewable) start page and sets another location in the prefs than the default one. This results in only admin seeing the correct location, non-logged-in guests still have San Francisco. The same for RSS portlets etc. I tried to use the "mergeSharedPreferences" feature, but could not achieve this behavoiur. Furthermore there is always a preference node for the guest user created by just viewing the page and this overrides always the "no-principal" prefs (besides that one can't graphically edit "no-principal" prefs). Using the Portlet Application Manager to set default prefs is insufficient too, as they're saved per portlet definition, not per entity. Thanks in advance for any advice, Thorsten
        Hide
        Ate Douma added a comment -

        Closed again now properly recorded against Fix Version 2.1 as well

        Show
        Ate Douma added a comment - Closed again now properly recorded against Fix Version 2.1 as well
        Ate Douma made changes -
        Fix Version/s 2.1 [ 12310617 ]
        Ate Douma made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            David Sean Taylor
            Reporter:
            David Sean Taylor
          • Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development