[magnolia-dev] [JIRA] (VANITY-4) External link building

2014-08-13 Thread JIRA (on behalf of Frank Sommer) 














































Frank Sommer
 updated  VANITY-4


External link building
















Change By:


Frank Sommer
(13/Aug/14 8:55 AM)




Fix Version/s:


1.3.0



























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] (VANITY-3) URL title + url configuration

2014-08-13 Thread JIRA (on behalf of Frank Sommer) 














































Frank Sommer
 updated  VANITY-3


URL title + url configuration
















Change By:


Frank Sommer
(13/Aug/14 8:56 AM)




Fix Version/s:


1.3.0



























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] (VANITY-6) App stopping after starting in 5.3

2014-08-13 Thread JIRA (on behalf of Frank Sommer) 














































Frank Sommer
 updated  VANITY-6


App stopping after starting in 5.3
















Change By:


Frank Sommer
(13/Aug/14 8:53 AM)




Fix Version/s:


1.3.0



























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] (VANITY-7) Label for delete confirm dialog not set

2014-08-13 Thread JIRA (on behalf of Frank Sommer) 














































Frank Sommer
 updated  VANITY-7


Label for delete confirm dialog not set
















Change By:


Frank Sommer
(13/Aug/14 8:53 AM)




Fix Version/s:


1.3.0



























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-3096) Section availability for multiple selection is plain wrong

2014-08-13 Thread on behalf of Mikaël Geljic 














































Mikaël Geljic
 updated  MGNLUI-3096


Section availability for multiple selection is plain wrong
















Change By:


Mikaël Geljic
(13/Aug/14 10:25 AM)




Description:


Therewasonesillycodeleftoverfrom5.3developmentin{{ConfiguredActionbarSectionDefinition}},whichItentativelyremovedaheadof5.3.2,buthadtorevertback:

{code:java}publicvoidsetAvailability(AvailabilityDefinitionavailability){//FIXMEThisisplainwrong,availabilityformultipleselectionmatchessectionsforwhichitisnotconfigured(i.e.settofalse)//Butwehavetokeepitforthetimebeingbecausesomecontentappsrelyonthisincorrectbehavior.((ConfiguredAvailabilityDefinition)availability).setMultiple(true);this.availability=availability;}{code}Inessence:-availabilityformultipleselectionmatchessectionsforwhichthemultiplepropertyisnottrue(i.e.non-exisitingorsettofalse)-butmanycontentapps(+UItests)relyonthisincorrectbehavior.--e.g.contacts,categoriesdohavea_multiple_sectionconfigured,buttheydontevenhavean{{availability}}subnodewith{{multiple}}setto{{true}}.--Whentrashingthesillyline,onecanendupwithenemptyactionbar.Asaresult,currentlywealwaysfallbackonthefirstconfiguredsection—typicallytheonedealingwithsingularitemselection—sothesetofactionsdisplayed,theirlabelingandthesectiontitleareallwrong._Sidenote:multipleavailabilitydoesworkcorrectlyonindividualactions;mostofthemareexpectedlydisabledwhenselectingmultipleitems._



























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-3096) Section availability for multiple selection is plain wrong

2014-08-13 Thread on behalf of Mikaël Geljic 














































Mikaël Geljic
 updated  MGNLUI-3096


Section availability for multiple selection is plain wrong
















Change By:


Mikaël Geljic
(13/Aug/14 10:25 AM)




Description:


Therewasonesillycodeleftoverfrom5.3developmentin{{ConfiguredActionbarSectionDefinition}},whichItentativelyremovedaheadof5.3.2,buthadtorevertback:

{code:java}publicvoidsetAvailability(AvailabilityDefinitionavailability){//FIXMEThisisplainwrong,availabilityformultipleselectionmatchessectionsforwhichitisnotconfigured(i.e.settofalse)//Butwehavetokeepitforthetimebeingbecausesomecontentappsrelyonthisincorrectbehavior.((ConfiguredAvailabilityDefinition)availability).setMultiple(true);this.availability=availability;}{code}Inessence:-availabilityformultipleselectionmatchessectionsforwhichthemultiplepropertyisnottrue(i.e.non-exisitingorsettofalse)-butmanycontentapps(+UItests)relyonthisincorrectbehavior.--e.g.contacts,categoriesdohavea_multiple_sectionconfigured,buttheydontevenhavean{{availability}}subnodewith{{multiple}}setto{{true}}.--Whentrashingthesillyline,onecanendupwithenemptyactionbar.Asaresult,currentlywealwaysfallbackonthefirstconfiguredsection—typicallytheonedealingwithsingularitemselection—sothesetofactionsdisplayed,theirlabelingandthesectiontitleareallwrong._Sidenote:multipleavailabilitydoesworkcorrectlyonindividualactions;mostofthemareexpectedlydisabledwhenselectingmultipleitems._



























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-3096) Section availability for multiple selection is plain wrong

