date:20100202

[magnolia-dev] [JIRA] Resolved: (MGNLSTK-557) Demo content: No dummy events for 2010

2010-02-02 Thread JIRA (on behalf of Federico Grilli)



 [ 
http://jira.magnolia-cms.com/browse/MGNLSTK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Federico Grilli resolved MGNLSTK-557.
-

Resolution: Fixed

 Demo content: No dummy events for 2010
 --

 Key: MGNLSTK-557
 URL: http://jira.magnolia-cms.com/browse/MGNLSTK-557
 Project: Magnolia Standard Templating Kit
  Issue Type: Bug
  Components: demoproject
Affects Versions: 1.2.1
Reporter: Christian Ringele
Assignee: Federico Grilli
 Fix For: 1.2.x

 Attachments: website.demo-project.service.dummy-events.xml


 All dummy events in the demo content are events of the year 2009.
 The events are located under: demo-project/service/dummy-events/
 These events should be updated to 2010.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Resolved: (MGNLSTK-533) pur integration in templating kit breaks with external users.

2010-02-02 Thread JIRA (on behalf of Federico Grilli)



 [ 
http://jira.magnolia-cms.com/browse/MGNLSTK-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Federico Grilli resolved MGNLSTK-533.
-

Resolution: Fixed

 pur integration in templating kit breaks with external users.
 -

 Key: MGNLSTK-533
 URL: http://jira.magnolia-cms.com/browse/MGNLSTK-533
 Project: Magnolia Standard Templating Kit
  Issue Type: Bug
  Components: paragraphs
Reporter: Rico Jansen
Assignee: Federico Grilli
 Fix For: 1.2.3, 1.3, 1.2.2

 Attachments: freemarker-user-unsupportedexception.patch, 
 link-ftl.patch, user-model.patch


 I have an issue with an exception that occurs when I log in with an LDAP 
 account,
 the adminInterface works fine , but the site gives an exception:
 2009-11-20 11:00:31,969 ERROR freemarker.runtime  
   :
 Method public java.lang.String 
 info.magnolia.cms.security.ExternalUser.getProperty(java.lang.String) threw 
 an exception when invoked on info.magnolia.cms.security.externalu...@11fde0
 The problematic instruction:
 --
 == assignment: userFullName=ctx.user.getProperty(title)!userName [on line 
 4, column 1 in templating-kit/paragraphs/pur/link.ftl]
 --
 Java backtrace for programmers:
 --
 freemarker.template.TemplateModelException: Method public java.lang.String 
 info.magnolia.cms.security.ExternalUser.getProperty(java.lang.String) threw 
 an exception when invoked on info.magnolia.cms.security.externalu...@11fde0
 at freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:130)
 at freemarker.core.MethodCall._getAsTemplateModel(MethodCall.java:93)
 at freemarker.core.Expression.getAsTemplateModel(Expression.java:89)
 at 
 freemarker.core.DefaultToExpression._getAsTemplateModel(DefaultToExpression.java:100)
 Caused by: java.lang.UnsupportedOperationException: not implemented for this 
 ExternalUser
 at 
 info.magnolia.cms.security.ExternalUser.getProperty(ExternalUser.java:155)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 It seems that the / templating-kit/paragraphs/pur/link.ftl tries to get the 
 fullname from an external user:
 [#assign userFullName = ctx.user.getProperty(title)!userName]
 But ExternalUser has this as
 its getProperty:
 public String getProperty(String propertyName) {
 throw new UnsupportedOperationException(not implemented for this 
 ExternalUser);
 }
 I am currently runing Magnolia Enterprise Edition 4.1RC1 and
 Templating Kit  Standard 1.2RC2 , Extended 1.2RC1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com

[magnolia-dev] Fwd: Product Team Meeting (2010.02.01): Protocol

2010-02-02 Thread Philipp Bärfuss

...Maintenancegoing to release STK 1.2.3mgnlstk-...@jiramgnlstk-...@jira4.3/Sprint IIupdated theroadmap pageupdate the newmindmapthanks to Grégory we have now an automatedburndown chartexports to xml and counts the progress iconsVideosmake them today so that we can finally close sprint Ido not fake features (its also a status report)make them before releasing in future to get the chance to fix some small thingslicense for screenflow: Boris will export the resultadd them to theroadmap page



Forlistdetailssee
http://www.magnolia-cms.com/home/community/mailing-lists.html
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3051) Ideas for improvements: drop the metadata node

2010-02-02 Thread on behalf of Grégory Joseph

[
http://jira.magnolia-cms.com/browse/MAGNOLIA-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=26304#action_26304
]

Grégory Joseph commented on MAGNOLIA-3051:
--

That's something we've been wanting to do for a while too. API-wise, it should
indeed be fine, although there *are* places where MetaData is accessed as a
regular node (at least with tests) - but worst case that should be
workaround-able via code too. The one thing that holds us back is updates. And
time.
The tree and other related classes would probably need to be adapted too.

Ideas for improvements: drop the metadata node
--

Key: MAGNOLIA-3051
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3051
Project: Magnolia
Issue Type: Improvement
Components: core
Reporter: Fabrizio Giustina
Assignee: Boris Kraft

Just a thought for the future: the metadata node is there just to hold a few
properties that could better stay in the actual node. All the properties are
already prefixed by mgnl: so they can be filtered easily when needed. Why
not removing metadata nodes at all?
This will bring a bunch of small nice effects:
- reduce (to half) the number of nodes in the repository, improving
performances (now every time a node is read, also its metadata node is
fetched).
- being able to sort properly on metadatas! A jcr query for sorting on the
creation date can be incredibly/unnecessary hard now (try getting all the
nodes with a in the title sorted by creation date... pretty evil)
- (minor) smaller/more readable xml files for bootstrap
We can easily keep APIs as they are now, since the MetaData class could just
fetch the same properties from the main node.
It will require a single-line change in the constructor, from:
{code}
this.node = workingNode.getNode(DEFAULT_META_NODE))
{code}
to:
{code}
this.node = workingNode;
{code}
I don't think metadatas are accessed directly in different ways, so updating
the APIs as described is probably enough. Redefining the nodetypes
declaration and adding a filter for xml import should complete the work.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

40 matches

Mail list logo