PUBLIC - Liferay Portal Community Edition
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-9

Reintroduce instance specific properties and make it configurable

    Details

    • Type: Feature Request Feature Request
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 5.1.2, 5.2.2
    • Fix Version/s: None
    • Labels:
      None
    • Branch Version/s:
      5.1.x
    • Backported to Branch:
      Committed
    • Liferay Contributor's Agreement:
      Accept
    • Similar Issues:
      Show 5 results 

      Description

      As I prefer to have instance specific configuration already on instance creation (eg. default admin and ldap settings) I ported it from 4.3 to current head and made it configurable in portal-ext.properties to avoid confusion (LEP-6390).

      Attached is ConfigurationImpl.java and PropsUtil.java (rev 21163).
      Set include-and-override=portal-$

      {easyconf:companyId}

      .properties in portal-ext.properties to enable the feature.

      I'd very much like to have this included again. Please let me know if I can do something else.

      1. ConfigurationImpl.java
        11 kB
        Marc Champion
      2. ConfigurationImpl.java
        11 kB
        Marc Champion
      3. PropsUtil.java
        7 kB
        Andrea Vacondio
      4. PropsUtil.java
        4 kB
        Marc Champion
      5. PropsUtil.java
        4 kB
        Marc Champion

        Issue Links

          Activity

          Marc Champion created issue -
          Marc Champion made changes -
          Field Original Value New Value
          Attachment ConfigurationImpl.java [ 14844 ]
          Marc Champion made changes -
          Attachment PropsUtil.java [ 14845 ]
          Michael Young made changes -
          Workflow Liferay Workflow - version 1.1 [ 83044 ] Liferay Workflow - version 1.2 [ 84197 ]
          Michael Young made changes -
          Workflow Liferay Workflow - version 1.2 [ 84197 ] Liferay Workflow - version 1.3 [ 95974 ]
          Ivan Cheung made changes -
          Workflow Liferay Workflow - version 1.3 [ 95974 ] Liferay Workflow - version 1.4 [ 107763 ]
          Ivan Cheung made changes -
          Workflow Liferay Workflow - version 1.4 [ 107763 ] Liferay Workflow - version 1.5 [ 119551 ]
          Michael Young made changes -
          Workflow Liferay Workflow - version 1.5 [ 119551 ] Liferay Workflow - version 1.6 [ 132405 ]
          Hide
          Tuomo Kujanpää added a comment -

          Great! Yeah, this feature is really needed. It is not enough to give a few properties to the instance in Enterprise Admin portlet after instance creation.

          Show
          Tuomo Kujanpää added a comment - Great! Yeah, this feature is really needed. It is not enough to give a few properties to the instance in Enterprise Admin portlet after instance creation.
          Michael Young made changes -
          Workflow Liferay Workflow - version 1.6 [ 132405 ] Liferay Workflow - version 1.7 [ 145624 ]
          Michael Young made changes -
          Workflow Liferay Workflow - version 1.7 [ 145624 ] Liferay Workflow - version 1.8 [ 158832 ]
          Hide
          Ben Starr added a comment -

          I would also very much like to see this feature included back into the main code base.

          Show
          Ben Starr added a comment - I would also very much like to see this feature included back into the main code base.
          Hide
          Marc Champion added a comment - - Restricted to

          I updated the patches to current head. Attached is ConfigurationImpl.java and PropsUtil.java (rev 27078).

          Set include-and-override=portal-$

          {easyconf:companyId}

          .properties in portal-ext.properties to enable the feature.

          Instance specific configuration was a killer feature of the liferay portal. When you realize even smaller projects with liferay such as we do it's hard to convince the customers to pay $700+ for a whole liferay instance with 1GB RAM. When you can share an instance with other customers the hosting price comes down and we can fully profit from the portal infrastructure.

          Are there others that miss this feature? Maybe we can convince Liferay inc. that it wasn't a good idea to remove it? If that's somehow impossible I ask for help in the community to test and contribute to the patches I made. Some settings such as layout.default.template.id and locales don't work properly in the instance specific configuration files but most of it works for me. Maybe we can at least provide a patchset that makes instance specific configuration fully work again.

          Show
          Marc Champion added a comment - - Restricted to I updated the patches to current head. Attached is ConfigurationImpl.java and PropsUtil.java (rev 27078). Set include-and-override=portal-$ {easyconf:companyId} .properties in portal-ext.properties to enable the feature. Instance specific configuration was a killer feature of the liferay portal. When you realize even smaller projects with liferay such as we do it's hard to convince the customers to pay $700+ for a whole liferay instance with 1GB RAM. When you can share an instance with other customers the hosting price comes down and we can fully profit from the portal infrastructure. Are there others that miss this feature? Maybe we can convince Liferay inc. that it wasn't a good idea to remove it? If that's somehow impossible I ask for help in the community to test and contribute to the patches I made. Some settings such as layout.default.template.id and locales don't work properly in the instance specific configuration files but most of it works for me. Maybe we can at least provide a patchset that makes instance specific configuration fully work again.
          Marc Champion made changes -
          Attachment ConfigurationImpl.java [ 15722 ]
          Attachment PropsUtil.java [ 15723 ]
          Hide
          Ben Starr added a comment - - Restricted to

          I totally agree with you Marc. I've submitted a feature suggestion to the message boards to have it re-introduced. Hopefully it will raise awareness of the issue:

          http://www.liferay.com/web/guest/community/forums/-/message_boards/message/2447165

          Ben

          Show
          Ben Starr added a comment - - Restricted to I totally agree with you Marc. I've submitted a feature suggestion to the message boards to have it re-introduced. Hopefully it will raise awareness of the issue: http://www.liferay.com/web/guest/community/forums/-/message_boards/message/2447165 Ben
          Hide
          Jorge Ferrer added a comment - - Restricted to

          Hey Marc, Ben,

          That feature lead to several issues, confusion and inconsistencies, which is why it was removed.

          The alternative now is the Portal > Settings item within the Control Panel.

          Show
          Jorge Ferrer added a comment - - Restricted to Hey Marc, Ben, That feature lead to several issues, confusion and inconsistencies, which is why it was removed. The alternative now is the Portal > Settings item within the Control Panel.
          Hide
          Ben Starr added a comment - - Restricted to

          Hi Jorge,

          Thanks for the information. I assume that the feature in Portal > Settings is only available in 5.2 and not 5.1? I'm currently using 5.1 and couldn't find anywhere that provides equivalent functionality. Can you confirm that the Portal > Settings function allows properties to be defined per-instance/company? Can these properties then be programmatically queried via the PrefsPropsUtil.getXxx(companyId, name) methods? That is the kind of functionality that I need.

          Thanks,

          Ben

          Show
          Ben Starr added a comment - - Restricted to Hi Jorge, Thanks for the information. I assume that the feature in Portal > Settings is only available in 5.2 and not 5.1? I'm currently using 5.1 and couldn't find anywhere that provides equivalent functionality. Can you confirm that the Portal > Settings function allows properties to be defined per-instance/company? Can these properties then be programmatically queried via the PrefsPropsUtil.getXxx(companyId, name) methods? That is the kind of functionality that I need. Thanks, Ben
          Hide
          Marc Champion added a comment - - Restricted to

          Hi Jorge,

          Thank you for your answer! I need to specify the following settings per instance. Is there currently a way to set them instance specific or are you planning to make them configurable via the settings page in the control panel?

          Kind regards,
          Marc

          ##

            1. Users
              ##

          users.form.add.main=
          users.form.add.identification=
          users.form.add.miscellaneous=

          users.form.update.main=
          users.form.update.identification=
          users.form.update.miscellaneous=

          ##

            1. Languages and Time Zones
              ##

          locales=

          ##

            1. Look and Feel
              ##

          default.regular.theme.id=

          ##

            1. Default User
              ##

          default.user.layout.name=
          default.user.public.layout.template.id=
          default.user.layout.column-1=

          ##

            1. Layouts
              ##

          layout.static.portlets.start.column-0[community]=
          layout.add.portlets=
          layout.show.portlet.inactive=

          layout.default.template.id=

          ##

            1. Navigation Portlet
              ##

          navigation.display.style.options=
          navigation.display.style[7]=

          Show
          Marc Champion added a comment - - Restricted to Hi Jorge, Thank you for your answer! I need to specify the following settings per instance. Is there currently a way to set them instance specific or are you planning to make them configurable via the settings page in the control panel? Kind regards, Marc ## Users ## users.form.add.main= users.form.add.identification= users.form.add.miscellaneous= users.form.update.main= users.form.update.identification= users.form.update.miscellaneous= ## Languages and Time Zones ## locales= ## Look and Feel ## default.regular.theme.id= ## Default User ## default.user.layout.name= default.user.public.layout.template.id= default.user.layout.column-1= ## Layouts ## layout.static.portlets.start.column-0 [community] = layout.add.portlets= layout.show.portlet.inactive= layout.default.template.id= ## Navigation Portlet ## navigation.display.style.options= navigation.display.style [7] =
          Marc Champion made changes -
          Status Open [ 1 ] Committed to Subversion [ 10000 ]
          Liferay Contributor's Agreement [Accept]
          Hide
          Ben Starr added a comment - - Restricted to

          I think there are two different issues here. The first is the ability to specify your own per-instance properties. The second is the ability to set standard portal properties per-instance. I'm not sure if both were previously possible or only the first.

          I am particularly interested in being able to specify my own per-instance properties as a way to customise the portal for different instances. However, it would also be useful to be able to set many of the standard portal properties on a per-instance basis. I would have thought this should include all standard portal properties that don't need to apply globally. Some ones I can think of in addition to the list above are those related to user layouts:

          layout.user.private.layouts.enabled=true
          layout.user.private.layouts.modifiable=true
          layout.user.private.layouts.auto.create=true

          layout.user.public.layouts.enabled=true
          layout.user.public.layouts.modifiable=true
          layout.user.public.layouts.auto.create=true

          It would be useful to be able to configure these on a per-instance basis. I'm not sure whether both of the issues mentioned above are provided for in Portal > Settings in the Control Panel?

          Show
          Ben Starr added a comment - - Restricted to I think there are two different issues here. The first is the ability to specify your own per-instance properties. The second is the ability to set standard portal properties per-instance. I'm not sure if both were previously possible or only the first. I am particularly interested in being able to specify my own per-instance properties as a way to customise the portal for different instances. However, it would also be useful to be able to set many of the standard portal properties on a per-instance basis. I would have thought this should include all standard portal properties that don't need to apply globally. Some ones I can think of in addition to the list above are those related to user layouts: layout.user.private.layouts.enabled=true layout.user.private.layouts.modifiable=true layout.user.private.layouts.auto.create=true layout.user.public.layouts.enabled=true layout.user.public.layouts.modifiable=true layout.user.public.layouts.auto.create=true It would be useful to be able to configure these on a per-instance basis. I'm not sure whether both of the issues mentioned above are provided for in Portal > Settings in the Control Panel?
          Hide
          Andrea Vacondio added a comment - - Restricted to

          Hi,
          I added this patch and tried to have a "per instance" configuration using the include-and-override=portal-$

          {easyconf:companyId}

          .properties. My need is to have different subsets of available locales so I added the following property to the portal-$

          {easyconf:companyId}

          .properties:

          locales=it_IT,en_US,fr_FR,es_ES,de_DE

          The problem is that this property seems to be ignored and when i publish a webcontent the combobox "Language" is populated with the full list and not my "per instance" list. Everything works if I set this property in the portal-ext.properties but I need a different list for each instance, could it be fixed?
          Thank you
          Andrea

          Show
          Andrea Vacondio added a comment - - Restricted to Hi, I added this patch and tried to have a "per instance" configuration using the include-and-override=portal-$ {easyconf:companyId} .properties. My need is to have different subsets of available locales so I added the following property to the portal-$ {easyconf:companyId} .properties: locales=it_IT,en_US,fr_FR,es_ES,de_DE The problem is that this property seems to be ignored and when i publish a webcontent the combobox "Language" is populated with the full list and not my "per instance" list. Everything works if I set this property in the portal-ext.properties but I need a different list for each instance, could it be fixed? Thank you Andrea
          Hide
          Marc Champion added a comment - - Restricted to

          Hi Andrea

          If you aren't sure if your setup works in general add the following property to an instance specific configuration file:

          field.enable.com.liferay.portal.model.Contact.birthday=false

          This should remove the birthday field from the create account portlet on the instance with the specific configuration.

          But even if this works, I know that locales don't work properly with my patch (see my comment from 10/Mar/09). I've already tried to fix this but didn't have enough time to track it down. In LanguageImpl.java the _getInstance() function creates a LanguageImpl per instance. This LanguageImpl get's it's locales from PropsValues.LOCALES which itself calls PropsUtil.getArray(PropsKeys.LOCALES) which is already patched to read the instance specific configuration file. That's how far I came. But there must be some other locale functionality which makes it stop working. Maybe others could help?

          Regards
          Marc

          Show
          Marc Champion added a comment - - Restricted to Hi Andrea If you aren't sure if your setup works in general add the following property to an instance specific configuration file: field.enable.com.liferay.portal.model.Contact.birthday=false This should remove the birthday field from the create account portlet on the instance with the specific configuration. But even if this works, I know that locales don't work properly with my patch (see my comment from 10/Mar/09). I've already tried to fix this but didn't have enough time to track it down. In LanguageImpl.java the _getInstance() function creates a LanguageImpl per instance. This LanguageImpl get's it's locales from PropsValues.LOCALES which itself calls PropsUtil.getArray(PropsKeys.LOCALES) which is already patched to read the instance specific configuration file. That's how far I came. But there must be some other locale functionality which makes it stop working. Maybe others could help? Regards Marc
          Hide
          Andrea Vacondio added a comment - - Restricted to

          Hi Mark,
          I'm new to Liferay (it's just a week I'm working on it) but digging into the code I found a possible solution to the locales issue.
          in PropsValues there's

          public static String[] LOCALES = PropsUtil.getArray(PropsKeys.LOCALES);

          that is a class variable and is accessed by the LanguageImpl constructor to get the locales list. While the PropsUtil.getArray(PropsKeys.LOCALES); has the logic to manage per instace configuration, the PropsValues.LOCALES is static and, from the Sun website:
          "If the declarator is for a class variable (that is, a static field), then the variable initializer is evaluated and the assignment performed exactly once, when the class is initialized" so the LOCALES field once initialized wont be reevaluated and every LanguageImpls will have the same locales list.
          To solve this i modified the LanguageImpl line 548 with:

          String[] localesArray = PropsUtil.getArray(PropsKeys.LOCALES);

          It seems working to me but as said I'm totally new to Liferay and perhaps I'm missing something thus it would be nice if some expert could confirm this.

          Regards
          Andrea

          Show
          Andrea Vacondio added a comment - - Restricted to Hi Mark, I'm new to Liferay (it's just a week I'm working on it) but digging into the code I found a possible solution to the locales issue. in PropsValues there's public static String[] LOCALES = PropsUtil.getArray(PropsKeys.LOCALES); that is a class variable and is accessed by the LanguageImpl constructor to get the locales list. While the PropsUtil.getArray(PropsKeys.LOCALES); has the logic to manage per instace configuration, the PropsValues.LOCALES is static and, from the Sun website: "If the declarator is for a class variable (that is, a static field), then the variable initializer is evaluated and the assignment performed exactly once, when the class is initialized" so the LOCALES field once initialized wont be reevaluated and every LanguageImpls will have the same locales list. To solve this i modified the LanguageImpl line 548 with: String[] localesArray = PropsUtil.getArray(PropsKeys.LOCALES); It seems working to me but as said I'm totally new to Liferay and perhaps I'm missing something thus it would be nice if some expert could confirm this. Regards Andrea
          Hide
          Marc Champion added a comment - - Restricted to

          Hey Andrea

          Great, that sounds like the solution. I'll try it next week and create a new patchset of the current 5.2.x branch.

          Thanks
          Marc

          Show
          Marc Champion added a comment - - Restricted to Hey Andrea Great, that sounds like the solution. I'll try it next week and create a new patchset of the current 5.2.x branch. Thanks Marc
          Hide
          Andrea Vacondio added a comment - - Restricted to

          Hi Marc,
          I'm still tring to understand the code (the "per instance" property file seems to be very important to my company) so this is what i found.
          Your PropsUtil.java seems to come from the 5.1 version and gives some error on the 5.2.2 (the version i patched). in particular there was an error with the default.liferay.home property thus I adapted your patched version to the PropsUtil in the 5.2.2 (hopefully with no errors) and everything seems fine now (I'll attach the PropsUtil.java).
          I also thought about the PropsValues class and it seems to me that a very structural change is needed to have your patch fully working (in 5.2.2, don't know about the 5.1). I think all the class variables in this class are populated with the portal.properties/portal-ext.properties logic ignoring the portal-$

          {easyconf:companyId}

          .properties and, if so, everywhere in the Liferay code where a PropsValue static filed is accessed the "per instance" logic doesn't apply. To have your patch fully working, class variables in PropsValues should be replaced by static method calls where the method body is something like:

          PropsUtil.getSOMETHING(PropsKeys.SOMETHING);

          This would call your "per instance" logic everytime a PropsValues is requested but, as said, it would have a very big impact on the Liferay code.

          Show
          Andrea Vacondio added a comment - - Restricted to Hi Marc, I'm still tring to understand the code (the "per instance" property file seems to be very important to my company) so this is what i found. Your PropsUtil.java seems to come from the 5.1 version and gives some error on the 5.2.2 (the version i patched). in particular there was an error with the default.liferay.home property thus I adapted your patched version to the PropsUtil in the 5.2.2 (hopefully with no errors) and everything seems fine now (I'll attach the PropsUtil.java). I also thought about the PropsValues class and it seems to me that a very structural change is needed to have your patch fully working (in 5.2.2, don't know about the 5.1). I think all the class variables in this class are populated with the portal.properties/portal-ext.properties logic ignoring the portal-$ {easyconf:companyId} .properties and, if so, everywhere in the Liferay code where a PropsValue static filed is accessed the "per instance" logic doesn't apply. To have your patch fully working, class variables in PropsValues should be replaced by static method calls where the method body is something like: PropsUtil.getSOMETHING(PropsKeys.SOMETHING); This would call your "per instance" logic everytime a PropsValues is requested but, as said, it would have a very big impact on the Liferay code.
          Hide
          Andrea Vacondio added a comment -

          Patched version from the 5.2.2

          Show
          Andrea Vacondio added a comment - Patched version from the 5.2.2
          Andrea Vacondio made changes -
          Attachment PropsUtil.java [ 16019 ]
          Hide
          Brian Chan added a comment -

          Alrighty guys, back by popular demand.

          Disabled by default though,

          java ... company-id-properties=true

          to enable it.

          I disabled it by default because if you enable it, it forces a creation of a new ConfigurationImpl for every instance, and for those who don't want it, it's unnecessary memory usage. I also updated the documentation on it to make it easier to understand.

          Thanks to all who wanted this (it helps when the community shouts, cause then we know ppl care).

          #

          1. Specify where to get the overridden properties. Updates should not be made
          2. on this file but on the overridden version of this file.
            #
          3. The default read order is: portal.properties and then
          4. portal-ext.properties.
            #
            include-and-override=portal-ext.properties
            include-and-override=$ {liferay.home}

            /portal-ext.properties

          #

          1. Each portal instance can have its own overriden property file following
          2. the convention portal-companyId.properties. To enable this feature, set
          3. the "company-id-properties" system property to true.
            #
          4. To enable:
            #
          5. java ... company-id-properties=true
            #
          6. The read order will now be: portal.properties, then portal-ext.properties,
          7. and then portal-liferay.com.properties.
            #
            include-and-override=portal-$ {easyconf:companyId}

            .properties

          #

          1. Additional property files can be used by setting the "external-properties"
          2. system property.
            #
          3. A common use case is to keep legacy property values when upgrading to
          4. newer versions of Liferay. To enable:
            #
          5. java ... -Dexternal-properties=portal-legacy-5.1.properties
            #
          6. The read order will now be: portal.properties, then portal-ext.properties,
          7. and then portal-legacy-5.1.properties.
            #
            include-and-override=$ {external-properties}
          Show
          Brian Chan added a comment - Alrighty guys, back by popular demand. Disabled by default though, java ... company-id-properties=true to enable it. I disabled it by default because if you enable it, it forces a creation of a new ConfigurationImpl for every instance, and for those who don't want it, it's unnecessary memory usage. I also updated the documentation on it to make it easier to understand. Thanks to all who wanted this (it helps when the community shouts, cause then we know ppl care). # Specify where to get the overridden properties. Updates should not be made on this file but on the overridden version of this file. # The default read order is: portal.properties and then portal-ext.properties. # include-and-override=portal-ext.properties include-and-override=$ {liferay.home} /portal-ext.properties # Each portal instance can have its own overriden property file following the convention portal-companyId.properties. To enable this feature, set the "company-id-properties" system property to true. # To enable: # java ... company-id-properties=true # The read order will now be: portal.properties, then portal-ext.properties, and then portal-liferay.com.properties. # include-and-override=portal-$ {easyconf:companyId} .properties # Additional property files can be used by setting the "external-properties" system property. # A common use case is to keep legacy property values when upgrading to newer versions of Liferay. To enable: # java ... -Dexternal-properties=portal-legacy-5.1.properties # The read order will now be: portal.properties, then portal-ext.properties, and then portal-legacy-5.1.properties. # include-and-override=$ {external-properties}
          Brian Chan made changes -
          Affects Version/s 5.2.2 [ 10364 ]
          Fix Version/s 5.2.3 [ 10367 ]
          Backport Version/s [5.1.x]
          Backport Committed [Committed]
          Brian Chan made changes -
          Status Committed to Subversion [ 10000 ] Pending Backport to EE [ 10003 ]
          Resolution Fixed [ 1 ]
          Hide
          Marc Champion added a comment -

          Thank you Brian!

          Show
          Marc Champion added a comment - Thank you Brian!
          Hide
          Josh Asbury added a comment -

          Great! Thanks, Brian!

          Show
          Josh Asbury added a comment - Great! Thanks, Brian!
          Samuel Kong made changes -
          Link This issue relates LPE-773 [ LPE-773 ]
          Samuel Kong made changes -
          Status Pending Backport to EE [ 10003 ] Closed [ 6 ]
          Hide
          Jorge Ferrer added a comment - - Restricted to

          Hey Marc, Josh,

          Note that although this has been added back the recommended way to set instance specific properties is through the Control Panel >> Portal >> Settings UI.

          If there are some settings that you miss there, let us know and we'll add them

          Show
          Jorge Ferrer added a comment - - Restricted to Hey Marc, Josh, Note that although this has been added back the recommended way to set instance specific properties is through the Control Panel >> Portal >> Settings UI. If there are some settings that you miss there, let us know and we'll add them
          Hide
          Mika Koivisto added a comment - - Restricted to

          Jorge, most of the options starting with layout. are the ones that come to my mind. For instance in some instances you might want to have user pages and on other you might not.

          Show
          Mika Koivisto added a comment - - Restricted to Jorge, most of the options starting with layout. are the ones that come to my mind. For instance in some instances you might want to have user pages and on other you might not.
          Hide
          Marc Champion added a comment - - Restricted to

          Hi Jorge, this is what I usually want to define instance specific:

          ##

            1. Theme
              ##

          theme.css.fast.load=
          theme.images.fast.load=

          ##

            1. JavaScript
              ##

          javascript.fast.load=
          javascript.log.enabled=

          ##

            1. Users
              ##

          users.screen.name.always.autogenerate=

            1. Groups and Roles
              ##

          terms.of.use.required=

          ##

            1. Organizations and Locations
              ##

          organizations.location.enabled=

          ##

            1. Velocity Engine
              ##

          velocity.engine.resource.manager.cache.enabled=

          ##

            1. Languages and Time Zones
              ##

          locales=

          ##

            1. Look and Feel
              ##

          default.regular.theme.id=

          ##

            1. Default User
              ##

          default.user.public.layout.name=
          default.user.public.layout.template.id=
          default.user.layout.column-1=

          ##

            1. Layouts
              ##

          layout.show.portlet.access.denied=
          layout.show.portlet.inactive=
          layout.template.cache.enabled=

          ##

            1. Fields
              ##

          field.enable.com.liferay.portal.model.Contact.male=
          field.enable.com.liferay.portal.model.Contact.birthday=

          ##

            1. Servlet Filters
              ##

          com.liferay.portal.servlet.filters.cache.CacheFilter=

          ##

            1. Passwords
              ##

          passwords.encryption.algorithm=

          ##

            1. Default Admin
              ##

          default.admin.password=
          default.admin.screen.name=
          default.admin.email.address.prefix=
          default.admin.first.name=
          default.admin.last.name=

          ##

            1. Listeners
              ##

          value.object.listener.com.liferay.portal.model.Layout=
          value.object.listener.com.liferay.portal.model.PortletPreferences=

          Show
          Marc Champion added a comment - - Restricted to Hi Jorge, this is what I usually want to define instance specific: ## Theme ## theme.css.fast.load= theme.images.fast.load= ## JavaScript ## javascript.fast.load= javascript.log.enabled= ## Users ## users.screen.name.always.autogenerate= Groups and Roles ## terms.of.use.required= ## Organizations and Locations ## organizations.location.enabled= ## Velocity Engine ## velocity.engine.resource.manager.cache.enabled= ## Languages and Time Zones ## locales= ## Look and Feel ## default.regular.theme.id= ## Default User ## default.user.public.layout.name= default.user.public.layout.template.id= default.user.layout.column-1= ## Layouts ## layout.show.portlet.access.denied= layout.show.portlet.inactive= layout.template.cache.enabled= ## Fields ## field.enable.com.liferay.portal.model.Contact.male= field.enable.com.liferay.portal.model.Contact.birthday= ## Servlet Filters ## com.liferay.portal.servlet.filters.cache.CacheFilter= ## Passwords ## passwords.encryption.algorithm= ## Default Admin ## default.admin.password= default.admin.screen.name= default.admin.email.address.prefix= default.admin.first.name= default.admin.last.name= ## Listeners ## value.object.listener.com.liferay.portal.model.Layout= value.object.listener.com.liferay.portal.model.PortletPreferences=
          Hide
          Josh Asbury added a comment - - Restricted to

          In addition to the aforementioned, here are the properties that I use:

          ##

            1. Default Landing Page
              ##
              default.landing.page.path=
              auth.forward.by.last.path=

          ##

            1. Calendar Portlet
              ##
              calendar.event.types=
          Show
          Josh Asbury added a comment - - Restricted to In addition to the aforementioned, here are the properties that I use: ## Default Landing Page ## default.landing.page.path= auth.forward.by.last.path= ## Calendar Portlet ## calendar.event.types=
          Hide
          Andrea Vacondio added a comment - - Restricted to

          Great!
          Here are mine properties:

          locales=
          layout.user.private.layouts.enabled=
          layout.user.public.layouts.enabled=
          dl.file.max.size=
          ig.image.max.size=
          journal.template.velocity.restricted.variables=

          It seems there are a lot of properties here and, in general every different Liferay user could have the need to set any of the available properties. If you aim to have the Panel >> Portal >> Settings interface like the place to go to set instace specific properties I think you should provide there some kind of interface to set every property or to edit the property file. Just a suggestion.

          Show
          Andrea Vacondio added a comment - - Restricted to Great! Here are mine properties: locales= layout.user.private.layouts.enabled= layout.user.public.layouts.enabled= dl.file.max.size= ig.image.max.size= journal.template.velocity.restricted.variables= It seems there are a lot of properties here and, in general every different Liferay user could have the need to set any of the available properties. If you aim to have the Panel >> Portal >> Settings interface like the place to go to set instace specific properties I think you should provide there some kind of interface to set every property or to edit the property file. Just a suggestion.
          Hide
          Jorge Ferrer added a comment - - Restricted to

          Thanks Marc, Josh, Andrea,

          That's very useful.

          Show
          Jorge Ferrer added a comment - - Restricted to Thanks Marc, Josh, Andrea, That's very useful.
          Hide
          Ben Starr added a comment -

          Brian, thank you very much for adding this feature back in! Having it disabled by default is fine with me as it is easy to enable if needed.

          Jorge, I think it would be useful to include all portal properties that do not need to apply globally to allow instances to be customised as much as possible.

          While it is good to be able to configure these settings in the GUI there are reasons why you might want to use the properties files. The first is that it means you can pre-configure a properties file and just deploy it to a Liferay Portal instance rather than having to configure each property manually in the GUI. The second is if you want to add your own custom properties that aren't part of the standard set. I'm using the latter to customise certain parts of the system that can't otherwise be customised. Any chance that we could also add our own properties in the GUI?

          Show
          Ben Starr added a comment - Brian, thank you very much for adding this feature back in! Having it disabled by default is fine with me as it is easy to enable if needed. Jorge, I think it would be useful to include all portal properties that do not need to apply globally to allow instances to be customised as much as possible. While it is good to be able to configure these settings in the GUI there are reasons why you might want to use the properties files. The first is that it means you can pre-configure a properties file and just deploy it to a Liferay Portal instance rather than having to configure each property manually in the GUI. The second is if you want to add your own custom properties that aren't part of the standard set. I'm using the latter to customise certain parts of the system that can't otherwise be customised. Any chance that we could also add our own properties in the GUI?
          Hide
          Ben Starr added a comment - - Restricted to

          In previous versions PropsUtil had a method get(long companyId, String key). This method does not seem to have been reintroduced. What if I want to retrieve a property for an instance other than the instance of the current thread? An example of this would be a background job that is not associated with a request. If the job was for a specific instance then it would be nice to store the properties for the job in the instance-specific properties even though the job runs in a separate thread.

          I'm also a bit confused about the difference between PropsUtil and PrefsPropsUtil. The latter seems to load overriden properties from the instance-specific properties file in some circumstances but when I looked in the code all I could see was it loading properties from the database so I'm not sure how it is getting them from the file. When should PropsUtil be used and when should PrefsPropsUtil be used?

          Thanks.

          Show
          Ben Starr added a comment - - Restricted to In previous versions PropsUtil had a method get(long companyId, String key). This method does not seem to have been reintroduced. What if I want to retrieve a property for an instance other than the instance of the current thread? An example of this would be a background job that is not associated with a request. If the job was for a specific instance then it would be nice to store the properties for the job in the instance-specific properties even though the job runs in a separate thread. I'm also a bit confused about the difference between PropsUtil and PrefsPropsUtil. The latter seems to load overriden properties from the instance-specific properties file in some circumstances but when I looked in the code all I could see was it loading properties from the database so I'm not sure how it is getting them from the file. When should PropsUtil be used and when should PrefsPropsUtil be used? Thanks.
          Hide
          Jorge Ferrer added a comment - - Restricted to

          Hi Ben,

          You should use PrefsPropsUtil for any property whose value can also be set from the Portal >> Settings UI. BTW, we added many more properties to that UI as suggested by previous comments and the change were backported to 5.2.x so you may want to check if you find what you want. You can check the changes in LPS-3457

          Show
          Jorge Ferrer added a comment - - Restricted to Hi Ben, You should use PrefsPropsUtil for any property whose value can also be set from the Portal >> Settings UI. BTW, we added many more properties to that UI as suggested by previous comments and the change were backported to 5.2.x so you may want to check if you find what you want. You can check the changes in LPS-3457
          Hide
          Ben Starr added a comment - - Restricted to

          Hi Jorge,

          Thanks for the clarification. Can you confirm that PrefsPropsUtil will load properties from the database and then from the properties files? If that is the case then I think there is a problem with the way this functionality has been re-introduced. From what I can tell there are versions of each method in PrefsPropsUtil to specify the company ID to retrieve the property for. However, in PropsUtil there is no way to specify the company ID but the way this functionality has been re-introduced it will retrieve the instance-specific property for the company ID of the current thread.

          I am assuming that if PrefsPropsUtil does not find the property in the database it will fall back to PropsUtil to load it from the properties files? In the case that the company ID has been specified in the call to PrefsPropsUtil this will work fine if the company ID is the same as the current thread since any fall-back to PropsUtil (i.e. the properties files) will use the correct company ID. However, if the company ID specified in the call to PrefsPropsUtil is not the same company ID as the current thread then the fall-back to PropsUtil may load the incorrect property value since it will use the company ID of the current thread.

          I think the fix for this would be to add methods to PropsUtil to load properties by a specified company ID and if PrefsPropsUtil falls back to PropsUtil because the property is not set in the database then it should pass through the company ID if specified.

          I hope this makes sense. An example of a situation where I have found this to be a problem is loading instance-specific properties from a background scheduled job where the current thread has no company ID associated with it. In this case a call to PrefsPropsUtil does not use the specified company ID to load the property from the instance-specific properties file, it just uses the default properties files (portal-ext.properties, portal.properties).

          Show
          Ben Starr added a comment - - Restricted to Hi Jorge, Thanks for the clarification. Can you confirm that PrefsPropsUtil will load properties from the database and then from the properties files? If that is the case then I think there is a problem with the way this functionality has been re-introduced. From what I can tell there are versions of each method in PrefsPropsUtil to specify the company ID to retrieve the property for. However, in PropsUtil there is no way to specify the company ID but the way this functionality has been re-introduced it will retrieve the instance-specific property for the company ID of the current thread. I am assuming that if PrefsPropsUtil does not find the property in the database it will fall back to PropsUtil to load it from the properties files? In the case that the company ID has been specified in the call to PrefsPropsUtil this will work fine if the company ID is the same as the current thread since any fall-back to PropsUtil (i.e. the properties files) will use the correct company ID. However, if the company ID specified in the call to PrefsPropsUtil is not the same company ID as the current thread then the fall-back to PropsUtil may load the incorrect property value since it will use the company ID of the current thread. I think the fix for this would be to add methods to PropsUtil to load properties by a specified company ID and if PrefsPropsUtil falls back to PropsUtil because the property is not set in the database then it should pass through the company ID if specified. I hope this makes sense. An example of a situation where I have found this to be a problem is loading instance-specific properties from a background scheduled job where the current thread has no company ID associated with it. In this case a call to PrefsPropsUtil does not use the specified company ID to load the property from the instance-specific properties file, it just uses the default properties files (portal-ext.properties, portal.properties).
          Hide
          Ben Starr added a comment -

          I have reopened this issue because I do not believe the fix addresses the situation where you need to load an instance-specific property for a company that is not the company of the current thread (e.g. in a background scheduled job). See my previous comment for further information about this issue.

          Show
          Ben Starr added a comment - I have reopened this issue because I do not believe the fix addresses the situation where you need to load an instance-specific property for a company that is not the company of the current thread (e.g. in a background scheduled job). See my previous comment for further information about this issue.
          Ben Starr made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Edgar Vonk added a comment - - Restricted to

          Hi,

          I would primarily like to change:

          default.landing.page.path=

          per portal instance.

          I have enabled the feature by including in my portal-ext.properties:

          include-and-override=portal-${easyconf:companyId}.properties

          and by setting:

          JAVA_OPTS="$JAVA_OPTS -Dcompany-id-properties=true"

          in my run.conf

          I have created a portal-mysecondportalinstance.properties file where mysecondportalinstance is the webId of my second portal instance. It does not seem to pick up any overriden properties however. Am I missing something?

          I read here:

          Also, my understanding is that at this stage only some of the properties in the portal.properties file can be overridden per-instance. I'm not sure exactly which ones can and can't - you might just have to experiment.

          Is this true?

          PS: liferay.com is de webId of the default portal instance, not the companyId?

          Show
          Edgar Vonk added a comment - - Restricted to Hi, I would primarily like to change: default.landing.page.path= per portal instance. I have enabled the feature by including in my portal-ext.properties: include-and-override=portal-${easyconf:companyId}.properties and by setting: JAVA_OPTS= "$JAVA_OPTS -Dcompany-id-properties= true " in my run.conf I have created a portal-mysecondportalinstance.properties file where mysecondportalinstance is the webId of my second portal instance. It does not seem to pick up any overriden properties however. Am I missing something? I read here : Also, my understanding is that at this stage only some of the properties in the portal.properties file can be overridden per-instance. I'm not sure exactly which ones can and can't - you might just have to experiment. Is this true? PS: liferay.com is de webId of the default portal instance, not the companyId?
          Hide
          Marc Champion added a comment - - Restricted to

          Hi Edgar

          default.landing.page.path cannot be set in portal-$

          {companyId}

          .properties. Since the 5.2 branch, additional settings can be made in Control Panel > Portal > Settings. On the first tab you'll find Default Landing Page. These settings are instance specific. Please note that these additional settings were not in the 5.2 bundle but they should be in the current 5.3.0 bundle.

          Regards, Marc

          Show
          Marc Champion added a comment - - Restricted to Hi Edgar default.landing.page.path cannot be set in portal-$ {companyId} .properties. Since the 5.2 branch, additional settings can be made in Control Panel > Portal > Settings. On the first tab you'll find Default Landing Page. These settings are instance specific. Please note that these additional settings were not in the 5.2 bundle but they should be in the current 5.3.0 bundle. Regards, Marc
          Hide
          Edgar Vonk added a comment - - Restricted to

          Thanks Marc! Looking forward to work with the 5.3.0 bundle when it is out.

          I have not looked at the latest 5.2 branch code but is there also support for custom instance specific properties from the Control Panel?

          Show
          Edgar Vonk added a comment - - Restricted to Thanks Marc! Looking forward to work with the 5.3.0 bundle when it is out. I have not looked at the latest 5.2 branch code but is there also support for custom instance specific properties from the Control Panel?
          Hide
          Marc Champion added a comment - - Restricted to

          Hi Edgar

          Yes, we are working with the latest 5.2 branch and can set "Default Landing Page" for every instance in the portal over the control panel.

          Regards, Marc

          Show
          Marc Champion added a comment - - Restricted to Hi Edgar Yes, we are working with the latest 5.2 branch and can set "Default Landing Page" for every instance in the portal over the control panel. Regards, Marc
          Hide
          Edgar Vonk added a comment -

          Ok clear, but can you also edit all the other portal properties there for every instance? And can you also add your own custom portal properties? We have some custom portal properties in our portal-ext.properties that we would like to configure differently for the portal instances we have.

          Show
          Edgar Vonk added a comment - Ok clear, but can you also edit all the other portal properties there for every instance? And can you also add your own custom portal properties? We have some custom portal properties in our portal-ext.properties that we would like to configure differently for the portal instances we have.
          Hide
          Ben Starr added a comment -

          I would also like to be able to edit custom properties through the UI. Custom properties are an important way to customise Liferay outside of the customisations that are already possible.

          Show
          Ben Starr added a comment - I would also like to be able to edit custom properties through the UI. Custom properties are an important way to customise Liferay outside of the customisations that are already possible.
          Hide
          Marc Champion added a comment - - Restricted to

          Hi Edgar and Ben

          I see the following situation:

          portal-ext.properties:
          Configure the default portal properties for all instances here. Some of them may also be configured instance specific over the ui. In that case the ui takes precedence. Of cause you can also define your custom, global portal properties here.

          portal-$

          {companyId}

          .properties:
          You can only configure custom, instance specific properties here. Liferay properties cannot be overridden instance specific, as the calls to the getProperty() functions are static. Again, this is where you want to put your custom, instance specific portal properties.

          UI:
          Configure a subset of the portal properties on an instance specific basis over the ui. Not all properties may be configured here. In the past liferay developers asked which properties we wished and implemented them. So give it a try if you need more properties.

          Thank you for any corrections!

          Regards, Marc

          Show
          Marc Champion added a comment - - Restricted to Hi Edgar and Ben I see the following situation: portal-ext.properties: Configure the default portal properties for all instances here. Some of them may also be configured instance specific over the ui. In that case the ui takes precedence. Of cause you can also define your custom, global portal properties here. portal-$ {companyId} .properties: You can only configure custom, instance specific properties here. Liferay properties cannot be overridden instance specific, as the calls to the getProperty() functions are static. Again, this is where you want to put your custom, instance specific portal properties. UI: Configure a subset of the portal properties on an instance specific basis over the ui. Not all properties may be configured here. In the past liferay developers asked which properties we wished and implemented them. So give it a try if you need more properties. Thank you for any corrections! Regards, Marc
          Hide
          Edgar Vonk added a comment -

          ok. thanks Marc! all clear now.

          Show
          Edgar Vonk added a comment - ok. thanks Marc! all clear now.
          Hide
          Lisa Simpson added a comment - - Restricted to

          I'd like to see almost everything be configured at the per instance level at most. I keep debating on the database connection. I can think of a couple of use cases where even the database connection should be set on a per instance basis. And I can't see where it would break the people who don't need it.

          Show
          Lisa Simpson added a comment - - Restricted to I'd like to see almost everything be configured at the per instance level at most. I keep debating on the database connection. I can think of a couple of use cases where even the database connection should be set on a per instance basis. And I can't see where it would break the people who don't need it.
          Michael Han made changes -
          Workflow Liferay Workflow - version 1.8 [ 158832 ] Greenhopper [ 192312 ]
          Hide
          Edgar Vonk added a comment -

          Same here. We run into big issues now because this is not possible. We might even have to run two completely separate Liferay installations because we need to quite different portals. It is a big shame that we would need two Liferay installations to achieve this.

          Show
          Edgar Vonk added a comment - Same here. We run into big issues now because this is not possible. We might even have to run two completely separate Liferay installations because we need to quite different portals. It is a big shame that we would need two Liferay installations to achieve this.
          Hide
          Ben Starr added a comment - - Restricted to

          Hi Marc,

          Thanks for the information. Personally I think the ideal situation would be as follows:

          portal-ext.properties
          Global modified Liferay properties and custom properties. Overrides portal.properties.

          portal-$

          {companyId}.properties
          Instance-specific Liferay properties and custom properties. Overrides portal-ext.properties and portal.properties.

          UI
          Instance-specific Liferay properties (subset) and custom properties. Overrides portal-${companyId}

          .properties, portal-ext.properties and portal.properties.

          This would provide the greatest flexibility. It is often desirable to configure properties in the various properties files because then you can pre-configure appropriate settings rather than having to manually enter them into the UI on each deployment. It is also desirable to be able to configure custom properties in the UI in addition to the Liferay properties as a way to override the properties files.

          If this is not possible then it would at least be useful to be able to configure custom properties in the UI in addition to Marc's specification above.

          Ben

          Show
          Ben Starr added a comment - - Restricted to Hi Marc, Thanks for the information. Personally I think the ideal situation would be as follows: portal-ext.properties Global modified Liferay properties and custom properties. Overrides portal.properties. portal-$ {companyId}.properties Instance-specific Liferay properties and custom properties. Overrides portal-ext.properties and portal.properties. UI Instance-specific Liferay properties (subset) and custom properties. Overrides portal-${companyId} .properties, portal-ext.properties and portal.properties. This would provide the greatest flexibility. It is often desirable to configure properties in the various properties files because then you can pre-configure appropriate settings rather than having to manually enter them into the UI on each deployment. It is also desirable to be able to configure custom properties in the UI in addition to the Liferay properties as a way to override the properties files. If this is not possible then it would at least be useful to be able to configure custom properties in the UI in addition to Marc's specification above. Ben
          Hide
          Marc Champion added a comment - - Restricted to

          Hi Ben

          The big plus of the instance specific configuration over the ui is that you don't have to restart the application server after
          changing settings. In my case most of the settings are the same for all instances and I can easily configure the varying settings manually over the ui. I think it's just confusing that portal-$

          {companyId}

          .properties was reintroduced but it just doesn't work for liferay properties, only for custom properties. This should be clarified in the portal.properties description. Maybe something like this:

          1. Each portal instance can have it's own overridden property file following
          2. the convention portal-companyWebId.properties. Use it to define or override
          3. your custom properties. You cannot override the default Liferay properties here.
          4. Use the settings section in the enterprise admin instead.

          Regards, Marc

          Show
          Marc Champion added a comment - - Restricted to Hi Ben The big plus of the instance specific configuration over the ui is that you don't have to restart the application server after changing settings. In my case most of the settings are the same for all instances and I can easily configure the varying settings manually over the ui. I think it's just confusing that portal-$ {companyId} .properties was reintroduced but it just doesn't work for liferay properties, only for custom properties. This should be clarified in the portal.properties description. Maybe something like this: Each portal instance can have it's own overridden property file following the convention portal-companyWebId.properties. Use it to define or override your custom properties. You cannot override the default Liferay properties here. Use the settings section in the enterprise admin instead. Regards, Marc
          Michael Han made changes -
          Workflow Greenhopper [ 192312 ] Liferay Workflow 2.2 [ 206208 ]
          Hide
          Milan Jaroš added a comment - - Restricted to

          Hi guys, thank you for that great improvement.
          IMHO it can be useful to have specified in portal.properties something like this:

            1. This property can be set in Portal settings portlet.
          Show
          Milan Jaroš added a comment - - Restricted to Hi guys, thank you for that great improvement. IMHO it can be useful to have specified in portal.properties something like this: This property can be set in Portal settings portlet.
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s 6.0.X - SP [ 10440 ]
          Fix Version/s 5.2.3 [ 10367 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s 6.0.0 [ 10366 ]
          Brian Chan made changes -
          Fix Version/s 6.0.X - 02/10 [ 10481 ]
          Fix Version/s 6.0.0 Preview [ 10366 ]
          Brian Chan made changes -
          Fix Version/s 6.0.0 Preview [ 10366 ]
          Brian Chan made changes -
          Fix Version/s 6.0.1 RC [ 10502 ]
          Brian Chan made changes -
          Fix Version/s 6.0.0 Preview [ 10366 ]
          Brian Chan made changes -
          Fix Version/s 6.0.0 Preview [ 10366 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s 6.0.0 Preview [ 10366 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s 6.0.0 Preview [ 10366 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s Sprint 6.0.1 RC - SP [ 10511 ]
          Fix Version/s 6.0.0 Preview [ 10366 ]
          Fix Version/s 6.0.X - SP [ 10440 ]
          Fix Version/s 6.0.X - 02/10 [ 10481 ]
          Fix Version/s 6.0.1 RC [ 10502 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s 6.0.1 RC [ 10502 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s --Sprint - TBD [ 10441 ]
          Fix Version/s --Sprint - SP [ 10511 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s 6.0.1 GA [ 10524 ]
          Fix Version/s 6.0.1 RC [ 10502 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s 6.1.0 [ 10550 ]
          Fix Version/s --Sprint - 05/10 [ 10441 ]
          Fix Version/s 6.0.2 GA [ 10524 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s --Sprint - 08/10 [ 10626 ]
          Fix Version/s 6.1.0 [ 10550 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s 6.1.0 [ 10550 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s 6.1.0 [ 10550 ]
          Julio Camarero made changes -
          Link This issue relates LPS-11512 [ LPS-11512 ]
          Cynthia Wilburn (Inactive) made changes -
          Fix Version/s Product Backlog [ 10454 ]
          Fix Version/s --Sprint - 08/10 [ 10626 ]
          Hide
          Cynthia Wilburn (Inactive) added a comment -

          Can you please update this ticket with a proper component selection?

          If you do not have edit permissions, please add it as a comment.

          Thanks!

          Show
          Cynthia Wilburn (Inactive) added a comment - Can you please update this ticket with a proper component selection? If you do not have edit permissions, please add it as a comment. Thanks!
          Vicki Tsang made changes -
          Workflow Liferay Workflow 2.2 [ 206208 ] LPS Workflow [ 265144 ]
          Cynthia Wilburn (Inactive) made changes -
          Status Reopened [ 4 ] Backlog [ 10021 ]
          Hide
          Arjun Mullick added a comment -

          I am using Liferay 6.0 and saw that some properties are made instance configurable like properties for
          terms of use and authentication type by keeping them as preference configurable setting ,
          can there be a way I can customize other property from PropsValues like (PropsValues.USERS_REMINDER_QUERIES_ENABLED) which are static variables.

          Though I am able yo fetch instance specific properties by kernel PropsUtil but PropsValues are referenced in many places in existing Liferay code and cant change it to PropsUtil , please suggest an alternate way to load instance specific class .

          Show
          Arjun Mullick added a comment - I am using Liferay 6.0 and saw that some properties are made instance configurable like properties for terms of use and authentication type by keeping them as preference configurable setting , can there be a way I can customize other property from PropsValues like (PropsValues.USERS_REMINDER_QUERIES_ENABLED) which are static variables. Though I am able yo fetch instance specific properties by kernel PropsUtil but PropsValues are referenced in many places in existing Liferay code and cant change it to PropsUtil , please suggest an alternate way to load instance specific class .
          Hide
          Milan Jaroš added a comment -

          According to my earlier comment:
          I mean that if something can be set at both Portal settings portlet and portal.properties there should be some comment line in portal.properties nearby that value.

          Show
          Milan Jaroš added a comment - According to my earlier comment: I mean that if something can be set at both Portal settings portlet and portal.properties there should be some comment line in portal.properties nearby that value.
          Hide
          Milan Jaroš added a comment -

          Arjun, I know this is not answer to your question but maybe it could be helpful for you.
          From my experience: Avoid using portal instances feature as long as it is possible. I prefer to create new server and database instance.

          Show
          Milan Jaroš added a comment - Arjun, I know this is not answer to your question but maybe it could be helpful for you. From my experience: Avoid using portal instances feature as long as it is possible. I prefer to create new server and database instance.
          Edward Gonzales made changes -
          Fix Version/s Product Backlog [ 10454 ]
          Andrew Kim made changes -
          Workflow LPS Workflow [ 265144 ] Restricted LPS Workflow [ 378936 ]
          Andrew Kim made changes -
          Workflow Restricted LPS Workflow [ 378936 ] Copy of LPS Workflow [ 406287 ]
          Andrew Kim made changes -
          Workflow Copy of LPS Workflow [ 406287 ] LPS Workflow [ 437906 ]
          Andrew Kim made changes -
          Workflow LPS Workflow [ 437906 ] Copy 2 of LPS Workflow [ 470224 ]
          Andrew Kim made changes -
          Workflow Copy 2 of LPS Workflow [ 470224 ] LPS Workflow [ 502120 ]
          Hide
          Randy Zhu added a comment -

          In preparation for Ideation; we are merging New Feature and Improvement tickets into a singular ticket type called “Feature Request”. Additional information to follow soon.

          Show
          Randy Zhu added a comment - In preparation for Ideation; we are merging New Feature and Improvement tickets into a singular ticket type called “Feature Request”. Additional information to follow soon.
          Randy Zhu made changes -
          Component/s Configuration > portal.properties [ 14553 ]
          Component/s Infrastructure > LDAP [ 10664 ]
          Randy Zhu made changes -
          Component/s Configuration [ 14552 ]
          Randy Zhu made changes -
          Workflow LPS Workflow [ 502120 ] LPS Feature Request Workflow [ 532820 ]
          Issue Type New Feature [ 2 ] Feature Request [ 64 ]
          Randy Zhu made changes -
          Workflow LPS Feature Request Workflow [ 532820 ] PUBLIC - LPS Feature Request Workflow [ 551031 ]
          Esther Sanz made changes -
          Component/s Portal Services [ 18013 ]
          Esther Sanz made changes -
          Component/s Configuration > portal.properties [ 14553 ]
          Esther Sanz made changes -
          Component/s Configuration [ 14552 ]
          Esther Sanz made changes -
          Component/s Portal Service > Mobile Device Rules > WURFL EE Impl [ 18082 ]
          Esther Sanz made changes -
          Component/s Security > Testing [ 18030 ]
          Component/s Security [ 10290 ]
          Esther Sanz made changes -
          Component/s Security [ 10290 ]
          Component/s Security > Testing [ 18030 ]
          Component/s Portal Service > Mobile Device Rules > WURFL EE Impl [ 18082 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Committed to SCM Committed to SCM
          160d 5h 25m 1 Marc Champion 13/Mar/09 11:00 AM
          Committed to SCM Committed to SCM Removed Status Removed Status
          33d 14h 35m 1 Brian Chan 16/Apr/09 1:35 AM
          Removed Status Removed Status Closed Closed
          20h 7m 1 Samuel Kong 16/Apr/09 9:43 PM
          Closed Closed Reopened Reopened
          72d 18h 55m 1 Ben Starr 28/Jun/09 4:38 PM
          Reopened Reopened Backlog Backlog
          1095d 23h 13m 1 Cynthia Wilburn (Inactive) 28/Jun/12 3:52 PM

            People

            • Votes:
              10 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since last comment:
                2 years, 9 weeks, 1 day ago

                Development

                  Structure Helper Panel