2014-08-13 Thread on behalf of Mikaël Geljic 














































Mikaël Geljic
 created  MGNLUI-3096


Section availability for multiple selection is plain wrong















Issue Type:


Bug



Affects Versions:


5.2.8, 5.3.2



Assignee:


Unassigned


Created:


13/Aug/14 10:25 AM



Description:


There was one silly code leftover from 5.3 development in ConfiguredActionbarSectionDefinition, which I tentatively removed ahead of 5.3.2, but had to revert back:

public void setAvailability(AvailabilityDefinition availability) {
// FIXME This is plain wrong, availability for multiple selection matches sections for which it is not configured (i.e. set to false)
// But we have to keep it for the time being because some content apps rely on this incorrect behavior.
((ConfiguredAvailabilityDefinition) availability).setMultiple(true);
this.availability = availability;
}

In essence:

	availability for multiple selection matches sections for which the multiple property is not true (i.e. non-exisiting or set to false)
	but many content apps (+ UI tests) rely on this incorrect behavior.
	
		e.g. contacts, categories do have a multiple section configured, but they don't even have an availability subnode with multiple set to true.
		When trashing the silly line, one can end up with en empty action bar.
	
	



As a result, currently we always fall back on the first configured section — typically the one dealing with singular item selection — so the set of actions displayed, their labeling and the section title are all wrong.

Side note: multiple availability does work correctly on individual actions; most of them are expectedly disabled when selecting multiple items.




Fix Versions:


5.3.x



Project:


Magnolia UI



Labels:


availability
actionbar




Priority:


Major




Reporter:


Mikaël Geljic



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-3058) PagesEditor sub-app should check the type of the changed item id

2014-08-13 Thread JIRA (on behalf of Daniel Lipp) 














































Daniel Lipp
 updated  MGNLUI-3058


PagesEditor sub-app should check the type of the changed item id
















Change By:


Daniel Lipp
(13/Aug/14 11:08 AM)




Fix Version/s:


5.3.3





Fix Version/s:


5.3.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] (MGNLUI-3097) Use Action Availability for action in page editor

2014-08-13 Thread JIRA (on behalf of Espen Jervidalo) 














































Espen Jervidalo
 created  MGNLUI-3097


Use Action Availability for action in page editor















Issue Type:


Improvement



Affects Versions:


5.3.2



Assignee:


Espen Jervidalo



Components:


page editor, pages app



Created:


13/Aug/14 11:29 AM



Description:


While we introduced the possibility to use action availability in the page editor, most actions are still hardcoded in the PagesEditorSubApp. This makes it hard to adapt simple changes to the rules. It also clutters the code.




Fix Versions:


5.3.3



Project:


Magnolia UI



Priority:


Neutral




Reporter:


Espen Jervidalo



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] (MGNLCACHE-61) Update default ehcache configuration

2014-08-13 Thread on behalf of Grégory Joseph 














































Grégory Joseph
 updated  MGNLCACHE-61


Update default ehcache configuration
















Change By:


Grégory Joseph
(13/Aug/14 11:43 AM)




Summary:


Updatedefault
ehcache
configuration



























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] (MGNLCACHE-61) Update default ehcache configuration

2014-08-13 Thread on behalf of Grégory Joseph 














































Grégory Joseph
 updated  MGNLCACHE-61


Update default ehcache configuration
















Change By:


Grégory Joseph
(13/Aug/14 11:43 AM)




Description:


*addnewcacheConfigurationproperty
*renamedeprecatedpropertiestotheirreplacementcounterparts



























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] (MGNLCACHE-69) Implement javax.inject.Provider which injects a @Named cache

2014-08-13 Thread on behalf of Grégory Joseph 














































Grégory Joseph
 created  MGNLCACHE-69


