[magnolia-dev] [JIRA] Created: (MGNLSTK-692) Glossary Letter paragraph only displays 5 terms

2010-10-25 Thread JIRA (on behalf of Matt Dertinger)

Glossary Letter paragraph only displays 5 terms
---

 Key: MGNLSTK-692
 URL: http://jira.magnolia-cms.com/browse/MGNLSTK-692
 Project: Magnolia Standard Templating Kit
  Issue Type: Bug
  Components: paragraphs, templates
Affects Versions: 1.3.5
Reporter: Matt Dertinger
Assignee: Philipp Bärfuss
 Attachments: 
config.modules.standard-templating-kit.dialogs.paragraphs.features.stkGlossaryLetter.xml.patch,
 glossaryLetter.ftl.patch

Hi,

I came across this issue while working with the Glossary templates. Currently, 
the Glossary Letter paragraph doesn't allow you to configure the number of 
terms to display.  It includes the {{glossaryTermsPerLetter.ftl}} macro, then 
makes the following call:

{code:xml}
[...@glossarytermsperletter letter=actualLetter /]
{code}

Since it doesn't set the {{maxTerms}} attribute, the 
{...@glossarytermsperletter}} macro sets the {{maxTerms}} to {{5}}

Here is the relevant code segment from the {{glossaryTermsPerLetter}} macro:

