[JBoss JIRA] Created: (JBPORTAL-1929) Relative links in CMS content munged by WYSIWYG editor
by Martin Putz (JIRA)
Relative links in CMS content munged by WYSIWYG editor
------------------------------------------------------
Key: JBPORTAL-1929
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1929
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal CMS
Affects Versions: 2.6.4 Final
Reporter: Martin Putz
Assigned To: Sohil Shah
Relative links defined in CMS content are munged by the WYSIWYG editor, which results in incorrect links if multiple CMS instances are used on different portals.
For instance, the default content has a link from 'default/index.html' to 'default/support.html'. In the original file jboss-portal.sar/portal-cms.sar/portal/cms/conf/default-content/default/index.html, this link is defined as
<a href="default/support.html">Explore</a>
This is fine, as it works correctly, even if I have a second CMS instance on another portal.
As soon as I open the file in the CMS admin portlet, however, this link is changed to
<a href="/portal/content/default/support.html">Explore</a>
which is problematic, as it always opens up this CMS content inside the default portal.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Created: (JBPORTAL-2033) User with only read-permissions on a folder cannot read a folder
by Wulf Rowek (JIRA)
User with only read-permissions on a folder cannot read a folder
----------------------------------------------------------------
Key: JBPORTAL-2033
URL: http://jira.jboss.com/jira/browse/JBPORTAL-2033
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal CMS
Reporter: Wulf Rowek
Assigned To: Sohil Shah
In the ACLInterceptor is special part of code (applyFilter method), which was obousily created to hide items from a user which have no write access and browse in a tool portlet (i.e. CMSAdmin)
but this aim should not be satisfied on ACL-Level, in my opinion, cause it's a contradiction, that a user have read permission but cannot read the item.
and to read a folder by a user seems to be a legitimate request, even if he has no write permission, i.e. to build a folder-index and browse a folder.
possible solution: specify the need of the result in the command (i.e. only read or something else) and don't filter, if the result of the command will be needed for reading only.
or maybe better: filter on application level, after the result was catched from the command by the excecuter
at this moment, i just commented out this line in applyFiler
securityContext.removeAttribute("command");
to disable this feature at all and to give read-permitted users read access
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Created: (JBAS-5589) Update hibernate-int module to understand RegionFactory
by Brian Stansberry (JIRA)
Update hibernate-int module to understand RegionFactory
-------------------------------------------------------
Key: JBAS-5589
URL: http://jira.jboss.com/jira/browse/JBAS-5589
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Clustering, Hibernate service
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.CR2
The org.jboss.hibernate.jmx.Hibernate class has some pass-through setters for configuring a CacheProvider. Need to add equivalent for a RegionFactory.
Also need to determine what to do with org.jboss.hibernate.cache.DeployedTreeCacheProvider. It's really a second (unmaintained) version of the old legacy org.jboss.ejb3.entity.TreeCacheProviderHook stuff. Perhaps the thing to do is pull the core TreeCacheProviderHook code into an external project and have both DeployedTreeCacheProvider and TreeCacheProviderHook be trivial subclasses of a common class provided solely for legacy configuration support.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months