Implement javax.inject.Provider which injects a @Named cache















Issue Type:


Task



Assignee:


Unassigned


Created:


13/Aug/14 11:59 AM



Description:


With MGNLCACHE-55, one can cache arbitrary objects (that was already the case, but the API was awkward, and the cache could not be configured), but one still has to :


public class FooBar {
  private final Cache cache;
  @Inject
  public FooBar(CacheModule cacheModule) {
// or keep a ref to module and retrieve the cache when needed
this.cache = cacheModule.getCacheFactory().getCache("foo-cache");
  }
}



It'd be nice if one could do this instead:


public class FooBar {
  private final Cache cache;
  @Inject
  public FooBar(@Named("foo-cache") Cache cache) {
this.cache = cache;
  }
}



Another approach (or additional) would let one inject an unnamed Cache, and the name would, by convention, be the class name of the injectee.




Fix Versions:


5.3



Project:


Magnolia Cache Module



Priority:


Neutral




Reporter:


Grégory Joseph




























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] (MGNLCACHE-69) Implement javax.inject.Provider which injects a @Named cache

2014-08-13 Thread on behalf of Grégory Joseph 














































Grégory Joseph
 updated  MGNLCACHE-69


Implement javax.inject.Provider which injects a @Named cache
















Change By:


Grégory Joseph
(13/Aug/14 12:00 PM)




Description:


WithMGNLCACHE-55,onecancachearbitraryobjects(thatwasalreadythecase,buttheAPIwasawkward,andthecachecouldnotbeconfigured),butonestillhasto:{code:java}publicclassFooBar{privatefinalCachecache;@InjectpublicFooBar(CacheModulecacheModule){//orkeepareftomoduleandretrievethecachewhenneededthis.cache=cacheModule.getCacheFactory().getCache(foo-cache);}}{code}Itdbe*nice*ifonecoulddothisinstead:{code:java}publicclassFooBar{privatefinalCachecache;@InjectpublicFooBar(@Named(foo-cache)Cachecache){this.cache=cache;}}{code}Anotherapproach(oradditional)wouldletoneinjectanunnamedCache,andthenamewould,byconvention,betheclassnameoftheinjectee.
{code:java}packagezim.zam;publicclassFooBar{privatefinalCachecache;@InjectpublicFooBar(Cachecache){assertcache.getName().equals(zim.zam.FooBar);this.cache=cache;}}{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-3098) Bulk oprtation MoveNodeAction: Move After is reverting the chosen Node order

2014-08-13 Thread JIRA (on behalf of Christian Ringele) 














































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

2014-08-13 Thread JIRA (on behalf of Christian Ringele) 














































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

2014-08-13 Thread JIRA (on behalf of Christian Ringele) 














































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

2014-08-13 Thread JIRA (on behalf of Christian Ringele) 














































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

2014-08-13 Thread JIRA (on behalf of Christian Ringele) 














































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

2014-08-13 Thread JIRA (on behalf of Christian Ringele) 














































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] (MGNLUI-3099) Changes in admincentral setup needed for merging activationMonitor into activation

2014-08-13 Thread JIRA (on behalf of Evzen Fochr) 














































Evzen Fochr
 created  MGNLUI-3099


Changes in admincentral setup needed for merging activationMonitor into activation















Issue Type:


Bug



Affects Versions:


5.3.2



Assignee:


Evzen Fochr



Created:


13/Aug/14 2:33 PM



Fix Versions:


5.3.x



Project:


Magnolia UI



Priority:


Neutral




Reporter:


Evzen Fochr



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] (MGNLWORKFLOW-268) CompleteTaskAction links in its deprecation information to the wrong successor class.

2014-08-13 Thread JIRA (on behalf of Christian Ringele) 














































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.

2014-08-13 Thread JIRA (on behalf of Christian Ringele) 














































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-3099) Changes in admincentral setup needed for merging activationMonitor into activation

2014-08-13 Thread JIRA (on behalf of Evzen Fochr) 














































Evzen Fochr
 deleted  MGNLUI-3099


Changes in admincentral setup needed for merging activationMonitor into activation
























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

2014-08-13 Thread JIRA (on behalf of Peili Liang) 














































Peili Liang
 updated  MGNLFORUM-270


DefaultForumManager#isModerator() checks only the directly attached roles of the user, but ignores his roles inherited from his groups
















Change By:


