[JBoss JIRA] Created: (GTNPORTAL-1122) Portlet icons locations need to be skin independent [or dependent]
by Matt Wringe (JIRA)
Portlet icons locations need to be skin independent [or dependent]
------------------------------------------------------------------
Key: GTNPORTAL-1122
URL: https://jira.jboss.org/jira/browse/GTNPORTAL-1122
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Matt Wringe
If a portlet wants to have a custom icon shown in the application registry or in the page editor, then they can place a png in a special location.
Currently this location is:
skin/DefaultSkin/portletIcons/PortletName.png
But this icon is shown for all skins, regardless if its the DefaultSkin or not (see ApplicationRegistryServiceImpl.getApplicationIconURL for where its hardcoded to this)
This location should be changed to a location which doesn't mention DefaultSkin, or it should be changed so that it is dependent on the current portal skin (for example skin/SimpleSkin/portleticons/PortletName.png would be the icon if the current portal skin is the SimpleSkin).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (GTNPORTAL-1250) There are useless messages printed by UIPortlet class.
by le thanh quang (JIRA)
There are useless messages printed by UIPortlet class.
------------------------------------------------------
Key: GTNPORTAL-1250
URL: https://jira.jboss.org/browse/GTNPORTAL-1250
Project: GateIn Portal
Issue Type: Task
Security Level: Public (Everyone can see)
Components: WebUI
Affects Versions: 3.0.0-GA
Reporter: le thanh quang
There are some useless messages at info level printed by org.exoplatform.portal.webui.application.UIPortlet class when load a portlet. The messages are as following log section:
Apr 16, 2010 4:39:05 PM org.exoplatform.portal.webui.application.UIPortlet supportsPublishingEvent
INFO: The portlet PortletContext[local./forum.ForumPortlet] doesn't support producing the event : QuickReplyEvent
Apr 16, 2010 4:39:05 PM org.exoplatform.portal.webui.application.UIPortlet supportsPublishingEvent
INFO: The portlet PortletContext[local./forum.ForumPortlet] doesn't support producing the event : ForumPollEvent
Apr 16, 2010 4:39:05 PM org.exoplatform.portal.webui.application.UIPortlet supportsPublishingEvent
In the contrast, if an event is configured as supported-publishing-event in portlet.xml file, another message is thrown as
May 26, 2010 2:12:38 PM org.exoplatform.portal.webui.application.UIPortlet supportsPublishingEvent
INFO: The Portlet PortletContext[local./forum.ForumPortlet] supports producing the event : QuickReplyEvent
Therefore, It's better if the such messages are refined to be more concise and convenient.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (GTNPORTAL-1230) Inherited node ACL
by Thomas Heute (JIRA)
Inherited node ACL
------------------
Key: GTNPORTAL-1230
URL: https://jira.jboss.org/browse/GTNPORTAL-1230
Project: GateIn Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Security
Reporter: Thomas Heute
Fix For: 3.2.0-GA
As of now it is difficult to maintain gazillion of nodes even in a hierarchy.
when you have:
A<-B<-C
(B is a child of A, C is a child of B)
and you want to restrict access to that tree, you need to define security rules on the 3 *pages*. (and modify the pages everytime you want to change a restriction)
As of now we don't have security restrictions on the node itself, we would need to add this feature and make it inherited.
the Picketlink Authz framework can do this effectively, but we would need an answer to this issue prior to the integration.
We should be able to tell that A is restricted to admins, and on an access to C check for parent restrictions. It should also be possible to add a restriction on B.
In some cases, one node may want to break the inheritance to define other rules.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (GTNPORTAL-1318) Provide a way to disable 'classic'
by Patrice Lamarque (JIRA)
Provide a way to disable 'classic'
----------------------------------
Key: GTNPORTAL-1318
URL: https://jira.jboss.org/browse/GTNPORTAL-1318
Project: GateIn Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 3.1.0-CR01
Reporter: Patrice Lamarque
Fix For: 3.2.0-GA
The 'classic' portal is builtin in gatein.
Extension writers will typically want to define their own portal different of 'classic'. They may want to make their own portal the default too.
Today, the only way to to this is to edit the portal.war and modify the builtin configuration for classic (UserPortalConfigService).
We need a way to indicate the portal to not attempt to load 'classic', but use another definition instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months