[magnolia-dev] [JIRA] (MGNLUI-2022) Property values in workbench view are not html encoded and hide leadind spaces.
Christian Ringele created MGNLUI-2022 Property values in workbench view are not html encoded and hide leadind spaces. Issue Type: Bug Affects Versions: 5.0.4 Assignee: Unassigned Attachments: Property-Displayed.png, Property-Displayed_ProducesHtml_FIlterOut_DivAndTD.png, Property-Displayed_With_Italic.png, Property-Edit_DivAndTD-FilteredOut.png, Property-Edit_Example1.png, Property-Edit_WithSpaces.png, Property-Edit_With_Italic.png Components: tree/list Created: 04/Sep/13 10:18 AM Description: By copy paste a full qualified class name (containing generics) I encountered a bug: The property values are not html encoded. So html within the property value is interpreted as such. Also it filters out leading spaces, you just don't see them. Which leads to many problems especially when you copy paste values (as for example from 'my first content app' tutorial.) I added print screens displaying this behavior. Fix Versions: 5.0.x Project: Magnolia UI Priority: Critical Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLSTK-1014) TemplatesAvailability reacts on node name and not on the defined id
Christian Ringele updated MGNLSTK-1014 TemplatesAvailability reacts on node name and not on the defined id Change By: Christian Ringele (12/Sep/13 1:05 PM) Summary: TemplatesAvailabilityreactsonnodenameandnoton hte the definedid This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLACTIVATION-40) Activation tool (not monitoring tool) missing in M5: Needed for public key creation
Christian Ringele created MGNLACTIVATION-40 Activation tool (not monitoring tool) missing in M5: Needed for public key creation Issue Type: Bug Affects Versions: 5.0.2 Assignee: Unassigned Attachments: FormerActivationTool.png Created: 22/Oct/13 10:16 AM Description: The former too to create public key for activation is missing. This tool/page should be ported asap. I tried to configure a app in tools by myself, but its not possible as the class and html page is not a part of the admin interface module anymore. Possible work around: Using a M4.5 instance to create the private public keys, and add them manually to the right places: Public Private key into file on author: /webapp/WEB-INF/config/default/magnolia-activation-keypair.properties Public key into config workspace on AuthorPublic instance: /config//server/activation/publicKey Fix Versions: 5.0.x Project: Magnolia Activation Module Priority: Critical Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-2371) CKEditor should be implemented using the Vaadin7 components.
Christian Ringele created MGNLUI-2371 CKEditor should be implemented using the Vaadin7 components. Issue Type: Bug Affects Versions: 5.1.1, 5.0.4 Assignee: Unassigned Components: dialogs Created: 11/Nov/13 2:11 PM Description: The CKEditor implementation should be refactored in two way: 1. Make it more flexible adding (and testing) CKEditor plugins: MGNLUI-1947 2. The Vaadin component should use the Vaadin7 data pipe for communication to the back end and not the legacy Vaadin 6 code. Fix Versions: 5.x Project: Magnolia UI Labels: ckeditor Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORM-218) form processor 'sendConfirmationEMail' will never be executes, enabled=true missing
Christian Ringele created MGNLFORM-218 form processor sendConfirmationEMail will never be executes, enabled=true missing Issue Type: Bug Affects Versions: 2.2, 2.1, 2.0.2, 2.0.1, 2.0, 1.4.9, 1.4.8, 1.4.7, 1.4.6, 1.4.5, 1.4.4 Assignee: Unassigned Attachments: Form-IgnoredDialogCheckbox.png, Form-NoEnabledOnSendConfirmationMail.png Components: processor Created: 17/Dec/13 4:09 PM Description: The class: info.magnolia.module.form.processors.AbstractFormProcessor Defines a property "enable=true" for that any form processor is triggered at all. Besides the 'sendContactEMail' processor non of the others have a "enable=true" configured. So no confirmation mail will ever be sent. This is also miss leading, as the dialog itself already provides a "Send a confirmation mail" checkbox, which is then checked in the processor. But without the "enable=true" on the processor itself, this code is never reached. Fix Versions: 1.4.x, 2.1.x, 2.2.x Project: Magnolia Form Module Priority: Critical Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORM-219) i18n: Collected form configNodes are not i18n aware in MultiStepForm component - requiredconfirmation text is not returned i18nized.
Christian Ringele created MGNLFORM-219 i18n: Collected form configNodes are not i18n aware in MultiStepForm component - requiredconfirmation text is not returned i18nized. Issue Type: Bug Affects Versions: 2.2.1, 2.0.2, 1.4.9 Assignee: Unassigned Attachments: NavigationUtils.patch Components: i18n Created: 20/Dec/13 11:13 AM Description: Behavior: When defining a required and confirmation text in different languages, it works fine on the form component, but not on the formStep component. Reason: The form.ftl gets the required text from the model class. The FormModel "allocates" the StartStepFormEngine with the 'content' node. The 'content' node is i18n wrapped be the renderer. The SubStepFormModel "allocates" the SubStepFormEngine and gets the component nodes by this helper method: info.magnolia.module.form.templates.components.multistep.NavigationUtils.findParagraphOfType(Node, Class?) This method does not wrap the found nodes with the i18nNodeWrapper (see patch). Fix Versions: 1.4.x, 2.2.x Project: Magnolia Form Module Priority: Major Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-2556) Workflow Pulse Message: Not viewable to the end user if already approved or not
Christian Ringele created MGNLUI-2556 Workflow Pulse Message: Not viewable to the end user if already approved or not Issue Type: Bug Affects Versions: 5.2.1 Assignee: Unassigned Components: pulse, user interaction Created: 09/Jan/14 11:30 AM Description: After approving a publishing workflow message in pulse, there is not viewable marker that this workflow has been approved (or rejected) in any kind. The only option is to open the message again and try to approve it. Also other participants of the same workflow (for example when a group is informed) won't be able to see that it was already approved by somebody else. If you think in a real live system with many publishing a day, this is very hard to keep track of what is approved and what not. Especially if a whole team of approvers have to collaborate. Fix Versions: 5.2.x Project: Magnolia UI Priority: Major Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-2654) CheckboxFieldDefinition: 'defaultValue' property does not behave as the former 'selected' property. Also former 'selected' still exists in configurations (but igno
Christian Ringele created MGNLUI-2654 CheckboxFieldDefinition: defaultValue property does not behave as the former selected property. Also former selected still exists in configurations (but ignored) and in documentation. Issue Type: Bug Affects Versions: 5.2.2 Assignee: Unassigned Attachments: CheckboxFieldDefinition_HideInNavigation.png Components: forms Created: 06/Feb/14 3:24 PM Description: From the commit fce63483089061379501143b58528541d0fe1fcc indicates, that the always existing 'defaultValue' property is the successor of 'selected' property. But setting the 'defaultValue' property to true (CheckboxFieldDefinition_HideInNavigation.png) has no impact, the checkbox is not checked, and will therefore save the false value (ignoring the defaultValue). In the past, the 'defaultValue' property was only used for defining in a group of Checkboxes and radio buttons, which one should be selected. I didn't test if this still works. Also looking at configurations in STK, the property still exists even its not used see CheckboxFieldDefinition_HideInNavigation.png. And in documentation the 'selected' property is still mentioned: http://documentation.magnolia-cms.com/display/DOCS/Checkbox Fix Versions: 5.2.x Project: Magnolia UI Labels: Support Priority: Critical Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-2654) CheckboxFieldDefinition: 'defaultValue' property does not behave as the former 'selected' property. Also former 'selected' still exists in configurations (but igno
Christian Ringele updated MGNLUI-2654 CheckboxFieldDefinition: defaultValue property does not behave as the former selected property. Also former selected still exists in configurations (but ignored) and in documentation. Change By: Christian Ringele (06/Feb/14 4:03 PM) Fix Version/s: 5.2.3 Fix Version/s: 5.2.x This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLDATA-249) Renaming existing node to a substring od the former name only affects the name property, but not the node name itself.
Christian Ringele
created MGNLDATA-249
Renaming existing node to a substring od the former name only affects the name property, but not the node name itself.
Issue Type:
Bug
Affects Versions:
1.7.8, 1.6.5
Assignee:
Unassigned
Attachments:
DataModule_ReanmeToSubstring.jpg
Created:
25/Feb/14 1:43 PM
Description:
Reproduce the problem:
Go the the contacts type in data module
Open the dialog of "JMustermann"
Rename the name field to a substing: JMuster
Result:
The property "name" was changes, but the node name itself is unchanged.
(DataModule_ReanmeToSubstring.jpg)
Problem source:
info.magnolia.module.data.dialogs.DataDialog.getNewNodeName()
Detecting the new node name falls to the else statement:
if(this.create || !this.nodeName.startsWith(name)){
name = Path.getUniqueLabel(hm, this.path, name);
}
else{
name = this.nodeName;
}
Project:
Magnolia Data Module
Labels:
support
Priority:
Neutral
Reporter:
Christian Ringele
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-2731) Non extpanded app icson should overlap existing app icons when being expanded.
Christian Ringele created MGNLUI-2731 Non extpanded app icson should overlap existing app icons when being expanded. Issue Type: Improvement Affects Versions: 5.2.2 Assignee: Unassigned Components: design, user interaction Created: 06/Mar/14 10:37 AM Description: When clicking at non expanded app group it can happen that it overlaps existing expanded groups. In this situation it should overlap the existing icons (be in fromt of them). Currently they are rendered behind the existing expanded group, see print screen. This should be changed, as the app icons are not properly readable and therefore not properly usable. Information of Andreas regarding this: It was once implemented this way, at least it was planned. Should be added again. Fix Versions: 5.2.3 Project: Magnolia UI Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-2731) Non extpanded app icson should overlap existing app icons when being expanded.
Christian Ringele updated MGNLUI-2731 Non extpanded app icson should overlap existing app icons when being expanded. Change By: Christian Ringele (06/Mar/14 11:05 AM) Attachment: Not-Overlapping-Group.PNG This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-1586) PageEditor: action availability is incorrect for several (area) selections
Christian Ringele updated MGNLUI-1586 PageEditor: action availability is incorrect for several (area) selections Change By: Christian Ringele (07/Apr/14 5:00 PM) Labels: support This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-2783) User is blocked in his browser session after starting long running Action
Christian Ringele updated MGNLUI-2783 User is blocked in his browser session after starting long running Action Change By: Christian Ringele (24/Apr/14 4:59 PM) Labels: support This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLRSSAGG-170) 'Number of entries' Rss-component filter is ignored
Christian Ringele created MGNLRSSAGG-170 Number of entries Rss-component filter is ignored Issue Type: Bug Affects Versions: 2.2.2 Assignee: Unassigned Attachments: RSS-NumberOdEntries.jpg, RSS-Result.jpg Components: rss_component Created: 05/May/14 11:18 AM Description: The dialogs value of the rss component is ignoring the value 'Number of entries'. All entries are displayed, see print screens. Fix Versions: 2.2.x Project: Magnolia RSS Aggregator Module Priority: Major Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLRSSAGG-171) Multi-client capability: Mage feed configuration resolving path and not name aware
Christian Ringele created MGNLRSSAGG-171 Multi-client capability: Mage feed configuration resolving path and not name aware Issue Type: Improvement Affects Versions: 2.2.3, 2.3, 2.4 Assignee: Aleksandr Pchelintcev Attachments: rssaggregator-pathAware.patch Components: rss_generator, rss_importer Created: 06/May/14 4:29 PM Description: In the ticket MGNLRSSAGG-143 the Multi-client capability was implemented, that each feed can be imported separately. In a project use where multi-clients are served a problem of the current implementation is shown: Feeds are fetched from the workspace by their name (with sql) and not their physical path - when two clients define a feed with the same name, all imports are always done on the first one found, the second is ignored. Use case in the project: mutli clients separate top level folder for separate ACls each client adds feeds to their rss "real" as all work for the same company (different subsidiaries) they common shared names for consuming the same feed sources Done: Changed the fetching and serving of feeds by path and not by its name. Patch is added. Fix Versions: 2.4 Project: Magnolia RSS Aggregator Module Labels: support Priority: Major Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLRSSAGG-171) Multi-client capability: Make feed configuration resolving path and not name aware
Christian Ringele updated MGNLRSSAGG-171 Multi-client capability: Make feed configuration resolving path and not name aware Change By: Christian Ringele (06/May/14 4:40 PM) Summary: Multi-clientcapability: Mage Make feedconfigurationresolvingpathandnotnameaware This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLRSSAGG-171) Multi-client capability: Make feed being resolved by path and not by name
Christian Ringele updated MGNLRSSAGG-171 Multi-client capability: Make feed being resolved by path and not by name Change By: Christian Ringele (06/May/14 4:40 PM) Summary: Multi-clientcapability:Makefeed configurationresolving beingresolvedby pathandnot by name aware This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3089) RichTextEditor: DAM image URLs in the rich text editor containthe context path in the created link (and stored text property)
Christian Ringele created MGNLUI-3089 RichTextEditor: DAM image URLs in the rich text editor containthe context path in the created link (and stored text property) Issue Type: Bug Affects Versions: 5.3.1, 5.2.8 Assignee: Unassigned Attachments: RichTextImage-Author.jpg, RichTextImage-Public.jpg Components: forms Created: 05/Aug/14 3:07 PM Description: When enabling the 'images' property on a RichTextFieldDefinition the resolved link/URL contains the context path. Also a link to a dam image shows the same problem. So when activating the content (or changing the context path afterwards) the image is not found. See the print screens RichTextImage-Author.jpg and RichTextImage-Public.jpg The image didn't show up on the public (attention as long the magnoliaAuthor is running the image is on the public is resolved by the author). I changed both context paths and the behavior was as expected: on both the image and the link was wrong. If I'm not mistaken, in the former FckEditor the URL was also stored in in the text's property, but the uuid itself was then used for the url creation. Fix Versions: 5.2.x, 5.3.x Project: Magnolia UI Labels: support Priority: Major Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORM-234) ValidateExpression should not extend NoHTMLValidator, as it prohobits valid password characters
Christian Ringele created MGNLFORM-234 ValidateExpression should not extend NoHTMLValidator, as it prohobits valid password characters Issue Type: Bug Affects Versions: 2.2.5 Assignee: Unassigned Components: validation Created: 11/Aug/14 9:56 AM Description: The regexp based validator: info.magnolia.module.form.validators.ValidateExpression extends the class: info.magnolia.module.form.validators.NoHTMLValidator Using the NoHTMLValidator as a base class for all other fields makes sense, as it prohibuts html characters in form fields. But the NoHTMLValidator prohibits characters which are perfectly fine as password characters. So the ValidateExpression should extends directly the base class Validator, and if by default it still should constrain by the html characters, it should directly be added to the used _expression_ itself. So its obvious and easy changeable. Project: Magnolia Form Module Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORM-235) Field, allow using more than one validator: The relation between a form field and a validator should be 1:n and not 1:1.
Christian Ringele created MGNLFORM-235 Field, allow using more than one validator: The relation between a form field and a validator should be 1:n and not 1:1. Issue Type: Improvement Affects Versions: 2.2.5 Assignee: Unassigned Components: field Created: 11/Aug/14 12:15 PM Description: In a form field one can choose only one validator to use (one drop down). This means that if you use 2-3 validators in your project very often, one must encapsulate its logic into a single one, even all three are existing with their perfect logic. An example: Regexp validator with general check for all fields. Password validator for the password field. Solution: A multifield value should be used to allow choosing a 1:n relation. Project: Magnolia Form Module Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLPUR-138) TokenPasswordProcessor does not check if the user has an actual token
Christian Ringele
created MGNLPUR-138
TokenPasswordProcessor does not check if the user has an actual token
Issue Type:
Bug
Affects Versions:
2.3.1
Assignee:
Unassigned
Created:
11/Aug/14 2:01 PM
Description:
No check is done to see if the user actually has a token. If the user has no token (e.g. because the password change functionality has already been used; e.g. the user clicks on the change password link twice) you get an ugly null pointer. We added this in our TokenPasswordProcessor. See code below.
The error messages (which are shown to the end-user) are hardcoded. i18n messages should really be used.
I think it would be good to add this to the Magnolia TokenPasswordProcessor class?
// not present in Magnolia's TokenPasswordProcessor
// check if user's token is present at all; if we don't do this and the token is not present
// we get an ugly nullpointer later on
if (null == user.getProperty("token")) {
throw new FormProcessorFailedException("No 'password change token' is present in the current user session. " +
"Maybe you have already changed your password? Should you want to change your password again then please " +
"request a new password reset.");
}
Project:
Magnolia Public User Registration
Labels:
support
Priority:
Neutral
Reporter:
Christian Ringele
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORM-236) Html Escaping of form fields should be configurable
Christian Ringele
updated MGNLFORM-236
Html Escaping of form fields should be configurable
Change By:
Christian Ringele
(11/Aug/14 1:57 PM)
Description:
Theformmodulehtmlescapesbydefaultinputs.Thisisincertainsituationsnotgood.Clearlyinthepasswordfield,asitwontstorethePWwithallowedcharactersdifferentthanthe1:1input.ThisleadstoproblemswhenreusingthePWalsoforothersystems.Alsothecustomerneedstostorefromotherfieldsinputswhichareunchanged(seelinkedsupportticket).Examplesasoriginalvaluetostore{code}ResearchDevelopment{code}becomes{code}Researchamp;Development{code}
.
Theproblemisthislineintheinfo.magnolia.module.form.templates.components.DefaultFormDataBinder#bindAndValidateFieldsmethod:{code}finalStringvalue=EscapeUtil.escapeXss(StringUtils.join(MgnlContext.getParameterValues(controlName),__));{code}Suggestedsolution:AllformfieldsshouldbehtmlescapedtopreventXSSattacks.Butallowaconfigurationontheformfieldtodisableitforthisspecificfield.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORM-236) Html Escaping of form fields should be configurable
Christian Ringele created MGNLFORM-236 Html Escaping of form fields should be configurable Issue Type: Improvement Affects Versions: 2.2.5 Assignee: Unassigned Created: 11/Aug/14 1:56 PM Description: The form module html escapes by default inputs. This is in certain situations not good. Clearly in the password field, as it won't store the PW with allowed characters different than the 1:1 input. This leads to problems when reusing the PW also for other systems. Also the customer needs to store from other fields inputs which are unchanged (see linked support ticket). Examples as original value to store Research Development becomes Research amp; Development . The problem is this line in the info.magnolia.module.form.templates.components.DefaultFormDataBinder#bindAndValidateFields method: final String value = EscapeUtil.escapeXss(StringUtils.join(MgnlContext.getParameterValues(controlName), "__")); Suggested solution: All form fields should be html escaped to prevent XSS attacks. But allow a configuration on the form field to disable it for this specific field. Project: Magnolia Form Module Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS atacks in AdminCentral and rethink XSS impl in Forum module.
Christian Ringele updated MGNLUI-3092 Consider XSS atacks in AdminCentral and rethink XSS impl in Forum module. Change By: Christian Ringele (11/Aug/14 2:09 PM) Summary: ConsiderXSSatacksinAdminCentraland rething rethink XSSimplinForummodule. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS attacks in AdminCentral and re-think XSS impl in Form modulet
Christian Ringele updated MGNLUI-3092 Consider XSS attacks in AdminCentral and re-think XSS impl in Form modulet Change By: Christian Ringele (11/Aug/14 2:10 PM) Summary: ConsiderXSS atacks attacks inAdminCentralandre-thinkXSSimplinFormmodulet This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS attacks in AdminCentral and re-think XSS impl in Form module
Christian Ringele updated MGNLUI-3092 Consider XSS attacks in AdminCentral and re-think XSS impl in Form module Change By: Christian Ringele (11/Aug/14 2:10 PM) Summary: ConsiderXSSattacksinAdminCentralandre-thinkXSSimplinForm modulet module This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS atacks in AdminCentral and re-think XSS impl in Form modulet
Christian Ringele updated MGNLUI-3092 Consider XSS atacks in AdminCentral and re-think XSS impl in Form modulet Change By: Christian Ringele (11/Aug/14 2:09 PM) Summary: ConsiderXSSatacksinAdminCentralandre-thinkXSSimplin Forummodule. Formmodulet This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS atacks in AdminCentral and re-think XSS impl in Forum module.
Christian Ringele updated MGNLUI-3092 Consider XSS atacks in AdminCentral and re-think XSS impl in Forum module. Change By: Christian Ringele (11/Aug/14 2:09 PM) Summary: ConsiderXSSatacksinAdminCentraland rethink re-think XSSimplinForummodule. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS atacks in AdminCentral and rething XSS impl in Forum module.
Christian Ringele created MGNLUI-3092 Consider XSS atacks in AdminCentral and rething XSS impl in Forum module. Issue Type: Improvement Assignee: Unassigned Components: forms Created: 11/Aug/14 2:09 PM Description: A customer who looked deep into the Form module validation and field value submission rose this topic (SUPPORT-3873): 1. As for preventing XSS attacks in the form module all inputs are html escaped, a similar approach should also be considered within the AdminCentral forms. In the AdminCentral all form fields are open to XSS attacks. It would be favorable, it the used solution would be aligned/comparable to the (new) implementation used in the form module. 2. Which leads to the second points: He suggests to rethink the XSS html escaping implementation currently used in the form module. It might not be the best way to prevent such attacks. As this topic is involving two modules, I created it here in the UI section (point 1 seems more important). Project: Magnolia UI Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORUM-270) DefaultForumManager#isModerator() checks only the directly attached roles of the user, but ignores his roles inherited from his groups
Christian Ringele
created MGNLFORUM-270
DefaultForumManager#isModerator() checks only the directly attached roles of the user, but ignores his roles inherited from his groups
Issue Type:
Bug
Affects Versions:
3.4.1, 3.3.3
Assignee:
Unassigned
Attachments:
DefaultForumManager.patch
Components:
moderation
Created:
11/Aug/14 5:20 PM
Description:
When trying to edit a form message, not only the ACL is checked, but also the method isModerator() is called on the DefaultForumManager.
This method only checks if the user has the roles "forum_ALL-admin" and "forum_ALL-moderator" directly assigned to the user. (currentUser.hasRole()).
But it is not checking, if the user has this role "inherited" be a group he is part of.
This means, if you have the role "forum_ALL-admin" only as a role of a group, you won't be able to edit a message, even if you have the content access rights to the data.
This is a big problem for all AD/LDap users. As AD/LDap users are matched by their user name or user group, one can not directly assign a role to a ad user, only groups. So even if the logged in AD user has the role by one if its group, he can not edit a message.
Former code:
@Override
public void isModerator() throws AccessDeniedException{
User currentUser = MgnlContext.getUser();
if (!currentUser.hasRole(ROLE_FORUM_ALL_MODERATOR) !currentUser.hasRole(ROLE_FORUM_ALL_ADMIN)) {
throw new AccessDeniedException("User not allowed to perform that action.");
}
}
Should be changed to:
@Override
public void isModerator() throws AccessDeniedException{
User currentUser = MgnlContext.getUser();
boolean hasRole = false;
// Needs to use getAllRoles() instead of .hasRole() because .hasRole() will only check for the roles directly attached to the user, but not the ones inherited from the group.
// As roles can not directly be attached to a AD user, it is crucial to be able to define it over its group.
CollectionString allRoles = currentUser.getAllRoles();
for (IteratorString iterator = allRoles.iterator(); iterator.hasNext();) {
String roleName = iterator.next();
if (roleName.equals(ROLE_FORUM_ALL_MODERATOR) || roleName.equals(ROLE_FORUM_ALL_ADMIN)) {
hasRole = true;
}
}
if (!hasRole) {
throw new AccessDeniedException("User not allowed to perform that action.");
}
}
The "currentUser.getAllRoles();" returns all roles also the ones form the user's groups.
I added the patch of the class.
But tests are failing because the mock user returns a empty list on .getAllRoles();
Test should be fixed accordingly.
Project:
Magnolia Forum Module
Labels:
support
Priority:
Critical
Reporter:
Christian Ringele
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3098) Bulk oprtation MoveNodeAction: Move After is reverting the chosen Node order
Christian Ringele created MGNLUI-3098 Bulk oprtation MoveNodeAction: Move After is reverting the chosen Node order Issue Type: Bug Affects Versions: 5.3.2, 5.2.8 Assignee: Unassigned Attachments: MoveNodeAction-M5.2.5.patch, MoveNodeAction-M5.3.1.patch Components: content app Created: 13/Aug/14 1:39 PM Description: Summary: When moving a selection of Nodes with the "Move After" operation, their order is reversed. The reason is that for each Node the moveAfter() is called, which reverses implicit its order: The last Node is placed as last element directly after the target node - its then the first Node and not the last anymore. Cause: Super class of MoveNodeAction abstract class is info.magnolia.ui.framework.action.AbstractMultiItemAction It calls in the execute() for every item operating on the abstract method .executeOnItem(JcrItemAdapter). The MoveNodeAction implementing the method executeOnItem is calling info.magnolia.ui.workbench.tree.MoveHandler.moveItem(Item, Item, MoveLocation) which in the end calles info.magnolia.jcr.util.NodeUtil.moveNodeAfter(Node, Node) . Solution general: Override the method info.magnolia.ui.contentapp.movedialog.action.MoveNodeAction.getSortedItems(ComparatorJcrItemAdapter) of the super class and revert the list on the MoveLoction.after operation. Solution patches: As the code changed form 5.2 to 5.3 of this class, I needed to create two different patches basically containing the same code. Just the line numbers won't match. Project: Magnolia UI Labels: support Priority: Major Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3098) Bulk oprtation MoveNodeAction: Move After is reverting the chosen Node order
Christian Ringele
updated MGNLUI-3098
Bulk oprtation MoveNodeAction: Move After is reverting the chosen Node order
Change By:
Christian Ringele
(13/Aug/14 1:57 PM)
Description:
Summary:WhenmovingaselectionofNodeswiththeMoveAfteroperation,theirorderisreversed.ThereasonisthatforeachNodethemoveAfter()iscalled,whichreversesimplicititsorder:ThelastNodeisplacedaslastelementdirectlyafterthetargetnode-itsthenthefirstNodeandnotthelastanymore.Cause:SuperclassofMoveNodeActionabstractclassis{code}info.magnolia.ui.framework.action.AbstractMultiItemAction{code}Itcallsintheexecute()foreveryitemoperatingontheabstractmethod.executeOnItem(JcrItemAdapter).TheMoveNodeActionimplementingthemethodexecuteOnItemiscalling{code}info.magnolia.ui.workbench.tree.MoveHandler.moveItem(Item,Item,MoveLocation){code}whichintheendcalles{code}info.magnolia.jcr.util.NodeUtil.moveNodeAfter(Node,Node){code}
.
Solutiongeneral:Overridethemethod{code}info.magnolia.ui.contentapp.movedialog.action.MoveNodeAction.getSortedItems(ComparatorJcrItemAdapter){code}ofthesuperclassandrevertthelistontheMoveLoction.afteroperation.Solutionpatches:Asthecodechangedform5.2to5.3ofthisclass,Ineededtocreatetwodifferentpatchesbasicallycontainingthesamecode.Justthelinenumberswontmatch.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3098) Bulk operation MoveNodeAction: Move After is reverting the chosen Node order
Christian Ringele
updated MGNLUI-3098
Bulk operation MoveNodeAction: Move After is reverting the chosen Node order
Change By:
Christian Ringele
(13/Aug/14 2:04 PM)
Description:
Summary:WhenmovingaselectionofNodeswiththeMoveAfteroperation,theirorderisreversed.ThereasonisthatforeachNodethemoveAfter()iscalled,whichreversesimplicititsorder:ThelastNodeisplacedaslastelementdirectlyafterthetargetnode-itsthenthefirstNodeandnotthelastanymore.Cause:SuperclassofMoveNodeActionabstractclassis{code}info.magnolia.ui.framework.action.AbstractMultiItemAction{code}Itcallsintheexecute()foreveryitemoperatingontheabstractmethod.executeOnItem(JcrItemAdapter).TheMoveNodeActionimplementingthemethodexecuteOnItemiscalling{code}info.magnolia.ui.workbench.tree.MoveHandler.moveItem(Item,Item,MoveLocation){code}whichintheend
called
calles
{code}info.magnolia.jcr.util.NodeUtil.moveNodeAfter(Node,Node){code}Solutiongeneral:Overridethemethod{code}info.magnolia.ui.contentapp.movedialog.action.MoveNodeAction.getSortedItems(ComparatorJcrItemAdapter){code}ofthesuperclassandrevertthelistontheMoveLoction.afteroperation.Solutionpatches:Asthecodechangedform5.2to5.3ofthisclass,Ineededtocreatetwodifferentpatchesbasicallycontainingthesamecode.Justthelinenumberswontmatch.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3098) Bulk operation MoveNodeAction: Move After is reverting the chosen Node order
Christian Ringele updated MGNLUI-3098 Bulk operation MoveNodeAction: Move After is reverting the chosen Node order Change By: Christian Ringele (13/Aug/14 2:00 PM) Summary: Bulk oprtation operation MoveNodeAction:MoveAfterisrevertingthechosenNodeorder This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3098) Bulk operation MoveNodeAction: Move After is reverting the chosen Node order
Christian Ringele
updated MGNLUI-3098
Bulk operation MoveNodeAction: Move After is reverting the chosen Node order
Change By:
Christian Ringele
(13/Aug/14 2:04 PM)
Description:
Summary:WhenmovingaselectionofNodeswiththeMoveAfteroperation,theirorderisreversed.ThereasonisthatforeachNodethemoveAfter()iscalled,whichreversesimplicititsorder:ThelastNodeisplacedaslastelementdirectlyafterthetargetnode-itsthenthefirstNodeandnotthelastanymore.Cause:SuperclassofMoveNodeActionabstractclassis{code}info.magnolia.ui.framework.action.AbstractMultiItemAction{code}Itcallsintheexecute()foreveryitemoperatingontheabstractmethod.executeOnItem(JcrItemAdapter).TheMoveNodeActionimplementingthemethodexecuteOnItemiscalling{code}info.magnolia.ui.workbench.tree.MoveHandler.moveItem(Item,Item,MoveLocation){code}whichintheend
calles
calls
{code}info.magnolia.jcr.util.NodeUtil.moveNodeAfter(Node,Node){code}Solutiongeneral:Overridethemethod{code}info.magnolia.ui.contentapp.movedialog.action.MoveNodeAction.getSortedItems(ComparatorJcrItemAdapter){code}ofthesuperclassandrevertthelistontheMoveLoction.afteroperation.Solutionpatches:Asthecodechangedform5.2to5.3ofthisclass,Ineededtocreatetwodifferentpatchesbasicallycontainingthesamecode.Justthelinenumberswontmatch.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3098) Bulk operation MoveNodeAction: Move After is reverting the chosen Node order
Christian Ringele
updated MGNLUI-3098
Bulk operation MoveNodeAction: Move After is reverting the chosen Node order
Change By:
Christian Ringele
(13/Aug/14 2:02 PM)
Description:
Summary:WhenmovingaselectionofNodeswiththeMoveAfteroperation,theirorderisreversed.ThereasonisthatforeachNodethemoveAfter()iscalled,whichreversesimplicititsorder:ThelastNodeisplacedaslastelementdirectlyafterthetargetnode-itsthenthefirstNodeandnotthelastanymore.Cause:SuperclassofMoveNodeActionabstractclassis{code}info.magnolia.ui.framework.action.AbstractMultiItemAction{code}Itcallsintheexecute()foreveryitemoperatingontheabstractmethod.executeOnItem(JcrItemAdapter).TheMoveNodeActionimplementingthemethodexecuteOnItemiscalling{code}info.magnolia.ui.workbench.tree.MoveHandler.moveItem(Item,Item,MoveLocation){code}whichintheend
calles
called
{code}info.magnolia.jcr.util.NodeUtil.moveNodeAfter(Node,Node){code}Solutiongeneral:Overridethemethod{code}info.magnolia.ui.contentapp.movedialog.action.MoveNodeAction.getSortedItems(ComparatorJcrItemAdapter){code}ofthesuperclassandrevertthelistontheMoveLoction.afteroperation.Solutionpatches:Asthecodechangedform5.2to5.3ofthisclass,Ineededtocreatetwodifferentpatchesbasicallycontainingthesamecode.Justthelinenumberswontmatch.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLWORKFLOW-268) CompleteTaskAction links in its deprecation information to the wrong successor class.
Christian Ringele
created MGNLWORKFLOW-268
CompleteTaskAction links in its deprecation information to the wrong successor class.
Issue Type:
Bug
Affects Versions:
5.4.1
Assignee:
Unassigned
Components:
Base
Created:
13/Aug/14 2:33 PM
Description:
The class info.magnolia.module.workflow.action.CompleteTaskAction states:
* @deprecated since 5.4. Use {@link info.magnolia.ui.admincentral.shellapp.pulse.task.action.CompleteTaskAction}
But the correct successor class is:
info.magnolia.ui.admincentral.shellapp.pulse.task.action.ResolveTaskAction
Should be changed, was misleading to a support customer.
Project:
Magnolia Workflow Module
Labels:
support
Priority:
Minor
Reporter:
Christian Ringele
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLWORKFLOW-268) CompleteTaskAction links in its deprecation information to the wrong successor class.
Christian Ringele
updated MGNLWORKFLOW-268
CompleteTaskAction links in its deprecation information to the wrong successor class.
Change By:
Christian Ringele
(13/Aug/14 2:36 PM)
Description:
Theclassinfo.magnolia.module.workflow.action.CompleteTaskActionstates:{code}*@deprecatedsince5.4.Use{@linkinfo.magnolia.ui.admincentral.shellapp.pulse.task.action.CompleteTaskAction}{code}Butthecorrectsuccessorclassis:
{code}
info.magnolia.ui.admincentral.shellapp.pulse.task.action.ResolveTaskAction
{code}
Shouldbechanged,wasmisleadingtoasupportcustomer.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3100) AdminCentral SearchJcrContainer: Using characters ( { [ ''' crashes the AdminCentral
Christian Ringele
created MGNLUI-3100
AdminCentral SearchJcrContainer: Using characters ( { [ crashes the AdminCentral
Issue Type:
Bug
Affects Versions:
5.3.2, 5.2.8
Assignee:
Unassigned
Components:
workbench
Created:
13/Aug/14 4:58 PM
Description:
This happens only on the fist search dropped after opening an app using the SearchJcrContainer (content apps in the workbench).
Reproduce crash:
Open for example the contacts app
enter one if these search terms:
(
{
[
'''
anythingAnd(inbetween
No crash when:
Open app
enter valid search term
removing the term using the at the right of the search field
drop one of the characters that don't work in first search
Errors:
The initial Error:
Aug 13, 2014 4:35:10 PM com.vaadin.server.DefaultErrorHandler doDefault
SEVERE:
java.lang.RuntimeException: Unable to get item id for index: 0 from container using Container.Indexed#getIdByIndex() even though container.size() endIndex. Returned item id was null. Check your container implementation!
at com.vaadin.data.ContainerHelpers.getItemIdsUsingGetIdByIndex(ContainerHelpers.java:90)
at info.magnolia.ui.workbench.container.AbstractJcrContainer.getItemIds(AbstractJcrContainer.java:676)
at com.vaadin.ui.Table.getItemIds(Table.java:2219)
at com.vaadin.ui.Table.getVisibleCellsNoCache(Table.java:2169)
at com.vaadin.ui.Table.refreshRenderedCells(Table.java:1694)
at com.vaadin.ui.Table.getVisibleCells(Table.java:3960)
Happens when the calls "ContainerHelpers.getItemIdsUsingGetIdByIndex(startIndex, numberOfItems, this);" which calls on the used container the method getIdByIndex(int):
info.magnolia.ui.workbench.container.AbstractJcrContainer.getIdByIndex(int)
The system complaints about illegal characters used for the full text search:
2014-08-13 16:08:05,914 WARN gnolia.ui.workbench.container.AbstractJcrContainer: Could not update size with statement: select * from [nt:base] as t where (([jcr:primaryType] = 'mgnl:contact' or [jcr:primaryType] = 'mgnl:folder') and (lower(localname()) LIKE '(%' or t.['('] IS NOT NULL or contains(t.*, '(')) ): javax.jcr.RepositoryException: Invalid full text search _expression_: (
2014-08-13 16:08:19,833 WARN gnolia.ui.workbench.container.AbstractJcrContainer: Cannot get Page with statement: select * from [nt:base] as t where (([jcr:primaryType] = 'mgnl:contact' or [jcr:primaryType] = 'mgnl:folder') and (lower(localname()) LIKE '(%' or t.['('] IS NOT NULL or contains(t.*, '(')) ) order by score(t) desc: javax.jcr.RepositoryException: Invalid full text search _expression_: (
Looked into:
First I suspected this method:
info.magnolia.ui.workbench.search.SearchJcrContainer.escapeIllegalFullTextSearchChars(String)
as it uses the variable
private static final String illegalFullTextChars = "-+)\"\\";
to determine the invalid characters.
Then I checked the method:
info.magnolia.ui.workbench.search.SearchJcrContainer.getQueryWhereClauseSearch()
Where the
final String escapedSearch = Text.escapeIllegalJcrChars(unescapedFullTextExpression);
is already using the Text.escapeIllegalJcrChars to remove illegal characters.
But all this can't be the full source of the problem, because this does not explain why it only doesn't work as a first dropped search. If the excaping alone would be the problem, then it would never work.
What surprises is:
If changing in the method "info.magnolia.ui.workbench.search.SearchJcrContainer.getQueryWhereClauseSearch()"
just for testing the
final String unescapedFullTextExpression = getFullTextExpression();
by
final String unescapedFullTextExpression = "\\(";
it works perfectly.
Project:
Magnolia UI
Labels:
support
Priority:
Neutral
[magnolia-dev] [JIRA] (MGNLUI-3120) Windows all browsers: On various actions the whole tree shifts quickly down and up again
Christian Ringele created MGNLUI-3120 Windows all browsers: On various actions the whole tree shifts quickly down and up again Issue Type: Bug Assignee: Unassigned Created: 25/Aug/14 4:36 PM Description: Customer raised the issue in the suppor ticket SUPPORT-3906 and added also a video of it. I tested it in parallels and can confirm the same behavior. Description: On various actions the whole tree shifts quickly down and up again. It is good viewable on the right side of the scroll bar. The actions where it was seen: adding a node adding a property renaming a node inline renaming a property inline It seems that it happens every time, when the tree needs to be updated for displaying the added change. Project: Magnolia UI Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3120) Windows all browsers: On various actions the whole tree shifts quickly down and up again
Christian Ringele updated MGNLUI-3120 Windows all browsers: On various actions the whole tree shifts quickly down and up again Change By: Christian Ringele (25/Aug/14 4:36 PM) Affects Version/s: 5.3.2 Affects Version/s: 5.2.8 Component/s: admincentral This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3121) ConversionException after unselecting and selecting agin a channel from exclusion
Christian Ringele created MGNLUI-3121 ConversionException after unselecting and selecting agin a channel from exclusion Issue Type: Bug Affects Versions: 5.3.2, 5.2.8 Assignee: Unassigned Components: forms Created: 26/Aug/14 11:29 AM Description: There was a similar issue MGNLUI-2048. Now the difference is in point 6. : it only shows up when it was selected before, and on the second opening the checkbox is deselected and selected again while the dialog stays open. With following steps you can reproduce the issue: 1. open a page in page editor 2. open page properties dialog 3. select an output channel checkbox 4. save the dialog 5. open page properties dialog again 6. unselect and select the output channel the error message will appear (see screenshot from demoauthor) Project: Magnolia UI Labels: support Priority: Neutral Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3123) Date property change in JCR browser doesn't work
Christian Ringele updated MGNLUI-3123 Date property change in JCR browser doesnt work Change By: Christian Ringele (26/Aug/14 4:12 PM) Labels: support This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3124) AbstractJcrNodeAdapter: allow calling updateChildren(Node) from outside the class.
Christian Ringele created MGNLUI-3124 AbstractJcrNodeAdapter: allow calling updateChildren(Node) from outside the class. Issue Type: Improvement Affects Versions: 5.3.2, 5.2.8 Assignee: Unassigned Attachments: AbstractJcrNodeAdapter.patch Components: forms Created: 27/Aug/14 12:20 PM Description: Use Case: Adding a image to the user dialog in security app. Problem: info.magnolia.security.app.dialog.action.SaveUserDialogAction Is not calling in the JcrNodeAdapter#applyChanges() as it needs to store the properties different (groups and roles). This is because applyChanges() calls besides the updateChildren(Node) also the updateProperties(node) method. Problem: As applyChanges() is not called, the updateChildren(Node) is also never called - no dialog field value will be stored which creates a subnode instead of a property (example: DamUploadFieldDefinition). Solution: Make the method updateChildren(Node) public as also the updateProperties(node) is public. See linked issue from security app: Project: Magnolia UI Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3124) AbstractJcrNodeAdapter: allow calling updateChildren(Node) from outside the class. Allow in security app storing a image on the user.
Christian Ringele updated MGNLUI-3124 AbstractJcrNodeAdapter: allow calling updateChildren(Node) from outside the class. Allow in security app storing a image on the user. Change By: Christian Ringele (27/Aug/14 12:23 PM) Description: UseCase:Addingaimagetotheuserdialoginsecurityapp.Problem:info.magnolia.security.app.dialog.action.SaveUserDialogActionIsnotcallingintheJcrNodeAdapter#applyChanges()asitneedstostorethepropertiesdifferent(groupsandroles).ThisisbecauseapplyChanges()callsbesidestheupdateChildren(Node)alsotheupdateProperties(node)method.Problem:AsapplyChanges()isnotcalled,theupdateChildren(Node)isalsonevercalled-nodialogfieldvaluewillbestoredwhichcreatesasubnodeinsteadofaproperty(example:DamUploadFieldDefinition).Solution:MakethemethodupdateChildren(Node)publicasalsotheupdateProperties(node)ispublic.Thetheinfo.magnolia.security.app.dialog.action.SaveUserDialogAction.createOrUpdateUser(JcrNodeAdapter)cancalltheupdateChildren(Node)explicitontheusernode (seepatchofSaveUserDialogAction) . This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3124) AbstractJcrNodeAdapter: allow calling updateChildren(Node) from outside the class. Allow in security app storing a image on the user.
Christian Ringele updated MGNLUI-3124 AbstractJcrNodeAdapter: allow calling updateChildren(Node) from outside the class. Allow in security app storing a image on the user. Change By: Christian Ringele (27/Aug/14 12:22 PM) Summary: AbstractJcrNodeAdapter:allowcallingupdateChildren(Node)fromoutsidetheclass. Allowinsecurityappstoringaimageontheuser. Attachment: SaveUserDialog.patch Description: UseCase:Addingaimagetotheuserdialoginsecurityapp.Problem:info.magnolia.security.app.dialog.action.SaveUserDialogActionIsnotcallingintheJcrNodeAdapter#applyChanges()asitneedstostorethepropertiesdifferent(groupsandroles).ThisisbecauseapplyChanges()callsbesidestheupdateChildren(Node)alsotheupdateProperties(node)method.Problem:AsapplyChanges()isnotcalled,theupdateChildren(Node)isalsonevercalled-nodialogfieldvaluewillbestoredwhichcreatesasubnodeinsteadofaproperty(example:DamUploadFieldDefinition).Solution:MakethemethodupdateChildren(Node)publicasalsotheupdateProperties(node)ispublic. Seelinkedissuefrom Thetheinfo.magnolia. security . app : .dialog.action.SaveUserDialogAction.createOrUpdateUser(JcrNodeAdapter)cancalltheupdateChildren(Node)explicitontheusernode. Component/s: securityapp This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3128) DefaultI18NAuthoringSupport: fallbackLocale provided in scope of pages app's editor is always from default site definiton
Christian Ringele created MGNLUI-3128 DefaultI18NAuthoringSupport: fallbackLocale provided in scope of pages apps editor is always from default site definiton Issue Type: Bug Affects Versions: 5.3.2 Assignee: Unassigned Attachments: fallbackLocal.jpg Components: dialogs, page editor Created: 28/Aug/14 11:00 PM Description: This issue is very related to MULTISITE-22, it's is follow up. The described behavior was also detected on the defaultLocale (MULTISITE-22). Description: When changing in a specific site definition the defaultLocale the fallbackLocale, the already stored content should appear in a dialog. This is not the case because the fallbackLocale is still served from the "default" site definition, see print screen fallbackLocal.jpg. (MULTISITE-22) corrected that the defaultLocale is set correctly and the dialog opens in the default locale (in this case "de") from the specific site definition, but because the fallbackLocale(en) != defaultLocale(de) the dialog still want to edit a property with "_en" appended to its name. There fore the dialog is empty, and if entering content it will store a "%propertyName_fallsbackLocale%" property. Reason: In info.magnolia.ui.framework.i18n.DefaultI18NAuthoringSupport.i18nize(HasComponents, Locale) the locale provided as the parameter is the correct defaultLocal. But in this code: boolean isFallbackLanguage = i18nContentSupport.getFallbackLocale().equals(locale); The provided fallbackLocal from i18nContentSupport (Object=MultiSiteI18nAuthoringSupport) is from the "default" site definition (set in MultiSiteFilter). This because the detected site definition in the scope of the pages app is not the actual specific site definition from the edited page (different requests). (same problem as in MULTISITE-22) Tried solution: I tried to create also a node dependent getFallbackLocale(Node node) method for MultiSiteI18nAuthoringSupport DefaultI18nAuthoringSupport as done in the MULTISITE-22 for the defaultLocale. The problem is that in the calling class of the method DefaultI18NAuthoringSupport#i18nize is the dialogs view: info.magnolia.ui.dialog.formdialog.ItemFormView.createLocaleSelector() I haven't found a way to retrieve the content the DialogView operates on. Which could be well intended by the MVP pattern. A different solution might has to be found. Project: Magnolia UI Labels: support Priority: Major Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3128) DefaultI18NAuthoringSupport: fallbackLocale is always from default site definiton in pages app.
Christian Ringele updated MGNLUI-3128 DefaultI18NAuthoringSupport: fallbackLocale is always from default site definiton in pages app. Change By: Christian Ringele (28/Aug/14 11:10 PM) Summary: DefaultI18NAuthoringSupport:fallbackLocale providedinscopeofpagesappseditor isalwaysfromdefaultsitedefiniton inpagesapp. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3128) DefaultI18NAuthoringSupport: fallbackLocale is in pages app always from default site definiton.
Christian Ringele updated MGNLUI-3128 DefaultI18NAuthoringSupport: fallbackLocale is in pages app always from default site definiton. Change By: Christian Ringele (28/Aug/14 11:11 PM) Summary: DefaultI18NAuthoringSupport:fallbackLocaleis inpagesapp alwaysfromdefaultsitedefiniton inpagesapp . This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (BLOSSOM-190) Provide also to blossom the MutliSite features placed in STK (i18n, prototype merging, etc)
Christian Ringele created BLOSSOM-190 Provide also to blossom the MutliSite features placed in STK (i18n, prototype merging, etc) Issue Type: Improvement Affects Versions: 3.0.3 Assignee: Tobias Mattsson Created: 01/Sep/14 1:36 PM Description: Multi site feature is a base functionality provided by the EE (Pro) usage. The mutli site configurations used in the MultiSiteModule (modules config node/sites) reflected by "info.magnolia.multisite.MultiSiteModule.sites" use the STK based SiteDefintion bean Site "info.magnolia.module.templatingkit.sites.Site". But various features of this configuration are based on pure STK implementations: i18n (the AbstractRenderer wrapps the nodes, not done by the blossom renderer) templates/prototype merging (done by the STK renderer) TemplatesAvailability class used for SiteDefition/templates node is pure STK (and not the one form the rendering module). This limits the use of the blossom module in collaboration of the multi site module. This functionality provided by the multi-site module should also be useable for the blossom module. The way to solve this problem by using STK-Pages and adding blossom components is not applicable for all customers, but they still need to use the mutli site capability and its features. Project: Magnolia Blossom Module Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3131) AdminCentral tree view: The focus gets lost after editing a property or doing a mouse right click
Christian Ringele created MGNLUI-3131 AdminCentral tree view: The focus gets lost after editing a property or doing a mouse right click Issue Type: Bug Affects Versions: 5.2.8, 5.2.7 Assignee: Unassigned Created: 03/Sep/14 1:25 PM Description: When editing a property or doing a right mouse click in the tree view the focus gets lost and the tree scrolls to the top. This behavior was fixed for M5.3.2 (or earlier 5.3.x), please check if the fix can be back ported also to M5.2.x. This behavior was detected on: (Videos available in the linked support ticket) Ubuntu 13.04: Firefox 26.0 Chrome 31.0.1650.63 - Ubuntu 13.04 Windows XP SP3: Firefox 26.0 Windows 7:* IE 9 (see screenshot) Project: Magnolia UI Labels: support Priority: Major Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3131) AdminCentral tree view: The focus gets lost after editing a property or doing a right mouse click
Christian Ringele updated MGNLUI-3131 AdminCentral tree view: The focus gets lost after editing a property or doing a right mouse click Change By: Christian Ringele (03/Sep/14 1:28 PM) Summary: AdminCentraltreeview:Thefocusgetslostaftereditingapropertyordoinga mouse right mouse click This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORUM-276) Forum app: ‘Creation date’ column should display creationDate and not mgnl:created. Also message node should be updated.
Christian Ringele created MGNLFORUM-276 Forum app: ‘Creation date’ column should display creationDate and not mgnl:created. Also message node should be updated. Issue Type: Improvement Affects Versions: 3.4.2 Assignee: Unassigned Attachments: config.modules.forum.apps.forum.subApps.browser.workbench.contentViews.list.columns.creation.xml Components: Admin-UI Created: 03/Sep/14 3:25 PM Description: When you edit the creation date of a message this is not reflected in the forum app. In the JCR the custom ‘creationDate’ node property is updated just fine however the message node itself is not renamed. Also the ‘Creation date’ column in the browser sub app shows the mgnl:created field and not the custom ‘creationDate’ property. However on the frontend (website) only the creationData is used.. I think the forum app should show the creationData property instead of mgnl:created (since that is really irrelevant) and should also rename the node when the creationDate is changed. This is very easy to do with the attached changed creation column for the browser app. Project: Magnolia Forum Module Labels: support Priority: Neutral Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORUM-276) Forum app: ‘Creation date’ column should display creationDate and not mgnl:created. Also message node should be updated.
Christian Ringele updated MGNLFORUM-276 Forum app: ‘Creation date’ column should display creationDate and not mgnl:created. Also message node should be updated. Change By: Christian Ringele (03/Sep/14 3:27 PM) Description: Customerfeedback: Whenyoueditthecreationdateofamessagethisisnotreflectedintheforumapp.IntheJCRthecustom‘creationDate’nodepropertyisupdatedjustfinehoweverthemessagenodeitselfisnotrenamed.Alsothe‘Creationdate’columninthebrowsersubappshowsthemgnl:createdfieldandnotthecustom‘creationDate’property.Howeveronthefrontend(website)onlythecreationDataisused..IthinktheforumappshouldshowthecreationDatapropertyinsteadofmgnl:created(sincethatisreallyirrelevant)andshouldalsorenamethenodewhenthecreationDateischanged.Thisisveryeasytodowiththeattachedchangedcreationcolumnforthebrowserapp. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORUM-277) Forum app: Provide possibility to add new forum thread messages.
Christian Ringele created MGNLFORUM-277 Forum app: Provide possibility to add new forum thread messages. Issue Type: Improvement Assignee: Unassigned Attachments: config.modules.forum.apps.forum.subApps.browser.actionbar.sections.message.groups.editActions.items.addMessage.xml, config.modules.forum.apps.forum.subApps.browser.actionbar.sections.thread.groups.editActions.items.addMessage.xml, config.modules.forum.apps.forum.subApps.browser.actions.addMessage.xml Created: 03/Sep/14 3:28 PM Description: Customer feedback: There is no way to add new forum thread messages in the forum app but our client really wants this. So I implemented this by adding an ‘Add message’ action in the appropriate places. See attached files (ps: I reuse the existing editMessage dialog). Maybe you want to add this to the forum app by default? The only thing I have not managed to do is to set the name of the created message node to the creationDate automatically (as is done when you create a message on the frontend). Instead the name is now set to ‘0’ (/’00’ etc). I am not sure how to do this. Project: Magnolia Forum Module Labels: support Priority: Neutral Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORUM-273) The messageEdit dialog in the forum app misses a ‘required=true’ property
Christian Ringele created MGNLFORUM-273 The messageEdit dialog in the forum app misses a ‘required=true’ property Issue Type: Improvement Affects Versions: 3.4.2 Assignee: Unassigned Components: dialogs Created: 03/Sep/14 3:18 PM Description: Customer feedback: The messageEdit dialog in the forum app misses a ‘required=true’ property for the fields author, content and creationDate. If you leave the author and creationDate empty you cannot save the dialog (you get an error) so they really should be added. Content as well in my opinion because what is a thread message without a message? In our version handler we have added them like this: // add missing required properties to edit message dialog in forum app tasks.add(new SetPropertyTask(RepositoryConstants.CONFIG, "/modules/forum/dialogs/messageEdit/form/tabs/tabMain/fields/author", "required", "true")); tasks.add(new SetPropertyTask(RepositoryConstants.CONFIG, "/modules/forum/dialogs/messageEdit/form/tabs/tabMain/fields/content", "required", "true")); tasks.add(new SetPropertyTask(RepositoryConstants.CONFIG, "/modules/forum/dialogs/messageEdit/form/tabs/tabMetadata/fields/creationDate", "required", "true")); Project: Magnolia Forum Module Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORUM-274) Old property: In the messageEdit dialog the author and inReplyTo fields have a ‘tree’ property.
Christian Ringele created MGNLFORUM-274 Old property: In the messageEdit dialog the author and inReplyTo fields have a ‘tree’ property. Issue Type: Improvement Affects Versions: 3.4.2 Assignee: Unassigned Components: dialogs Created: 03/Sep/14 3:20 PM Description: In the messageEdit dialog the author and inReplyTo fields have a ‘tree’ property. This seems an old property type from Magnolia 4? In any case it does not seem to work anymore. The fields are now just text fields. I guess the idea was that you could link to an existing user / forum message respectively. That would be very nice indeed. Can this be re-implemented? I guess you would do this with a Link property in Magnolia 5? I have not looked into this myself. Surely would be nice if this could be fixed/enhanced. Project: Magnolia Forum Module Labels: support Priority: Neutral Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORUM-275) Update using the new i18n mechanism.
Christian Ringele created MGNLFORUM-275 Update using the new i18n mechanism. Issue Type: Improvement Affects Versions: 3.4.2 Assignee: Unassigned Components: i18n Created: 03/Sep/14 3:22 PM Description: Customer feedback: The forum module seems to still use the ‘old’ way of defining i18n properties using ‘i18nBasename’ instead of the new way? This makes overriding i18n properties cumbersome because we now have to override i18nBasename in the right places and then copy a lot of properties from the forum module which we do not really want to do, just to override a single property ourselves. Project: Magnolia Forum Module Labels: support Priority: Neutral Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORUM-274) Old property: In the messageEdit dialog the author and inReplyTo fields have a ‘tree’ property.
Christian Ringele updated MGNLFORUM-274 Old property: In the messageEdit dialog the author and inReplyTo fields have a ‘tree’ property. Change By: Christian Ringele (03/Sep/14 3:21 PM) Description: Customerfeedback: InthemessageEditdialogtheauthorandinReplyTofieldshavea‘tree’property.ThisseemsanoldpropertytypefromMagnolia4?Inanycaseitdoesnotseemtoworkanymore.Thefieldsarenowjusttextfields.Iguesstheideawasthatyoucouldlinktoanexistinguser/forummessagerespectively.Thatwouldbeveryniceindeed.Canthisbere-implemented?IguessyouwoulddothiswithaLinkpropertyinMagnolia5?Ihavenotlookedintothismyself.Surelywouldbeniceifthiscouldbefixed/enhanced. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORUM-277) Forum app: Provide possibility to add new forum thread messages.
Christian Ringele updated MGNLFORUM-277 Forum app: Provide possibility to add new forum thread messages. Change By: Christian Ringele (03/Sep/14 3:29 PM) Affects Version/s: 3.4.2 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLFORUM-277) Forum app: Provide possibility to add new forum thread messages.
Christian Ringele updated MGNLFORUM-277 Forum app: Provide possibility to add new forum thread messages. Change By: Christian Ringele (03/Sep/14 3:30 PM) Component/s: Admin-UI This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3159) Suggestion: task in ui-admincentral for registering apps into the UI/Shell
Christian Ringele updated MGNLUI-3159 Suggestion: task in ui-admincentral for registering apps into the UI/Shell Change By: Christian Ringele (18/Sep/14 11:20 AM) Summary: Suggestion:taskinui-admincentralfor adding registering apps intotheUI/Shell This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3159) Suggestion: task in ui-admincentral for registering apps into the UI's app launcher
Christian Ringele updated MGNLUI-3159 Suggestion: task in ui-admincentral for registering apps into the UIs app launcher Change By: Christian Ringele (18/Sep/14 11:21 AM) Summary: Suggestion:taskinui-admincentralforregisteringappsintotheUI /Shell sapplauncher This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3215) Page component chooser field (available pages components): Allo the customer to define a comparator-class to have an impact on the displayed order.
Christian Ringele created MGNLUI-3215 Page component chooser field (available pages components): Allo the customer to define a comparator-class to have an impact on the displayed order. Issue Type: Improvement Affects Versions: 5.3.4, 5.2.10 Assignee: Unassigned Components: page editor, pages app Created: 27/Oct/14 2:26 PM Description: Problem: The page template one can choose in the pages app, and the components one can choose in the pages editor are sorted alphabetically. This is in many situations quite annoying: When the most often used pages and component have a "low" letter (t-z), they appear at the very bottom, or in case of page templates you need to click on "next" to get to the second tab pane - you loos possibility to do all via keys, mouse click is a must. For example the "Section" page is always in the second pane. Source of problem: /modules/pages/fieldTypes/templateSelect defined info.magnolia.pages.app.field.TemplateSelectorFieldFactory Which delegates to a internal used comparator class. Solution: Allow to define/configure your own/custom comparator class on a select field. (Probably on any field that operates on more than just one value this would make sense) I think this is a often use case for select fields. Having an impact on the order of the values without the need to "duplicate" the originals Factory class just for injecting a different comparator. Project: Magnolia UI Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3219) Move in Configuration app: Option for live systems that triggers confirmation pop up for any move operation
Christian Ringele created MGNLUI-3219 Move in Configuration app: Option for live systems that triggers confirmation pop up for any move operation Issue Type: Improvement Affects Versions: 5.3.4, 5.2.10 Assignee: Unassigned Components: configuration Created: 27/Oct/14 5:06 PM Description: Problem: As unfortunately not all states are displayed always property on the client side (which node is actively clicked in the tree view) and also the move operation via the mouse is not very precise this can lead to the following error: A users tries to move a node in config app/workspace, but moves more nodes than expected, or into a wrong place. As the config workspace is crucial for the system, one can easily break the while instance like this. Accessing and operating on live in the content app is done for example when creating virtualURIMappings or any live ad-hoc needed changes. Solution: A property that can be set (for example in magnolia.properties) which declares that the system is a live system. This has the result in the config app that: Any move operation needs a confirmation (as deletion). All nodes that will be moved The source path The destination path Project: Magnolia UI Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3225) Security App: 'superuer' role can not be edited
Christian Ringele
updated MGNLUI-3225
Security App: superuer role can not be edited
Change By:
Christian Ringele
(28/Oct/14 5:00 PM)
Description:
*
Info:
*
Thedescribedproblemhappensonlywheneditingthesuperuserrole,andonlyinMangolia5.3.4,
*
Problem:
*
Whentryingtoeditthesuperuserrolefollowingerroristhrown:{noformat}2014-10-2813:44:35,787ERRORfo.magnolia.ui.contentapp.browser.BrowserPresenter:Anerroroccurredwhileexecutingaction[editRole]info.magnolia.ui.api.action.ActionExecutionException:Actionexecutionfailedforaction:editRole atinfo.magnolia.ui.api.action.AbstractActionExecutor.execute(AbstractActionExecutor.java:64) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.executeAction(BrowserPresenter.java:333) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.executeDefaultAction(BrowserPresenter.java:310) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.access$300(BrowserPresenter.java:91) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter$3.onItemDoubleClicked(BrowserPresenter.java:200) atinfo.magnolia.ui.workbench.event.ItemDoubleClickedEvent.dispatch(ItemDoubleClickedEvent.java:65) atinfo.magnolia.ui.workbench.event.ItemDoubleClickedEvent.dispatch(ItemDoubleClickedEvent.java:43) atinfo.magnolia.event.SimpleEventBus.fireEvent(SimpleEventBus.java:78) atinfo.magnolia.ui.workbench.AbstractContentPresenterBase.onDoubleClick(AbstractContentPresenterBase.java:156) atinfo.magnolia.ui.workbench.list.ListViewImpl$3.itemClick(ListViewImpl.java:146) atsun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) atjava.lang.reflect.Method.invoke(Method.java:606) atcom.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:508) atcom.vaadin.event.EventRouter.fireEvent(EventRouter.java:167) atcom.vaadin.server.AbstractClientConnector.fireEvent(AbstractClientConnector.java:969) atcom.vaadin.ui.Table.handleClickEvent(Table.java:3057) atcom.vaadin.ui.Table.changeVariables(Table.java:2853) atcom.vaadin.ui.TreeTable.changeVariables(TreeTable.java:415) atinfo.magnolia.ui.vaadin.grid.MagnoliaTreeTable.changeVariables(MagnoliaTreeTable.java:87) atcom.vaadin.server.communication.ServerRpcHandler.changeVariables(ServerRpcHandler.java:403) atcom.vaadin.server.communication.ServerRpcHandler.handleBurst(ServerRpcHandler.java:228) atcom.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:111) atcom.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:91) atcom.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:37) atcom.vaadin.server.VaadinService.handleRequest(VaadinService.java:1371) atcom.vaadin.server.VaadinServlet.service(VaadinServlet.java:238) atinfo.magnolia.ui.admincentral.AdmincentralVaadinServlet.service(AdmincentralVaadinServlet.java:132) atjavax.servlet.http.HttpServlet.service(HttpServlet.java:728) atinfo.magnolia.cms.filters.ServletDispatchingFilter.doFilter(ServletDispatchingFilter.java:148) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:65) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.cms.filters.VirtualUriFilter.doFilter(VirtualUriFilter.java:68) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.module.cache.executor.Bypass.processCacheRequest(Bypass.java:58)
[magnolia-dev] [JIRA] (MGNLUI-3225) Security App: 'superuer' role can not be edited
Christian Ringele updated MGNLUI-3225 Security App: superuer role can not be edited Change By: Christian Ringele (28/Oct/14 4:57 PM) Attachment: magnolia-security-app-5.3.4-MGNLUI-3225.jar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3225) Security App: 'superuer' role can not be edited
Christian Ringele created MGNLUI-3225 Security App: superuer role can not be edited Issue Type: Bug Affects Versions: 5.3.4 Assignee: Unassigned Attachments: magnolia-security-app-5.3.4-MGNLUI-3225.jar, Superuser-Role_export.jpg, Superuser-Role_import.jpg, WorkspaceAccessFieldFactory.class.zip Components: security app Created: 28/Oct/14 4:57 PM Description: Info: The described problem happens only when editing the 'superuser' role, and only in Mangolia 5.3.4, Problem: When trying to edit the 'superuser' role following error is thrown: 2014-10-28 13:44:35,787 ERROR fo.magnolia.ui.contentapp.browser.BrowserPresenter: An error occurred while executing action [editRole] info.magnolia.ui.api.action.ActionExecutionException: Action execution failed for action: editRole at info.magnolia.ui.api.action.AbstractActionExecutor.execute(AbstractActionExecutor.java:64) at info.magnolia.ui.contentapp.browser.BrowserPresenter.executeAction(BrowserPresenter.java:333) at info.magnolia.ui.contentapp.browser.BrowserPresenter.executeDefaultAction(BrowserPresenter.java:310) at info.magnolia.ui.contentapp.browser.BrowserPresenter.access$300(BrowserPresenter.java:91) at info.magnolia.ui.contentapp.browser.BrowserPresenter$3.onItemDoubleClicked(BrowserPresenter.java:200) at info.magnolia.ui.workbench.event.ItemDoubleClickedEvent.dispatch(ItemDoubleClickedEvent.java:65) at info.magnolia.ui.workbench.event.ItemDoubleClickedEvent.dispatch(ItemDoubleClickedEvent.java:43) at info.magnolia.event.SimpleEventBus.fireEvent(SimpleEventBus.java:78) at info.magnolia.ui.workbench.AbstractContentPresenterBase.onDoubleClick(AbstractContentPresenterBase.java:156) at info.magnolia.ui.workbench.list.ListViewImpl$3.itemClick(ListViewImpl.java:146) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:508) at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:167) at com.vaadin.server.AbstractClientConnector.fireEvent(AbstractClientConnector.java:969) at com.vaadin.ui.Table.handleClickEvent(Table.java:3057) at com.vaadin.ui.Table.changeVariables(Table.java:2853) at com.vaadin.ui.TreeTable.changeVariables(TreeTable.java:415) at info.magnolia.ui.vaadin.grid.MagnoliaTreeTable.changeVariables(MagnoliaTreeTable.java:87) at com.vaadin.server.communication.ServerRpcHandler.changeVariables(ServerRpcHandler.java:403) at com.vaadin.server.communication.ServerRpcHandler.handleBurst(ServerRpcHandler.java:228) at com.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:111) at com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:91) at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:37) at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1371) at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:238) at info.magnolia.ui.admincentral.AdmincentralVaadinServlet.service(AdmincentralVaadinServlet.java:132) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at info.magnolia.cms.filters.ServletDispatchingFilter.doFilter(ServletDispatchingFilter.java:148) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at
[magnolia-dev] [JIRA] (MGNLUI-3225) Security App: 'superuer' role can not be edited
Christian Ringele
updated MGNLUI-3225
Security App: superuer role can not be edited
Change By:
Christian Ringele
(28/Oct/14 4:59 PM)
Description:
Info:Thedescribedproblemhappensonlywheneditingthesuperuserrole,andonlyinMangolia5.3.4,Problem:Whentryingtoeditthesuperuserrolefollowingerroristhrown:{noformat}2014-10-2813:44:35,787ERRORfo.magnolia.ui.contentapp.browser.BrowserPresenter:Anerroroccurredwhileexecutingaction[editRole]info.magnolia.ui.api.action.ActionExecutionException:Actionexecutionfailedforaction:editRole atinfo.magnolia.ui.api.action.AbstractActionExecutor.execute(AbstractActionExecutor.java:64) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.executeAction(BrowserPresenter.java:333) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.executeDefaultAction(BrowserPresenter.java:310) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.access$300(BrowserPresenter.java:91) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter$3.onItemDoubleClicked(BrowserPresenter.java:200) atinfo.magnolia.ui.workbench.event.ItemDoubleClickedEvent.dispatch(ItemDoubleClickedEvent.java:65) atinfo.magnolia.ui.workbench.event.ItemDoubleClickedEvent.dispatch(ItemDoubleClickedEvent.java:43) atinfo.magnolia.event.SimpleEventBus.fireEvent(SimpleEventBus.java:78) atinfo.magnolia.ui.workbench.AbstractContentPresenterBase.onDoubleClick(AbstractContentPresenterBase.java:156) atinfo.magnolia.ui.workbench.list.ListViewImpl$3.itemClick(ListViewImpl.java:146) atsun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) atjava.lang.reflect.Method.invoke(Method.java:606) atcom.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:508) atcom.vaadin.event.EventRouter.fireEvent(EventRouter.java:167) atcom.vaadin.server.AbstractClientConnector.fireEvent(AbstractClientConnector.java:969) atcom.vaadin.ui.Table.handleClickEvent(Table.java:3057) atcom.vaadin.ui.Table.changeVariables(Table.java:2853) atcom.vaadin.ui.TreeTable.changeVariables(TreeTable.java:415) atinfo.magnolia.ui.vaadin.grid.MagnoliaTreeTable.changeVariables(MagnoliaTreeTable.java:87) atcom.vaadin.server.communication.ServerRpcHandler.changeVariables(ServerRpcHandler.java:403) atcom.vaadin.server.communication.ServerRpcHandler.handleBurst(ServerRpcHandler.java:228) atcom.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:111) atcom.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:91) atcom.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:37) atcom.vaadin.server.VaadinService.handleRequest(VaadinService.java:1371) atcom.vaadin.server.VaadinServlet.service(VaadinServlet.java:238) atinfo.magnolia.ui.admincentral.AdmincentralVaadinServlet.service(AdmincentralVaadinServlet.java:132) atjavax.servlet.http.HttpServlet.service(HttpServlet.java:728) atinfo.magnolia.cms.filters.ServletDispatchingFilter.doFilter(ServletDispatchingFilter.java:148) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:65) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.cms.filters.VirtualUriFilter.doFilter(VirtualUriFilter.java:68) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.module.cache.executor.Bypass.processCacheRequest(Bypass.java:58)
[magnolia-dev] [JIRA] (MGNLUI-3225) Security App: 'superuser' role can not be edited
Christian Ringele
updated MGNLUI-3225
Security App: superuser role can not be edited
Change By:
Christian Ringele
(28/Oct/14 5:42 PM)
Description:
*Info:*Thedescribedproblemhappensonlywheneditingthesuperuserrole,andonlyinMangolia5.3.4,*Problem:*Whentryingtoeditthesuperuserrolefollowingerroristhrown:{noformat}2014-10-2813:44:35,787ERRORfo.magnolia.ui.contentapp.browser.BrowserPresenter:Anerroroccurredwhileexecutingaction[editRole]info.magnolia.ui.api.action.ActionExecutionException:Actionexecutionfailedforaction:editRole atinfo.magnolia.ui.api.action.AbstractActionExecutor.execute(AbstractActionExecutor.java:64) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.executeAction(BrowserPresenter.java:333) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.executeDefaultAction(BrowserPresenter.java:310) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.access$300(BrowserPresenter.java:91) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter$3.onItemDoubleClicked(BrowserPresenter.java:200) atinfo.magnolia.ui.workbench.event.ItemDoubleClickedEvent.dispatch(ItemDoubleClickedEvent.java:65) atinfo.magnolia.ui.workbench.event.ItemDoubleClickedEvent.dispatch(ItemDoubleClickedEvent.java:43) atinfo.magnolia.event.SimpleEventBus.fireEvent(SimpleEventBus.java:78) atinfo.magnolia.ui.workbench.AbstractContentPresenterBase.onDoubleClick(AbstractContentPresenterBase.java:156) atinfo.magnolia.ui.workbench.list.ListViewImpl$3.itemClick(ListViewImpl.java:146) atsun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) atjava.lang.reflect.Method.invoke(Method.java:606) atcom.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:508) atcom.vaadin.event.EventRouter.fireEvent(EventRouter.java:167) atcom.vaadin.server.AbstractClientConnector.fireEvent(AbstractClientConnector.java:969) atcom.vaadin.ui.Table.handleClickEvent(Table.java:3057) atcom.vaadin.ui.Table.changeVariables(Table.java:2853) atcom.vaadin.ui.TreeTable.changeVariables(TreeTable.java:415) atinfo.magnolia.ui.vaadin.grid.MagnoliaTreeTable.changeVariables(MagnoliaTreeTable.java:87) atcom.vaadin.server.communication.ServerRpcHandler.changeVariables(ServerRpcHandler.java:403) atcom.vaadin.server.communication.ServerRpcHandler.handleBurst(ServerRpcHandler.java:228) atcom.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:111) atcom.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:91) atcom.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:37) atcom.vaadin.server.VaadinService.handleRequest(VaadinService.java:1371) atcom.vaadin.server.VaadinServlet.service(VaadinServlet.java:238) atinfo.magnolia.ui.admincentral.AdmincentralVaadinServlet.service(AdmincentralVaadinServlet.java:132) atjavax.servlet.http.HttpServlet.service(HttpServlet.java:728) atinfo.magnolia.cms.filters.ServletDispatchingFilter.doFilter(ServletDispatchingFilter.java:148) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:65) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.cms.filters.VirtualUriFilter.doFilter(VirtualUriFilter.java:68) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.module.cache.executor.Bypass.processCacheRequest(Bypass.java:58)
[magnolia-dev] [JIRA] (MGNLUI-3225) Security App: 'superuser' role can not be edited
Christian Ringele
updated MGNLUI-3225
Security App: superuser role can not be edited
Change By:
Christian Ringele
(28/Oct/14 5:40 PM)
Description:
*Info:*Thedescribedproblemhappensonlywheneditingthesuperuserrole,andonlyinMangolia5.3.4,*Problem:*Whentryingtoeditthesuperuserrolefollowingerroristhrown:{noformat}2014-10-2813:44:35,787ERRORfo.magnolia.ui.contentapp.browser.BrowserPresenter:Anerroroccurredwhileexecutingaction[editRole]info.magnolia.ui.api.action.ActionExecutionException:Actionexecutionfailedforaction:editRole atinfo.magnolia.ui.api.action.AbstractActionExecutor.execute(AbstractActionExecutor.java:64) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.executeAction(BrowserPresenter.java:333) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.executeDefaultAction(BrowserPresenter.java:310) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter.access$300(BrowserPresenter.java:91) atinfo.magnolia.ui.contentapp.browser.BrowserPresenter$3.onItemDoubleClicked(BrowserPresenter.java:200) atinfo.magnolia.ui.workbench.event.ItemDoubleClickedEvent.dispatch(ItemDoubleClickedEvent.java:65) atinfo.magnolia.ui.workbench.event.ItemDoubleClickedEvent.dispatch(ItemDoubleClickedEvent.java:43) atinfo.magnolia.event.SimpleEventBus.fireEvent(SimpleEventBus.java:78) atinfo.magnolia.ui.workbench.AbstractContentPresenterBase.onDoubleClick(AbstractContentPresenterBase.java:156) atinfo.magnolia.ui.workbench.list.ListViewImpl$3.itemClick(ListViewImpl.java:146) atsun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) atjava.lang.reflect.Method.invoke(Method.java:606) atcom.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:508) atcom.vaadin.event.EventRouter.fireEvent(EventRouter.java:167) atcom.vaadin.server.AbstractClientConnector.fireEvent(AbstractClientConnector.java:969) atcom.vaadin.ui.Table.handleClickEvent(Table.java:3057) atcom.vaadin.ui.Table.changeVariables(Table.java:2853) atcom.vaadin.ui.TreeTable.changeVariables(TreeTable.java:415) atinfo.magnolia.ui.vaadin.grid.MagnoliaTreeTable.changeVariables(MagnoliaTreeTable.java:87) atcom.vaadin.server.communication.ServerRpcHandler.changeVariables(ServerRpcHandler.java:403) atcom.vaadin.server.communication.ServerRpcHandler.handleBurst(ServerRpcHandler.java:228) atcom.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:111) atcom.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:91) atcom.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:37) atcom.vaadin.server.VaadinService.handleRequest(VaadinService.java:1371) atcom.vaadin.server.VaadinServlet.service(VaadinServlet.java:238) atinfo.magnolia.ui.admincentral.AdmincentralVaadinServlet.service(AdmincentralVaadinServlet.java:132) atjavax.servlet.http.HttpServlet.service(HttpServlet.java:728) atinfo.magnolia.cms.filters.ServletDispatchingFilter.doFilter(ServletDispatchingFilter.java:148) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) atinfo.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:65) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.cms.filters.VirtualUriFilter.doFilter(VirtualUriFilter.java:68) atinfo.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:89) atinfo.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:80) atinfo.magnolia.module.cache.executor.Bypass.processCacheRequest(Bypass.java:58)
[magnolia-dev] [JIRA] (MGNLUI-3227) Field Validation: Don't ignore 'required' property on the CompositeField itself.
Christian Ringele
created MGNLUI-3227
Field Validation: Dont ignore required property on the CompositeField itself.
Issue Type:
Improvement
Affects Versions:
5.3.4, 5.2.10
Assignee:
Unassigned
Attachments:
CompositeField-Required.jpg, CompositeField.patch
Components:
forms
Created:
29/Oct/14 12:31 PM
Description:
Setting on the CompositeFieldDefinition the required property it is ignored.
So if one needs to ensure that all fields in the composite need to be filled out, one must set to all sub fields a required property.
Much easier would be if the required could be set on the composite itself.
Use case definition:
If the Composite field sets required=true, every sub field in the composite needs a value.
Problem:
CompositeFieldDefinition does not implement isValid(), and the super's isValid is only checking the validation of the sub fields.
This code solves the problem, I included a patch.
@Override
public boolean isValid() {
boolean isValid = super.isValid();
if (this.isRequired()) {
// If required is set on the composite itself then it checks if one of the sub-fields is empty - all must have a value
ListAbstractFieldPropertysetItem fields = getFields(this, false);
for (AbstractFieldPropertysetItem field : fields) {
if (isEmpty()) {
isValid = false;
}
}
}
return isValid;
}
Project:
Magnolia UI
Labels:
support
Priority:
Neutral
Reporter:
Christian Ringele
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3240) UI From: Add cross field validation feature
Christian Ringele updated MGNLUI-3240 UI From: Add cross field validation feature Change By: Christian Ringele (04/Nov/14 1:50 PM) Description: Crossfieldvalidationwouldbeahelpfulfeatureinmanyusecases.Herethreeexamples:1.Ifyouenteravalueforanassetfield,youalsomustprovideavaluefortheassetdescriptionfieldthatispresentinthedialog.2.IntheCompositefieldPointofinterest,youmustalwaysfillinalongitudeandalatitude,orleavebothempty.3.Twofields,ageparentsnames:Ifage18onemustenteraparentsname.Thiswouldbeaveryhelpfulfeaturetomaketheusageofformsmoreflexible.IhavecreatedanissuewhereItriedacrossfieldvalidationonaCompositeField(constrainedscope)asaPOC,thePOCwouldbeusable: MGNLUI-3241 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3241) Composite Field: Add cross field validation between the subfields of the composite field
Christian Ringele created MGNLUI-3241 Composite Field: Add cross field validation between the subfields of the composite field Issue Type: New Feature Assignee: Unassigned Attachments: AllEmptyOrNoneEmpty.java, config.modules.training-templating.dialogs.myTextImage.form.tabs.tabMain.fields.pointOfInterest.xml, config.modules.ui-framework.fieldTypes.crossValidatingCompositeField.xml, CrossFieldsComparator.java, CrossFieldsValidatingCompositeField.java, CrossFieldsValidatingCompositeFieldDefinition.java, CrossFieldsValidatingCompositeFieldFactory.java Created: 04/Nov/14 1:50 PM Description: Cross field validation is not a feature of the current Magnolia Form UI implementation. I have created a general issue for requesting this feature as a general feature throughout form fields: MGNLUI-3240 In this ticket the the idea is to implement it for the CompositeField, as it would be a alternative to handle many of the use cases that occur of fields that need to be cross validated. Possible use cases: A "point of interest" CompositeField with the sub-fields "Longitude' and 'Latitude'. The field is not required, BUT if in one sub field a value is entered, the other also needs a value (no value or all have a value situation). Idea: Extending the CompositeField by a cross field validation of its sub fields. Overriding the validate() method and delegating to a configurable field comparator class. POC implementation: I tried quickly such an implementation to test if it is possible. I created: CrossFieldsValidatingCompositeField.java which extends the CompositeField and its definition factory class. The field delegates to an implementation of the CrossFieldsComparator.java interface to do the field comparison. CrossFieldsComparator.java does the field comparison. AllEmptyOrNoneEmpty.java is the implementation for this use case, checking if one field ha a value. Attention: This is just a POC, not product ready code! It can be used in projects, but will probably need some adaptions. Usage: Add a 'fieldTypes' mapping of the FieldDefinition and the FieldFactory class. (added bootstrap file) Use the CrossFieldsValidatingCompositeField class for a composite field. Define the crossFieldsComparator property pointing to the implementation CrossFieldsComparator for the specific use case, in this case here the AllEmptyOrNoneEmpty. Other use cases: Just implement another version of CrossFieldsComparator. Project: Magnolia UI Labels: support Priority: Neutral Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3240) UI From: Add cross field validation feature
Christian Ringele created MGNLUI-3240 UI From: Add cross field validation feature Issue Type: New Feature Affects Versions: 5.3.5 Assignee: Unassigned Components: forms Created: 04/Nov/14 1:47 PM Description: Cross field validation would be a helpful feature in many use cases. Here three examples: 1. If you enter a value for an asset field, you also must provide a value for the asset description field that is present in the dialog. 2. In the Composite field "Point of interest", you must always fill in a longitude and a latitude, or leave both empty. 3. Two fields, age parents names: If age 18 one must enter a parents name. This would be a very helpful feature to make the usage of forms more flexible. I have created an issue where I tried a cross field validation on a CompositeField (constrained scope) as a POC, the POC would be usable: Project: Magnolia UI Labels: support Priority: Neutral Reporter: Christian Ringele Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3241) Composite Field: Add cross field validation between the subfields of the composite field
Christian Ringele updated MGNLUI-3241 Composite Field: Add cross field validation between the subfields of the composite field Change By: Christian Ringele (04/Nov/14 1:52 PM) Attachment: CrossFieldsValidatingCompositeField-Configuration.jpg This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3227) Field Validation: Don't ignore 'required' property on the CompositeField itself.
Christian Ringele updated MGNLUI-3227 Field Validation: Dont ignore required property on the CompositeField itself. Change By: Christian Ringele (04/Nov/14 2:17 PM) Attachment: CompositeField.patch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3227) Field Validation: Don't ignore 'required' property on the CompositeField itself.
Christian Ringele updated MGNLUI-3227 Field Validation: Dont ignore required property on the CompositeField itself. Change By: Christian Ringele (04/Nov/14 2:16 PM) Attachment: CompositeField-Required.patch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3227) Field Validation: Don't ignore 'required' property on the CompositeField itself.
Christian Ringele updated MGNLUI-3227 Field Validation: Dont ignore required property on the CompositeField itself. Change By: Christian Ringele (04/Nov/14 2:16 PM) Attachment: CompositeField-Required.patch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3227) Field Validation: Don't ignore 'required' property on the CompositeField itself.
Christian Ringele
updated MGNLUI-3227
Field Validation: Dont ignore required property on the CompositeField itself.
Change By:
Christian Ringele
(04/Nov/14 2:15 PM)
Description:
SettingontheCompositeFieldDefinitiontherequiredpropertyitisignored.Soifoneneedstoensurethatallfieldsinthecompositeneedtobefilledout,onemustsettoallsubfieldsarequiredproperty.Mucheasierwouldbeiftherequiredcouldbesetonthecompositeitself.Usecasedefinition:IftheCompositefieldsetsrequired=true,everysubfieldinthecompositeneedsavalue.Problem:CompositeFieldDefinitiondoesnotimplementisValid(),andthesupersisValidisonlycheckingthevalidationofthesubfields.Thiscodesolvestheproblem,Iincludedapatch.{code}@OverridepublicbooleanisValid(){booleanisValid=super.isValid();if(this.isRequired()){
//Ifrequiredissetonthecompositeitselfthenitchecks
if
oneofthesub-fieldsisempty-allmusthaveavalueListAbstractFieldPropertysetItemfields=getFields
(
this,false);for(AbstractFieldPropertysetItemfield:fields){if(
isEmpty()){isValid=false;}}
}
returnisValid;}{code}
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3227) Field Validation: Don't ignore 'required' property on the CompositeField itself.
Christian Ringele updated MGNLUI-3227 Field Validation: Dont ignore required property on the CompositeField itself. Change By: Christian Ringele (04/Nov/14 2:17 PM) Attachment: CompositeField.patch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3241) Composite Field: Add cross field validation between the subfields of the composite field
Christian Ringele updated MGNLUI-3241 Composite Field: Add cross field validation between the subfields of the composite field Change By: Christian Ringele (04/Nov/14 2:31 PM) Description: CrossfieldvalidationisnotafeatureofthecurrentMagnoliaFormUIimplementation.Ihavecreatedageneralissueforrequestingthisfeatureasageneralfeaturethroughoutformfields:MGNLUI-3240InthisticketthetheideaistoimplementitfortheCompositeField,asitwouldbeaalternativetohandlemanyoftheusecasesthatoccuroffieldsthatneedtobecrossvalidated.Possibleusecases:-ApointofinterestCompositeFieldwiththesub-fieldsLongitudeandLatitude.Thefieldisnotrequired,BUTifinonesubfieldavalueisentered,theotheralsoneedsavalue(novalueorallhaveavaluesituation).Idea:ExtendingtheCompositeFieldbyacrossfieldvalidationofitssubfields.Overridingthevalidate()methodanddelegatingtoaconfigurablefieldcomparatorclass.POCimplementation:Itriedquicklysuchanimplementationtotestifitispossible.Icreated:-CrossFieldsValidatingCompositeField.javawhichextendstheCompositeFieldanditsdefinitionfactoryclass.ThefielddelegatestoanimplementationoftheCrossFieldsComparator.javainterfacetodothefieldcomparison.-CrossFieldsComparator.javadoesthefieldcomparison.-AllEmptyOrNoneEmpty.javaistheimplementationforthisusecase,checkingifonefieldhaavalue.Attention:ThisisjustaPOC,notproductreadycode!Itcanbeusedinprojects,butwillprobablyneedsomeadaptions.Usage:-AddafieldTypesmappingoftheFieldDefinitionandtheFieldFactoryclass.(addedbootstrapfile)-UsetheCrossFieldsValidatingCompositeFieldclassforacompositefield.-DefinethecrossFieldsComparatorpropertypointingtotheimplementationCrossFieldsComparatorforthespecificusecase,inthiscaseheretheAllEmptyOrNoneEmpty.Otherusecases:JustimplementanotherversionofCrossFieldsComparator. Constrains Constraints :IfirsttriedtouseaVaadinValidatoronthecompositefield.ThisdoesntworkbecausetheValidatorisdecoupledformtheinvokedfiled.SoTheValidatorisnotawareofanyconfiguredsubfieldsofaMagnoliaCompositeField.ProvidingthisvaluestotheValidatortodoacomparisonwouldbeveryhackish(interlinkingMagnoliaConfigurationsandVaadinValidators). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3241) Composite Field: Add cross field validation between the subfields of the composite field
Christian Ringele updated MGNLUI-3241 Composite Field: Add cross field validation between the subfields of the composite field Change By: Christian Ringele (04/Nov/14 2:31 PM) Description: CrossfieldvalidationisnotafeatureofthecurrentMagnoliaFormUIimplementation.Ihavecreatedageneralissueforrequestingthisfeatureasageneralfeaturethroughoutformfields:MGNLUI-3240InthisticketthetheideaistoimplementitfortheCompositeField,asitwouldbeaalternativetohandlemanyoftheusecasesthatoccuroffieldsthatneedtobecrossvalidated.Possibleusecases:-ApointofinterestCompositeFieldwiththesub-fieldsLongitudeandLatitude.Thefieldisnotrequired,BUTifinonesubfieldavalueisentered,theotheralsoneedsavalue(novalueorallhaveavaluesituation).Idea:ExtendingtheCompositeFieldbyacrossfieldvalidationofitssubfields.Overridingthevalidate()methodanddelegatingtoaconfigurablefieldcomparatorclass.POCimplementation:Itriedquicklysuchanimplementationtotestifitispossible.Icreated:-CrossFieldsValidatingCompositeField.javawhichextendstheCompositeFieldanditsdefinitionfactoryclass.ThefielddelegatestoanimplementationoftheCrossFieldsComparator.javainterfacetodothefieldcomparison.-CrossFieldsComparator.javadoesthefieldcomparison.-AllEmptyOrNoneEmpty.javaistheimplementationforthisusecase,checkingifonefieldhaavalue.Attention:ThisisjustaPOC,notproductreadycode!Itcanbeusedinprojects,butwillprobablyneedsomeadaptions.Usage:-AddafieldTypesmappingoftheFieldDefinitionandtheFieldFactoryclass.(addedbootstrapfile)-UsetheCrossFieldsValidatingCompositeFieldclassforacompositefield.-DefinethecrossFieldsComparatorpropertypointingtotheimplementationCrossFieldsComparatorforthespecificusecase,inthiscaseheretheAllEmptyOrNoneEmpty.Otherusecases:JustimplementanotherversionofCrossFieldsComparator. Constrains:IfirsttriedtouseaVaadinValidatoronthecompositefield.ThisdoesntworkbecausetheValidatorisdecoupledformtheinvokedfiled.SoTheValidatorisnotawareofanyconfiguredsubfieldsofaMagnoliaCompositeField.ProvidingthisvaluestotheValidatortodoacomparisonwouldbeveryhackish(interlinkingMagnoliaConfigurationsandVaadinValidators). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3240) UI From: Add cross field validation feature
Christian Ringele updated MGNLUI-3240 UI From: Add cross field validation feature Change By: Christian Ringele (04/Nov/14 2:51 PM) Labels: support Fix Version/s: Backlog This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3241) Composite Field: Add cross field validation between the subfields of the composite field
Christian Ringele updated MGNLUI-3241 Composite Field: Add cross field validation between the subfields of the composite field Change By: Christian Ringele (04/Nov/14 2:51 PM) Labels: support Fix Version/s: Backlog Affects Version/s: 5.3.5 Affects Version/s: 5.2.10 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3283) Search View value: Don't reset search value after load of the tree view's content
Christian Ringele created MGNLUI-3283 Search View value: Dont reset search value after load of the tree views content Issue Type: Improvement Affects Versions: 5.3.5, 5.2.10 Assignee: Unassigned Components: content app Created: 04/Dec/14 10:53 AM Description: Example form the Contacts app: "When having a lot of contacts in the contacts app, the tree view might load a while. Imagine a scenario, where the editor enters a search term into the search field before the tree load completes. Unfortunately, the search field is reset after load is completed and the search term must be entered again." It would be great, if the search term would not be resetted after the tree view loading is finished. Project: Magnolia UI Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3283) Search View value: Don't reset search value after initial load of the tree view's content
Christian Ringele updated MGNLUI-3283 Search View value: Dont reset search value after initial load of the tree views content Change By: Christian Ringele (04/Dec/14 10:54 AM) Summary: SearchViewvalue:Dontresetsearchvalueafter initial loadofthetreeviewscontent This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3290) Field properties: Combination of i18n=true readOnly=true results in Exception Dialog or subApp does not open.
Christian Ringele created MGNLUI-3290 Field properties: Combination of i18n=true readOnly=true results in Exception Dialog or subApp does not open. Issue Type: Bug Affects Versions: 5.3.5 Assignee: Unassigned Attachments: Form-readOnly-ContactsApp.png, Form-readOnly-TextImageDialog.png Components: forms Created: 10/Dec/14 9:51 AM Description: The combination of these two properties on a form field does not work: i18n = true readOnly = true The the detail subapp of the contacts app does not open and trows: 2014-12-10 09:49:48,033 ERROR agnolia.ui.framework.app.AppInstanceControllerImpl: Sub-app detail failed to start: Invocation of method valueChange in info.magnolia.ui.dialog.formdialog.ItemFormView$2 failed. com.vaadin.event.ListenerMethod$MethodException: Invocation of method valueChange in info.magnolia.ui.dialog.formdialog.ItemFormView$2 failed. at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:528) at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:167) at com.vaadin.server.AbstractClientConnector.fireEvent(AbstractClientConnector.java:969) at com.vaadin.ui.AbstractField.fireValueChange(AbstractField.java:1126) at com.vaadin.ui.AbstractField.setValue(AbstractField.java:542) at com.vaadin.ui.AbstractSelect.setValue(AbstractSelect.java:702) at com.vaadin.ui.AbstractSelect.setValue(AbstractSelect.java:671) at info.magnolia.ui.dialog.formdialog.ItemFormView.setCurrentLocale(ItemFormView.java:143) at info.magnolia.ui.dialog.formdialog.FormBuilder.buildForm(FormBuilder.java:132) at info.magnolia.ui.contentapp.detail.DetailPresenter.setItemView(DetailPresenter.java:159) at info.magnolia.ui.contentapp.detail.DetailPresenter.start(DetailPresenter.java:138) at info.magnolia.ui.contentapp.detail.DetailEditorPresenter.start(DetailEditorPresenter.java:122) at info.magnolia.ui.contentapp.detail.DetailEditorPresenter.start(DetailEditorPresenter.java:101) at info.magnolia.ui.contentapp.detail.DetailSubApp.start(DetailSubApp.java:118) at info.magnolia.ui.contentapp.detail.DetailSubApp.start(DetailSubApp.java:1) In the textImage component the dialog does not open and trwos: 2014-12-10 09:51:04,699 ERROR info.magnolia.pages.app.editor.PageEditorPresenter: An error occurred while executing action [editComponent] info.magnolia.ui.api.action.ActionExecutionException: Action execution failed for action: editComponent at info.magnolia.ui.api.action.AbstractActionExecutor.execute(AbstractActionExecutor.java:64) at info.magnolia.pages.app.editor.PageEditorPresenter.onAction(PageEditorPresenter.java:127) at info.magnolia.ui.vaadin.editor.PageEditor$1.editComponent(PageEditor.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.vaadin.server.ServerRpcManager.applyInvocation(ServerRpcManager.java:168) at com.vaadin.server.ServerRpcManager.applyInvocation(ServerRpcManager.java:118) at com.vaadin.server.communication.ServerRpcHandler.handleBurst(ServerRpcHandler.java:214) at com.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:111) at com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:91) at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:37) at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1371) at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:238) Project: Magnolia UI Priority: Neutral
[magnolia-dev] [JIRA] (DOCU-547) URL selectors should be documented
Christian Ringele created DOCU-547 URL selectors should be documented Issue Type: Task Assignee: Antti Hietala Components: content Created: 13/Jan/15 2:31 PM Description: URL selectors should be documented. It was mentioned in SUPPORT-4305 see Milan's comment of 12/Jan/15 12:34 PM I hope its correct that I create an issue here regarding this. Project: Documentation Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (PAGES-16) Pages Brwoser SubApp: Pages can't be moved
Title: Message Title Christian Ringele created an issue Magnolia pages module / PAGES-16 Pages Brwoser SubApp: Pages can't be moved Issue Type: Bug Affects Versions: 5.4.x Assignee: Espen Jervidalo Created: 31/Mar/15 1:14 PM Priority: Major Reporter: Christian Ringele Version 5.4-m4 Pages can not be moved in the page's browser sub app. Not with drag drop nor with the move action. Add Comment This
[magnolia-dev] [JIRA] (PAGES-16) Pages Browser SubApp: Pages can't be moved
Title: Message Title Christian Ringele updated an issue Magnolia pages module / PAGES-16 Pages Browser SubApp: Pages can't be moved Change By: Christian Ringele Summary: Pages Brwoser Browser SubApp:Pagescan'tbemoved Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLDEMO-23) Dialogs: Don't use extends for no reson (or some might possible future easons)
Title: Message Title Christian Ringele created an issue Magnolia Demo Projects / MGNLDEMO-23 Dialogs: Don't use extends for no reson (or some might possible future easons) Issue Type: Bug Affects Versions: 1.0 Assignee: Philip Mundt Attachments: Demo_TextImage_DialogExtends.png Components: magnolia-travels Created: 06/May/15 12:13 PM Priority: Major Reporter: Christian Ringele Something that killed STK is the way to complex referencing of configurations via extends. Extends is a really cool feature, if there is a good reason to use it (real need of variations). But until there is a real need of it, using if for future possible extensions is contradicting this: the goal should be that it is straight forward and by this easy to understand for beginners
[magnolia-dev] [JIRA] (MTE-20) Don't store html elements in website workspace, use named/speaking headlineLevels instead
Title: Message Title Christian Ringele updated an issue Magnolia Templating Essentials / MTE-20 Don't store html elements in website workspace, use named/speaking headlineLevels instead Change By: Christian Ringele Summary: Don'tstorehtmlelementsinwebsiteworkspace,usenamed /speaking headlineLevelsinstead Add Comment This message was sent by Atlassian JIRA (v6.4.1#64016-sha1:5d75814) Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MTE-20) Don't store html elements in website workspace, use named headlineLevels instead
Title: Message Title Christian Ringele updated an issue Magnolia Templating Essentials / MTE-20 Don't store html elements in website workspace, use named headlineLevels instead Change By: Christian Ringele Attachment: Demo_TxtImage_CurrentImpl_HeadinLevels.png Add Comment This message was sent by Atlassian JIRA (v6.4.1#64016-sha1:5d75814) Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLDEMO-22) Freemarker Scripts: Should be simplified and best practices should be used
Title: Message Title
Christian Ringele created an issue
Magnolia Demo Projects / MGNLDEMO-22
Freemarker Scripts: Should be simplified and best practices should be used
Issue Type:
Improvement
Assignee:
Philip Mundt
Components:
magnolia-travels
Created:
06/May/15 11:50 AM
Fix Versions:
1.0
Priority:
Major
Reporter:
Christian Ringele
I see in many scripts parts which are either too complicated or do not use scripting best practices. This should be changes to make the readability and understandability much better.
One example (textImage.ftl): Original
[#assign headingLevel = h2]
[#if content.headingLevel?has_content]
[#assign headingLevel = content.headingLevel]
[/#if]
[#if content.headline?has_content]
${headingLevel}${content.headline!}/${headingLevel}
[/#if]
Replacing with (using properly !):
[#assign headingLevel = content.headingLevel!h2]
[#if content.headline?has_content]
[magnolia-dev] [JIRA] (MGNLUI-3339) Vaadin Communication Problem error message on slow connections
Title: Message Title Christian Ringele updated an issue Magnolia UI / MGNLUI-3339 Vaadin Communication Problem error message on slow connections Change By: Christian Ringele Labels: OnDemand support Add Comment This message was sent by Atlassian JIRA (v6.4.1#64016-sha1:5d75814) Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3473) Tranformer for TwinColumnField: Provide transformers alike the DelegatingMultiValueFieldTransformer and DelegatingMultiValueSubnodeTransformer for the TwinColumnFi
Title: Message Title Christian Ringele created an issue Magnolia UI / MGNLUI-3473 Tranformer for TwinColumnField: Provide transformers alike the DelegatingMultiValueFieldTransformer and DelegatingMultiValueSubnodeTransformer for the TwinColumnField Issue Type: Improvement Affects Versions: 5.3.9 Assignee: Unassigned Components: forms Created: 25/Jun/15 2:46 PM Labels: support Priority: Neutral Reporter: Christian Ringele Security Level: Public The TwinColumnField (actually a ComboBox) stores the data by default into a JCR MultiValue property. Same as the as the MultiField does by default. There is also the need for TwinColumnField to have this
[magnolia-dev] [JIRA] (MGNLUI-3446) RichTextField: reguired=true validator is ignored when using a jsConfig file
Title: Message Title Christian Ringele updated an issue Magnolia UI / MGNLUI-3446 RichTextField: reguired=true validator is ignored when using a jsConfig file Change By: Christian Ringele Summary: RichTextField:reguired=truevalidatoris if ignored whenusingajsConfigfile Add Comment This message was sent by Atlassian JIRA (v6.4.1#64016-sha1:5d75814) Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MGNLUI-3446) RichTextField: reguired=true validator is if when using a jsConfig file
Title: Message Title Christian Ringele updated an issue Magnolia UI / MGNLUI-3446 RichTextField: reguired=true validator is if when using a jsConfig file Change By: Christian Ringele Summary: RichTextField:reguired=truevalidatoris ifnored if whenusingajsConfigfile Add Comment This message was sent by Atlassian JIRA (v6.4.1#64016-sha1:5d75814) Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