Peili Liang
(13/Aug/14 3:14 PM)




Fix Version/s:


3.4.3





Fix Version/s:


3.4.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] (MGNLCACHE-32) Upgrade EhCache to 2.8

2014-08-13 Thread on behalf of Grégory Joseph 














































Grégory Joseph
 updated  MGNLCACHE-32


Upgrade EhCache to 2.8
















Change By:


Grégory Joseph
(13/Aug/14 4:47 PM)




Summary:


Upgrade
ehcache
EhCacheto2.8



























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] (MGNLCACHE-32) Upgrade Ehcache to 2.8

2014-08-13 Thread on behalf of Grégory Joseph 














































Grégory Joseph
 updated  MGNLCACHE-32


Upgrade Ehcache to 2.8
















Change By:


Grégory Joseph
(13/Aug/14 4:47 PM)




Summary:


Upgrade
EhCache
Ehcache
to2.8



























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] (MGNLCACHE-68) Set explicit name for Ehcache CacheManager

2014-08-13 Thread on behalf of Grégory Joseph 














































Grégory Joseph
 updated  MGNLCACHE-68


Set explicit name for Ehcache CacheManager
















Change By:


Grégory Joseph
(13/Aug/14 4:47 PM)




Summary:


Setexplicitnamefor
ehcache
Ehcache
CacheManager



























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

2014-08-13 Thread JIRA (on behalf of Christian Ringele) 














































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] (MGNLCACHE-70) Update modules installs for new config OR change flush policy workspace registration

2014-08-13 Thread on behalf of Grégory Joseph 














































Grégory Joseph
 created  MGNLCACHE-70


Update modules installs for new config OR change flush policy workspace registration















Issue Type:


Sub-task



Assignee:


Unassigned


Created:


13/Aug/14 5:32 PM



Description:


With MGNLCACHE-55, we changed the location of flush policy configuration. Because of this, a number of modules fail to install:

 Could not create property contacts at /modules/cache/config/configurations/default/flushPolicy/policies/flushAll/repositories, please create it with value contacts.
 Could not create property dam at /modules/cache/config/configurations/default/flushPolicy/policies/flushAll/repositories, please create it with value dam.
 Could not install or update standard-templating-kit module. Task 'Browser cache policy' failed. (ItemNotFoundException: node /modules/cache/config/configurations/default/browserCachePolicy/policies has no child node with name default)
 Could not create property category at /modules/cache/config/configurations/default/flushPolicy/policies/flushAll/repositories, please create it with value category.
 Could not install or update personalization-integration module. Task 'Cache setup' failed. (PathNotFoundException: modules/cache/config/configurations)



We have two (non-exclusive) options:

	update each and every module.
	change how flush policies are configured: assume we want to flush all repositories by default and only configure exceptions.






Fix Versions:


5.3



Project:


Magnolia Cache Module



Priority:


Major




Reporter:


Grégory Joseph




























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] (MGNLCACHE-55) Caching arbitrary objects

2014-08-13 Thread on behalf of Grégory Joseph 














































Grégory Joseph
 updated  MGNLCACHE-55


Caching arbitrary objects
















Change By:


Grégory Joseph
(13/Aug/14 5:57 PM)




Comment:


ReportedMGNLCACHE-70forchangestobedoneonothermodules(whichwillthenbelinkedtomodulesticketsifwedecidetogodownthatroute)



























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.

2014-08-13 Thread on behalf of Mikaël Geljic 














































Mikaël Geljic
 updated  MGNLUI-2371


CKEditor should be implemented using the Vaadin7 components.
















Edited this issue: untied it from the CKEditor loading issue (MGNLUI-3052) that was fixed several weeks ago, and moved it as improvement to the backlog.





Change By:


Mikaël Geljic
(13/Aug/14 6:14 PM)




Issue Type:


Bug
Improvement





Labels:


ckeditor
support





Fix Version/s:


Backlog





Fix Version/s:


5.2.x





Description:


TheCKEditorimplementationshouldberefactoredintwoway:1.Makeitmoreflexibleadding(andtesting)CKEditorplugins
:MGNLUI-1947
(asJSextension?)
2.
The
Dropthe
Vaadin
componentshould
wrapperadd-onand
usetheVaadin7datapipeforcommunicationtothebackendandnotthelegacyVaadin6code.





Component/s:


forms



























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