{code:xml}
[#macro glossaryTermsPerLetter letter maxTerms=5]

[#list letter?children as term]
[#if term?node_type == "mgnl:content" && term_index < maxTerms]
${term.title!te...@name}
[/#if]
[/#list]

[#if letter?children?size > maxTerms]
${i18n['glossary.seeAllTerms']} 
'${lett...@name}'
[/#if]
[/#macro]
{code}

In addition, the {{stkGlossaryLetter}} template definition sets the 
{{defaultValue}} for {{maxTermsPerLetter}} to {{6}}.  However, this would only 
have an effect if the {{maxTerms}} attribute was set using this value.

There are a few approaches I can think of to resolve this issue, but I'm not 
entirely sure which one would be best.

h2. Approach 1 
Add {{maxTerms=content.maxTermsPerLetter!1000}} to the call to the 
{{glossaryTermsPerLetter}} macro in the {{glossaryLetter.ftl}} paragraph. Then 
update the Template Definition for {{stkGlossaryLetter}}, removing the 
{{mainArea/autoGeneratedParagraph/defaultValues}} content node that sets 
{{maxTermsPerLetter}} to {{6}}.

h2. Approach 2 
Modify the {{glossaryTermsPerLetter.ftl}} macro, set the default value for 
{{maxTerms}} to {{1000}}.

For instance:

{code:xml|title=glossaryTermsPerLetter.ftl}
[#macro glossaryTermsPerLetter letter maxTerms=1000]

[#list letter?children as term]
[#if term?node_type == "mgnl:content" && term_index < maxTerms]
${term.title!te...@name}
[/#if]
[/#list]

[#if letter?children?size > maxTerms]
${i18n['glossary.seeAllTerms']} 
'${lett...@name}'
[/#if]
[/#macro]
{code}

h2. Approach 3 

(i) *Note:* I have attached patch files for the following approach.

# Modify the {{glossaryLetter.ftl}} paragraph
## Add an {{Edit}} bar that allows authors to set the {{maxTerms}} to display.
{code:xml}
[...@cms.editbar editLabel="${i18n['glossary.editLabel.paragraph']}" 
moveLabel="" deleteLabel="" /]
{code}
## Add {{maxTerms=content.maxTermsPerLetter!1000}} to the call to the 
{{glossaryTermsPerLetter}} macro, like so:
{code:xml|Updated glossaryLetter.ftl paragraph}
[#-- Rendering: Glossary all terms of its letter--]

${actualLetter?upper_case}
[...@glossarytermsperletter letter=actualLetter 
maxTerms=content.maxTermsPerLetter!1000 /]

{code}
# Modify the {{stkGlossaryLetter}} Dialog Definition 
## Add a {{maxTermsPerLetter}} content node to the {{stkGlossaryLetter}} Dialog 
Definition. @see 
{{config.modules.standard-templating-kit.dialogs.paragraphs.features.stkGlossaryLetter.xml.patch}}

Please let me know if you have any questions.

Thanks,
Matt


-- 
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: 




[magnolia-dev] [JIRA] Created: (MGNLSTK-691) Glossary Letter Template not available in Template drop-down menu

2010-10-25 Thread JIRA (on behalf of Matt Dertinger)

Glossary Letter Template not available in Template drop-down menu
-

 Key: MGNLSTK-691
 URL: http://jira.magnolia-cms.com/browse/MGNLSTK-691
 Project: Magnolia Standard Templating Kit
  Issue Type: Bug
  Components: demoproject, templates
Affects Versions: 1.3.5
Reporter: Matt Dertinger
Assignee: Philipp Bärfuss
 Attachments: glossary-letter-template-unavailable.png

Hi,

If someone mistakenly clicks on the template column for a page that uses the 
Glossary Letter template, they won't be able to change the template back to 
Glossary Letter.  This happens on the demoauthor.magnolia-cms.com site as well.

h2. Steps to reproduce
# Log in to AdminCentral
# Navigate to {{website/demo-project/service/glossary/a}}
# {{Double-click}} on the {{template}} column
# Notice that the Glossary Letter template is not available as an option (See 
attached screenshot).

Please let me know if you need more information.

h2. Possible Remedy
Would it be possible to update {{TemplateCategoryUtil}} to only allow templates 
with a {{subcategory}} of {{glossaryLetter}} under pages that have a template 
with a {{subcategory}} of {{glossary}}. In other words, the only allowable 
template under {{stkGlossary}} should be {{stkGlossaryLetter}}.  Likewise, the 
only allowable template under {{stkGlossaryLetter}} should be 
{{stkGlossaryTerm}}.  

Does this make sense?

Thanks,
Matt

-- 
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: 




[magnolia-dev] [JIRA] Updated: (BLOSSOM-20) Implement FactoryBean with similar functionality as ObservedComponentFactory

2010-10-25 Thread JIRA (on behalf of Tobias Mattsson)


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

Tobias Mattsson updated BLOSSOM-20:
---

Summary: Implement FactoryBean with similar functionality as 
ObservedComponentFactory  (was: Implement FactoryBean with similar 
functionality ObservedComponentFactory)

> Implement FactoryBean with similar functionality as ObservedComponentFactory
> 
>
> Key: BLOSSOM-20
> URL: http://jira.magnolia-cms.com/browse/BLOSSOM-20
> Project: Magnolia Blossom Module
>  Issue Type: New Feature
>Reporter: Tobias Mattsson
>Assignee: Tobias Mattsson
>Priority: Minor
>
> The FactoryBean will create a bean configured in a repository with support 
> for transparently reloading it on changes in repository. The bean needs to be 
> proxied and the bean should have AOP proxies from ApplicationContext applied. 
> If possible the bean should also be disposed using normal spring bean 
> lifecycle events. 

-- 
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: 




[magnolia-dev] [JIRA] Created: (BLOSSOM-20) Implement FactoryBean with similar functionality ObservedComponentFactory

2010-10-25 Thread JIRA (on behalf of Tobias Mattsson)

Implement FactoryBean with similar functionality ObservedComponentFactory
-

 Key: BLOSSOM-20
 URL: http://jira.magnolia-cms.com/browse/BLOSSOM-20
 Project: Magnolia Blossom Module
  Issue Type: New Feature
Reporter: Tobias Mattsson
Assignee: Tobias Mattsson
Priority: Minor


The FactoryBean will create a bean configured in a repository with support for 
transparently reloading it on changes in repository. The bean needs to be 
proxied and the bean should have AOP proxies from ApplicationContext applied. 
If possible the bean should also be disposed using normal spring bean lifecycle 
events. 

-- 
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: 




[magnolia-dev] [JIRA] Created: (BLOSSOM-19) Add support for DI and AOP in Content2Bean

2010-10-25 Thread JIRA (on behalf of Tobias Mattsson)

Add support for DI and AOP in Content2Bean
--

 Key: BLOSSOM-19
 URL: http://jira.magnolia-cms.com/browse/BLOSSOM-19
 Project: Magnolia Blossom Module
  Issue Type: New Feature
Reporter: Tobias Mattsson
Assignee: Tobias Mattsson
Priority: Minor


By extending Content2BeanTransformer the created bean can have autowiring and 
be post processed before and after initialization. This would enable the 
created bean to be post processed by all BeanPostProcessors in the root web 
application context, enabling support for InitializingBean, 
ServletContextAware, BeanFactoryAware, ApplicationContextAware and so on, 
including JSR-250 annotations @PostConstruct and @Resource. By modifying 
Content2BeanProcessor it would also be possible to support AOP proxies applied 
to the created bean.

-- 
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: 




[magnolia-dev] [JIRA] Updated: (MGNLFORM-61) Show a clearer error message for failed "noHTML" validation

2010-10-25 Thread JIRA (on behalf of Tobias Mattsson)


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

Tobias Mattsson updated MGNLFORM-61:


 Assignee: Tobias Mattsson  (was: Teresa Miyar)
Fix Version/s: 1.1.4

Integrated to branch 1.1

> Show a clearer error message for failed "noHTML" validation
> ---
>
> Key: MGNLFORM-61
> URL: http://jira.magnolia-cms.com/browse/MGNLFORM-61
> Project: Magnolia Form Module
>  Issue Type: Improvement
>Affects Versions: 1.1.4
>Reporter: Felix Rabe
>Assignee: Tobias Mattsson
> Fix For: 1.1.4
>
>
> The file 
> {{/magnolia-module-form/src/main/resources/info/magnolia/module/form/messages_en.properties}}
>  contains no line for the noHTML error message, showing a potentially 
> confusing "invalid input" instead.  Proposed change:
> {noformat}
>  form.user.errorMessage.number = must be a number
> +form.user.errorMessage.noHTML = characters "<>&" are not allowed
>  form.user.errorMessage.generic= Internal error, form could not be sent
> {noformat}
> I have applied this change locally and it works for me.

-- 
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: 




[magnolia-dev] [JIRA] Commented: (MGNLSTK-685) Possible Copy/Paste error in setBaseArea method of STKTemplate.java

2010-10-25 Thread JIRA (on behalf of Hudson CI server)


[ 
http://jira.magnolia-cms.com/browse/MGNLSTK-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30602#action_30602
 ] 

Hudson CI server commented on MGNLSTK-685:
--

Integrated in !http://hudson.magnolia-cms.com/images/16x16/blue.gif! 
[standard-templating-kit 
#2710|http://hudson.magnolia-cms.com/job/standard-templating-kit/2710/]
 MGNLSTK-685 fixing copy-pasta mistake, thanks Matt !


> Possible Copy/Paste error in setBaseArea method of STKTemplate.java
> ---
>
> Key: MGNLSTK-685
> URL: http://jira.magnolia-cms.com/browse/MGNLSTK-685
> Project: Magnolia Standard Templating Kit
>  Issue Type: Bug
>  Components: templates
>Affects Versions: 1.3.4
>Reporter: Matt Dertinger
>Assignee: Grégory Joseph
>Priority: Minor
> Fix For: 1.3.x
>
> Attachments: STKTemplate.java.patch
>
>
> Just noticed a small issue in STKTemplate.java, probably just a copy/paste 
> error.  The parameter name being passed in to the setBaseArea method is named 
> "platformArea", should be "baseArea". I've included the patch file.
> Thanks,
> Matt

-- 
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: 




[magnolia-dev] [JIRA] Resolved: (MGNLSTK-685) Possible Copy/Paste error in setBaseArea method of STKTemplate.java

2010-10-25 Thread on behalf of Grégory Joseph


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

Grégory Joseph resolved MGNLSTK-685.


 Assignee: Grégory Joseph  (was: Ondřej Chytil)
Fix Version/s: 1.3.x
   Resolution: Fixed

> Possible Copy/Paste error in setBaseArea method of STKTemplate.java
> ---
>
> Key: MGNLSTK-685
> URL: http://jira.magnolia-cms.com/browse/MGNLSTK-685
> Project: Magnolia Standard Templating Kit
>  Issue Type: Bug
>  Components: templates
>Affects Versions: 1.3.4
>Reporter: Matt Dertinger
>Assignee: Grégory Joseph
>Priority: Minor
> Fix For: 1.3.x
>
> Attachments: STKTemplate.java.patch
>
>
> Just noticed a small issue in STKTemplate.java, probably just a copy/paste 
> error.  The parameter name being passed in to the setBaseArea method is named 
> "platformArea", should be "baseArea". I've included the patch file.
> Thanks,
> Matt

-- 
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: 




[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3336) Multipart and Unicode filters do not release requests properly in case of errors

2010-10-25 Thread JIRA (on behalf of Hudson CI server)


[ 
http://jira.magnolia-cms.com/browse/MAGNOLIA-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30599#action_30599
 ] 

Hudson CI server commented on MAGNOLIA-3336:


Integrated in !http://hudson.magnolia-cms.com/images/16x16/blue.gif! 
[magnolia_main-4.4-branch 
#52|http://hudson.magnolia-cms.com/job/magnolia_main-4.4-branch/52/]
 MAGNOLIA-3336 Make sure the stack is released properly even on errors.


> Multipart and Unicode filters do not release requests properly in case of 
> errors
> 
>
> Key: MAGNOLIA-3336
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3336
> Project: Magnolia
>  Issue Type: Bug
>Affects Versions: 4.3.7
>Reporter: Jan Haderka
>Assignee: Jan Haderka
>Priority: Critical
> Fix For: 4.4.x
>
>
> {{CosMultipartFilter}},{{MultipartFilter}} and {{UnicodeNormalization 
> filter}} manage stack of request/response wrappers on their own and do not 
> release those objects from the stack properly in case of errors the same way 
> {{ContextFilter}} does.
> They need to wrap chain execution in try block and make sure stack is updated 
> after execution even in case of errors.

-- 
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: 




[magnolia-dev] [JIRA] Created: (MAGNOLIA-3336) Multipart and Unicode filters do not release requests properly in case of errors

2010-10-25 Thread JIRA (on behalf of Jan Haderka)

Multipart and Unicode filters do not release requests properly in case of errors


 Key: MAGNOLIA-3336
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3336
 Project: Magnolia
  Issue Type: Bug
Affects Versions: 4.3.7
Reporter: Jan Haderka
Assignee: Jan Haderka
Priority: Critical
 Fix For: 4.4.x


{{CosMultipartFilter}},{{MultipartFilter}} and {{UnicodeNormalization filter}} 
manage stack of request/response wrappers on their own and do not release those 
objects from the stack properly in case of errors the same way 
{{ContextFilter}} does.
They need to wrap chain execution in try block and make sure stack is updated 
after execution even in case of errors.

-- 
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: 




[magnolia-dev] hold commits to the form module

2010-10-25 Thread Tobias Mattsson

please hold all commits to the form module as im in the process of creating a 
branch for 1.1 where the next release will be 1.1.4, trunk will become 1.2 and 
contain multi step support

// Tobias


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




[magnolia-dev] [JIRA] Resolved: (MGNLFORM-26) Add delete button for the form paragraph

2010-10-25 Thread JIRA (on behalf of Zdenek Skodik)


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

Zdenek Skodik resolved MGNLFORM-26.
---

Fix Version/s: 1.1.4
   (was: 1.2)
   Resolution: Fixed

> Add delete button for the form paragraph
> 
>
> Key: MGNLFORM-26
> URL: http://jira.magnolia-cms.com/browse/MGNLFORM-26
> Project: Magnolia Form Module
>  Issue Type: Improvement
>Reporter: Teresa Miyar
>Assignee: Zdenek Skodik
> Fix For: 1.1.4
>
>


-- 
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: 




[magnolia-dev] [JIRA] Commented: (MGNLFORM-26) Add delete button for the form paragraph

2010-10-25 Thread JIRA (on behalf of Hudson CI server)


[ 
http://jira.magnolia-cms.com/browse/MGNLFORM-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30594#action_30594
 ] 

Hudson CI server commented on MGNLFORM-26:
--

Integrated in !http://hudson.magnolia-cms.com/images/16x16/blue.gif! 
[magnolia-module-form 
#1178|http://hudson.magnolia-cms.com/job/magnolia-module-form/1178/]
 MGNLFORM-26 - add delete button to the form paragraph bar


> Add delete button for the form paragraph
> 
>
> Key: MGNLFORM-26
> URL: http://jira.magnolia-cms.com/browse/MGNLFORM-26
> Project: Magnolia Form Module
>  Issue Type: Improvement
>Reporter: Teresa Miyar
>Assignee: Zdenek Skodik
> Fix For: 1.2
>
>


-- 
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: 




[magnolia-dev] [JIRA] Commented: (MGNLFORM-26) Add delete button for the form paragraph

2010-10-25 Thread JIRA (on behalf of Zdenek Skodik)


[ 
http://jira.magnolia-cms.com/browse/MGNLFORM-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30593#action_30593
 ] 

Zdenek Skodik commented on MGNLFORM-26:
---

It's about adding a delete button to the main form bar since at the moment one 
can delete just a field set or particular fields but not the whole form from 
within the page. 


> Add delete button for the form paragraph
> 
>
> Key: MGNLFORM-26
> URL: http://jira.magnolia-cms.com/browse/MGNLFORM-26
> Project: Magnolia Form Module
>  Issue Type: Improvement
>Reporter: Teresa Miyar
>Assignee: Zdenek Skodik
> Fix For: 1.2
>
>


-- 
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: 




[magnolia-dev] [JIRA] Resolved: (MAGNOLIA-3334) FckEditor images not handled correctly without context path in URL

2010-10-25 Thread on behalf of Ondřej Chytil


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

Ondřej Chytil resolved MAGNOLIA-3334.
-

Fix Version/s: 4.3.8
   (was: 4.3.x)
   Resolution: Fixed

> FckEditor images not handled correctly without context path in URL
> --
>
> Key: MAGNOLIA-3334
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3334
> Project: Magnolia
>  Issue Type: Bug
>  Components: core, fckeditor
>Affects Versions: 4.3.7
>Reporter: Ondřej Chytil
>Assignee: Ondřej Chytil
> Fix For: 4.3.8
>
>
> When inserting images in fckEditor from DMS without context path in URL image 
> is rendered on page after saving but not in edit mode of fckEditor or in 
> preview window.

-- 
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: 




[magnolia-dev] Code freeze on 4.3 branches!

2010-10-25 Thread Grégory Joseph

Hey there,Magnolia 4.3.8 is about to get released. Hang on to your shorts, please do not commit on the 4.3 branches until the release.Cheers,-greg



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





[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3264) UnicodeNormalizerRequestWrapper.getParameterMap() may return a stale result in case of forwards

2010-10-25 Thread on behalf of Ondřej Chytil


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

Ondřej Chytil updated MAGNOLIA-3264:


Fix Version/s: 4.3.8
   (was: 4.3.x)

> UnicodeNormalizerRequestWrapper.getParameterMap() may return a stale result 
> in case of forwards
> ---
>
> Key: MAGNOLIA-3264
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3264
> Project: Magnolia
>  Issue Type: Bug
>Affects Versions: 4.3.5
>Reporter: Fabrizio Giustina
>Assignee: Ondřej Chytil
> Fix For: 4.3.8
>
>
> When utf8 is enabled, forwards with added parameters may not work correctly 
> due to unicode normalization which doesn't "see" added parameters.
> For example, if you have a regexp virtual uri with:
> {noformat}
> ^/my/path/(.*)\.html
> forward://my/path/page.html?product=$1
> {noformat}
> the "product" parameter is seen in the destination page only if uft8 is 
> disabled.
> This is due to the getParameterMap() method in 
> UnicodeNormalizerRequestWrapper which caches the map with normalized 
> parameters after the forward:
> {noformat}
> public Map getParameterMap()
> {
> if (parameters == null)
> {
> parameters = new HashMap();
> for (Object key : original.getParameterMap().keySet())
> {
> String[] value = transform((String[]) 
> original.getParameterMap().get(key));
> parameters.put(key, value);
> }
> }
> return parameters;
> }
> {noformat}
> removing the " if (parameters == null)" check and making normalization all 
> the times is enough to fix it, but this will add an unwanted overhead. We 
> should find a way to re-normalize the parameter map only when the request 
> gets overridden

-- 
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: 




[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3321) Rotating virtual URI mapping does not return expected values

2010-10-25 Thread on behalf of Ondřej Chytil


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

Ondřej Chytil updated MAGNOLIA-3321:


Fix Version/s: 4.3.8
   (was: 4.3.x)

> Rotating virtual URI mapping does not return expected values 
> -
>
> Key: MAGNOLIA-3321
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3321
> Project: Magnolia
>  Issue Type: Bug
>  Components: core
>Affects Versions: 4.3.7
>Reporter: Antti Hietala
>Assignee: Ondřej Chytil
>Priority: Minor
> Fix For: 4.3.8
>
>
> [API doc for 
> RotatingVirtualURIMapping|http://dev.magnolia-cms.com/ref/latest/apidocs/info/magnolia/cms/beans/config/RotatingVirtualURIMapping.html]
>  says: "An extension of RegexpVirtualURIMapping that allows a rotation 
> between different destination urls. In order to rotate {{toURI}} must contain 
> the {{*}} that will be replaced by a random number between {{start}} (default 
> is 1) and {{end}} (default is 3)."
> The code does not return random integers between {{start}} and {{end}}. It 
> returns integers between one and "end minus start".
> {code:java}int randomNumber = RandomUtils.nextInt(end - start) + 1;{code}
> || {{start}} || {{end}} || {{RandomUtils.nextInt(end - start) + 1}} ||
> | 0 | 3 | 1...3 |
> | 1 | 3 | 1...2 |
> | 1 | 4 | 1...3 |
> | 2 | 5 | 1...3 |
> | 3 | 7 | 1...4 |
> | 4 | 9 | 1...5 |
> Kindly revise the code to return integers between {{start}} and {{end}}. This 
> is potentially quite useful.

-- 
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: 




[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3310) UnicodeNormalizationFilter seems to be messing up the virtualUriMappings

2010-10-25 Thread on behalf of Ondřej Chytil


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

Ondřej Chytil updated MAGNOLIA-3310:


Fix Version/s: 4.3.8
   (was: 4.3.x)

> UnicodeNormalizationFilter seems to be messing up the virtualUriMappings
> 
>
> Key: MAGNOLIA-3310
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3310
> Project: Magnolia
>  Issue Type: Bug
>  Components: core
>Affects Versions: 4.3.6
>Reporter: Ernst Bunders
>Assignee: Ondřej Chytil
>Priority: Critical
> Fix For: 4.3.8
>
>
> Hello
> I discovered a problem with a virtual uri mapping (of type forward)and the 
> UnicodeNormalizationFilter. What i try to do is the following:
> I have a processed css file that creates the css for a configurable theme. 
> The theme also has a dialog that lets you do all kinds of theme settings.
> The theme css is called with some parameters: the uuid of the page node (to 
> resolve the theme config), and a version parameter (to create uniuque urls 
> for each 'version' of the theme).
> What i want is a virtalUriMapping for this css request, so i can call it 
> without request parameters, making it more cachable. Here is the 
> virtualUriMapping config:
> class: info.magnolia.cms.beans.config.RegexpVirtualURIMapping
> fromURI:  ^/themes/([^/]+)/([0-9]+)/theme\.css$
> toURI:  
> forward:/resources/vpro/themes/pip/css/theme.css?uuid=$1&lastmodified=$2
> this way i can call my css from the template like: 
> http://localhost:8080/pip/themes/1fb8d8e1-d625-4c24-95a3-904e0102eddd/1286288160080/theme.css
> And the request is forwarded to: 
> /resources/vpro/themes/pip/css/theme.css?uuid=1fb8d8e1-d625-4c24-95a3-904e0102eddd&lastmodified=1286288160080
> So that works but oh lala: when the css model class kicks into action: no 
> more request parameters.
> I put some breakpoints here and there and this is what i see:
> - Every request object is wrapped with a 
> info.magnolia.cms.filters.UnicodeNormalizationFilter.UnicodeNormalizerRequestWrapper
>  by the UnicodeNormalizationFilter filter.
> - this method has a method getParameterMap(), that will look into the wrapped 
> request and fetch the parameters only once.
> - so the first time the VirtualUriFilter is hit, the request wrapper is 
> wrapping a request with no parameters. So the 
> UnicodeNormalizerRequestWrapper.parameters map is empty.
> - The virtualUriMapping is found, the 'forward:' prefix is found, and a 
> request dispatcher is created (with proper requestUri and queryString values).
> - the request is forwarded.
> - At this point i would expect a new request to be created and reinserted 
> into the whole requests handling pipeline. So the next time 
> UnicodeNormalizationFilter is hit, i expect the request to be unwrapped. To 
> my surprise this is not the case. the request is wrapped already, and the 
> wrapper still has the parameters map (with zero entries)  from the first 
> request.
> The wrapper now wraps two requests! In it's field 'original' there is the 
> request with url:  
> http://localhost:8080/pip/themes/1fb8d8e1-d625-4c24-95a3-904e0102eddd/1286288160080/theme.css
>  (the first request), and in it's field 'request' (inherited from 
> HttpServletRequestWrapper) a request with url: 
> /resources/vpro/themes/pip/css/theme.css and queryString: 
> uuid=1fb8d8e1-d625-4c24-95a3-904e0102eddd&lastmodified=1286288160080 ( the 
> new request)
> All a bit surprising, and It seems to me that the wrapper is still around at 
> the second request handling. Another thing that seems strange: why does the 
> UnicodeNormalizerRequestWrapper has it's own field for the wrapped request 
> and parameters, as it already extends HttpServletRequestWrapper. It seems to 
> me that the only method that actually adds someting is getHeader(String name).
> And thus: when i switch of the UnicodeNormalization filter: it works!

-- 
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: 




[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3229) Use new office address in Magnolia Login Form

2010-10-25 Thread on behalf of Ondřej Chytil


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

Ondřej Chytil updated MAGNOLIA-3229:


Fix Version/s: 4.3.8
   (was: 4.3.x)

> Use new office address in Magnolia Login Form
> -
>
> Key: MAGNOLIA-3229
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3229
> Project: Magnolia
>  Issue Type: Bug
>Affects Versions: 4.3.2
>Reporter: Zdenek Skodik
>Assignee: Zdenek Skodik
> Fix For: 4.2.x, 4.1.x, 4.3.8, 5.0, 4.0.x
>
>
> [here|http://svn.magnolia-cms.com/svn/community/magnolia/trunk/magnolia-module-admininterface/src/main/resources/mgnl-resources/loginForm/login.html].
>  Current year would be also taken into account for the copyright years.

-- 
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: 




[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3231) Update translations

2010-10-25 Thread on behalf of Ondřej Chytil


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

Ondřej Chytil updated MAGNOLIA-3231:


Fix Version/s: 4.3.8
   (was: 4.3.x)

> Update translations
> ---
>
> Key: MAGNOLIA-3231
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3231
> Project: Magnolia
>  Issue Type: Task
>  Components: contributions, i18n
>Reporter: Grégory Joseph
>Assignee: Grégory Joseph
>Priority: Blocker
> Fix For: 4.3.8, 4.4.x, 5.0
>
>
> Our translations are outdated. We started a translation effort - see 
> http://documentation.magnolia-cms.com/contribute/i18n.html - this issue will 
> track effort and updates to translations files!

-- 
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: 




[magnolia-dev] [JIRA] Updated: (MGNLFORM-63) Magnolia Form Module does not support i18n

2010-10-25 Thread on behalf of Grégory Joseph


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

Grégory Joseph updated MGNLFORM-63:
---

Fix Version/s: 1.2
  Description: 
The magnolia Form Module is not configured to support multiple languages (i18n.)

Modifying it to support i18n appears to be trivial, and involves setting a 
property of i18n to true for each control defined for the form dialogs.

Here is a short example Groovy script that does that:

{code}
hm = ctx.getHierarchyManager('config')
root = hm.getContent("/modules/form/dialogs")
root.getChildren("mgnl:contentNode").each{cn->
  cn.getChildren("mgnl:contentNode").each{cn2->
cn2.getChildren("mgnl:contentNode").findAll{cn3->
  cn3.controlType == 'edit'
}.each{editControl ->
  if(!editControl.i18n) {
editControl.setNodeData('i18n', true)
editControl.save()
  }
}  
  }
}
{code}

  was:
The magnolia Form Module is not configured to support multiple languages (i18n.)

Modifying it to support i18n appears to be trivial, and involves setting a 
property of i18n to true for each control defined for the form dialogs.

Here is a short example Groovy script that does that:


hm = ctx.getHierarchyManager('config')
root = hm.getContent("/modules/form/dialogs")
root.getChildren("mgnl:contentNode").each{cn->
  cn.getChildren("mgnl:contentNode").each{cn2->
cn2.getChildren("mgnl:contentNode").findAll{cn3->
  cn3.controlType == 'edit'
}.each{editControl ->
  if(!editControl.i18n) {
editControl.setNodeData('i18n', true)
editControl.save()
  }
}  
  }

}


> Magnolia Form Module does not support i18n
> --
>
> Key: MGNLFORM-63
> URL: http://jira.magnolia-cms.com/browse/MGNLFORM-63
> Project: Magnolia Form Module
>  Issue Type: Improvement
>Affects Versions: 1.1.2
> Environment: All
>Reporter: Corin Moss
>Assignee: Tobias Mattsson
>Priority: Minor
> Fix For: 1.2
>
>
> The magnolia Form Module is not configured to support multiple languages 
> (i18n.)
> Modifying it to support i18n appears to be trivial, and involves setting a 
> property of i18n to true for each control defined for the form dialogs.
> Here is a short example Groovy script that does that:
> {code}
> hm = ctx.getHierarchyManager('config')
> root = hm.getContent("/modules/form/dialogs")
> root.getChildren("mgnl:contentNode").each{cn->
>   cn.getChildren("mgnl:contentNode").each{cn2->
> cn2.getChildren("mgnl:contentNode").findAll{cn3->
>   cn3.controlType == 'edit'
> }.each{editControl ->
>   if(!editControl.i18n) {
> editControl.setNodeData('i18n', true)
> editControl.save()
>   }
> }  
>   }
> }
> {code}

-- 
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: 




[magnolia-dev] [JIRA] Updated: (MGNLFORM-26) Add delete button for the form paragraph

2010-10-25 Thread on behalf of Grégory Joseph


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

Grégory Joseph updated MGNLFORM-26:
---

Fix Version/s: 1.2

What's the status of this issue ?
Can we get a more detailed description ?

> Add delete button for the form paragraph
> 
>
> Key: MGNLFORM-26
> URL: http://jira.magnolia-cms.com/browse/MGNLFORM-26
> Project: Magnolia Form Module
>  Issue Type: Improvement
>Reporter: Teresa Miyar
>Assignee: Zdenek Skodik
> Fix For: 1.2
>
>


-- 
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: 




[magnolia-dev] [JIRA] Updated: (MGNLFORM-58) Add support for multi step forms

2010-10-25 Thread on behalf of Grégory Joseph


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

Grégory Joseph updated MGNLFORM-58:
---

Fix Version/s: 1.2

> Add support for multi step forms
> 
>
> Key: MGNLFORM-58
> URL: http://jira.magnolia-cms.com/browse/MGNLFORM-58
> Project: Magnolia Form Module
>  Issue Type: New Feature
>Reporter: Tobias Mattsson
>Assignee: Tobias Mattsson
> Fix For: 1.2
>
>
> Add support for multi step forms. Relies in the addition of preexecution in 
> magnolia-core.
> * Each step will be configured on a page of its own so that different steps 
> can be on a page with content specific to that step.
> * The back button must work as expected.
> * Must be able to use the same form in multiple tabs. Tabs should not use 
> each others values.

-- 
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: 




[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3333) LockTimeoutException

2010-10-25 Thread on behalf of Grégory Joseph


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

Grégory Joseph updated MAGNOLIA-:
-

Component/s: cache
 (was: content2bean)

> LockTimeoutException
> 
>
> Key: MAGNOLIA-
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-
> Project: Magnolia
>  Issue Type: Bug
>  Components: cache
>Reporter: Grégory Joseph
>Assignee: Boris Kraft
> Fix For: 4.3.3
>
> Attachments: MAGNOLIA--exception.txt
>
>
> I've noticed a lot of exceptions like the attached on our documentation 
> website. I have currently no idea why this happens. Restarting the instance 
> "solves" the issue.
> There is a secondary issue to this: the exception appears both in the logs 
> and on screen. I believe this type of exception should never been rendered in 
> the client of a public instance (it shows some information that might be 
> considered sensitive). (perhaps a good generic solution to this problem would 
> be a filter intercepting all exceptions and rendering a default uninformative 
> error page on public instances)

-- 
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: 




[magnolia-dev] [JIRA] Commented: (MGNLFORM-63) Magnolia Form Module does not support i18n

2010-10-25 Thread on behalf of Philipp Bärfuss


[ 
http://jira.magnolia-cms.com/browse/MGNLFORM-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30590#action_30590
 ] 

Philipp Bärfuss commented on MGNLFORM-63:
-

Thanks for the helpful script. We should truly add this i18n flags to the form 
dialogs.

> Magnolia Form Module does not support i18n
> --
>
> Key: MGNLFORM-63
> URL: http://jira.magnolia-cms.com/browse/MGNLFORM-63
> Project: Magnolia Form Module
>  Issue Type: Improvement
>Affects Versions: 1.1.2
> Environment: All
>Reporter: Corin Moss
>Assignee: Tobias Mattsson
>Priority: Minor
>
> The magnolia Form Module is not configured to support multiple languages 
> (i18n.)
> Modifying it to support i18n appears to be trivial, and involves setting a 
> property of i18n to true for each control defined for the form dialogs.
> Here is a short example Groovy script that does that:
> hm = ctx.getHierarchyManager('config')
> root = hm.getContent("/modules/form/dialogs")
> root.getChildren("mgnl:contentNode").each{cn->
>   cn.getChildren("mgnl:contentNode").each{cn2->
> cn2.getChildren("mgnl:contentNode").findAll{cn3->
>   cn3.controlType == 'edit'
> }.each{editControl ->
>   if(!editControl.i18n) {
> editControl.setNodeData('i18n', true)
> editControl.save()
>   }
> }  
>   }
> }

-- 
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: