May 2010 - xwiki-devs@xwiki.org

[xwiki-devs] [ANN] XWiki Office 1.1.1 released
by Florin Ciubotaru 10 May '10

10 May '10

The XWiki development team is pleased to announce the release of XWiki Office 1.1.1. This is a bug fix release of version 1.1. All active XOffice instances will be automatically updated. Bugs fixed in version 1.1.1 - Styles not preserved after multiple edits - Image upload and download on localized versions of Microsoft Office - Image upload on pages containing white characters - Grammar markup filtering when on non-English language default settings - Refreshing published documents Detailed release notes are available at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXOffice111 For more information about XOffice please visit: http://xoffice.xwiki.org Thanks, - The XWiki dev team

2 1

Re: [xwiki-devs] [VOTE] "member" field of XWikiGroups objects is supposed to contains only one member (summary)
by Thomas Mortagne 10 May '10

10 May '10

On Mon, May 10, 2010 at 09:34, Ludovic Dubost <ludovic(a)xwiki.org> wrote: > I was also +1 on this.. > > However it would be nice to provide a script to detect any data that might > have been using the feature, and put it in the release notes > Things is that this feature was pretty much not usable anyway since not all the places manipulating groups was using it, in fact it was only applied by XWikiGroupServiceImpl#listMemberForGroup. > > Ludovic > > Le 09/05/10 12:44, Thomas Mortagne a écrit : > > 3 +1 >> >> Committed in trunk >> >> On Fri, May 7, 2010 at 18:36, Thomas Mortagne<thomas.mortagne(a)xwiki.com >> >wrote: >> >> >> >>> Hi devs, >>> >>> I recently created http://jira.xwiki.org/jira/browse/XWIKI-5149, this >>> issue is due to the fact that XWikiGroupServiceImpl#listMemberForGroup >>> is splitting the value of the "member" field based on white space and >>> comma. >>> >>> That does not make sense IMO and makes impossible to have a user with >>> a white space (and comma which is less common) in its name for a very >>> bad reason. Also the name of the field is "member" and not "members". >>> Last reason is that i think in all other places we don't take this >>> value as a list. >>> >>> Note that this bug is mainly a pain for authenticators where you have >>> to remember the real name of the user and have some collision handling >>> to support use case users "somename" and "some name" coming for an >>> external authentication server in which theses are two different >>> users. >>> >>> WDYT ? >>> >>> Here is my +1. >>> >>> -- >>> Thomas Mortagne >>> >>> >>> >> >> >> >> > > > -- > Ludovic Dubost > Blog: http://blog.ludovic.org/ > XWiki: http://www.xwiki.com > Skype: ldubost GTalk: ldubost > > -- Thomas Mortagne

1 0

Re: [xwiki-devs] [VOTE] "member" field of XWikiGroups objects is supposed to contains only one member (summary)
by Thomas Mortagne 10 May '10

10 May '10

3 +1 Committed in trunk On Fri, May 7, 2010 at 18:36, Thomas Mortagne <thomas.mortagne(a)xwiki.com>wrote: > Hi devs, > > I recently created http://jira.xwiki.org/jira/browse/XWIKI-5149, this > issue is due to the fact that XWikiGroupServiceImpl#listMemberForGroup > is splitting the value of the "member" field based on white space and > comma. > > That does not make sense IMO and makes impossible to have a user with > a white space (and comma which is less common) in its name for a very > bad reason. Also the name of the field is "member" and not "members". > Last reason is that i think in all other places we don't take this > value as a list. > > Note that this bug is mainly a pain for authenticators where you have > to remember the real name of the user and have some collision handling > to support use case users "somename" and "some name" coming for an > external authentication server in which theses are two different > users. > > WDYT ? > > Here is my +1. > > -- > Thomas Mortagne > -- Thomas Mortagne

2 1

[xwiki-devs] [VOTE] "member" field of XWikiGroups objects is supposed to contains only one member
by Thomas Mortagne 09 May '10

09 May '10

Hi devs, I recently created http://jira.xwiki.org/jira/browse/XWIKI-5149, this issue is due to the fact that XWikiGroupServiceImpl#listMemberForGroup is splitting the value of the "member" field based on white space and comma. That does not make sense IMO and makes impossible to have a user with a white space (and comma which is less common) in its name for a very bad reason. Also the name of the field is "member" and not "members". Last reason is that i think in all other places we don't take this value as a list. Note that this bug is mainly a pain for authenticators where you have to remember the real name of the user and have some collision handling to support use case users "somename" and "some name" coming for an external authentication server in which theses are two different users. WDYT ? Here is my +1. -- Thomas Mortagne

4 3

Re: [xwiki-devs] [xwiki-notifications] r28794 - platform/xwiki-applications/trunk/administration/src/main/resources/XWiki
by Sergiu Dumitriu 08 May '10

08 May '10

On 05/07/2010 10:42 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-05-07 22:42:06 +0200 (Fri, 07 May 2010) > New Revision: 28794 > > Modified: > platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml > Log: > XAADMINISTRATION-138: ConfigurableClass producing invalid xhtml > Fixed regression introduced in r28787 preventing saving. > > Modified: platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml > =================================================================== > --- platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml 2010-05-07 20:21:45 UTC (rev 28793) > +++ platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml 2010-05-07 20:42:06 UTC (rev 28794) > @@ -567,8 +567,8 @@ > #end > </label> > ## Have to prepend the app name to prevent id collisions. Are you sure it's always going to be _0_ ? > - $obj.display($propName, "edit").replaceAll("$objClass.getName()_0_$propName", > - "${escapedAppName}_$objClass.getName()_0_$propName") > + $obj.display($propName, "edit").replaceAll(" id='$objClass.getName()_0_$propName", > + " id='${escapedAppName}_$objClass.getName()_0_$propName") > </p> > #end## If property is in propertiesToShow > #end## Foreach property in this class > -- Sergiu Dumitriu http://purl.org/net/sergiu/

3 2

Re: [xwiki-devs] [xwiki-notifications] r28793 - platform/xwiki-applications/trunk/administration/src/main/resources/XWiki
by Sergiu Dumitriu 07 May '10

07 May '10

On 05/07/2010 10:21 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-05-07 22:21:45 +0200 (Fri, 07 May 2010) > New Revision: 28793 > > Modified: > platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml > Log: > XAADMINISTRATION-129: Fix save button for 'Registration> Customize XWiki.RegistrationConfig' > Javascript (which fixes buttons) now tested and working in IE7 > > Modified: platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml > =================================================================== > --- platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml 2010-05-07 18:00:43 UTC (rev 28792) > +++ platform/xwiki-applications/trunk/administration/src/main/resources/XWiki/ConfigurableClass.xml 2010-05-07 20:21:45 UTC (rev 28793) > @@ -222,15 +222,16 @@ > var errorShown = false; > for (var i = elementsInPage.length - 1; i> -1; i--) { > var e = elementsInPage[i]; > - if (e.tagName == 'DIV'&& e.getAttribute('class').indexOf('errormessage') != -1) > + if (e.tagName != undefined&& e.tagName.toLowerCase() == 'div'&& e.getAttribute('class') != undefined&& e.getAttribute('class').indexOf('errormessage') != -1) $(e).hasClassName('errormessage') is a better alternative, since indexOf can also match <div class="notanerrormessage"> > { > errorShown = true; > } else if (!errorShown > -&& e.tagName == 'H1' > -&& e.getAttribute('class') == 'wikigeneratedheader' > -&& e.getAttribute('id').indexOf('HCustomize') == 0) > +&& e.tagName != undefined > +&& e.tagName.toLowerCase() == 'h1' > +&& e.getAttribute('id') != undefined > +&& e.getAttribute('id').toLowerCase().indexOf('hcustomize') == 0) > { > - e.setAttribute('class', 'hidden'); > + e.parentNode.removeChild(e); $(e).remove() or $(e).hide(); You should have a look at what Prototype can offer, see http://www.prototypejs.org/api/element > errorShown = false; > } > } > @@ -239,8 +240,8 @@ > var forms = document.getElementsByTagName('form'); > var inputs = document.getElementsByTagName('input'); > for (var i = 0; i< inputs.length; i++) { > - if (inputs[i].getAttribute('type') == 'submit') { > - inputs[i].setAttribute('class', 'hidden'); > + if (inputs[i].getAttribute('type') != undefined&& inputs[i].getAttribute('type').toLowerCase() == 'submit') { > + inputs[i].parentNode.removeChild(inputs[i]); $(inputs[i]).remove(); > } > } > > @@ -302,6 +303,9 @@ > <number>0</number> > <className>XWiki.TagClass</className> > <guid>ddb1f0f6-1943-4e80-824a-0718cdbf1892</guid> > +<property> > +<tags/> > +</property> This looks like a leftover tag object which should be removed. > </object> > <content>{{velocity}} > #* -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] Should email invitation app be a top level application? How should I add it to the sandbox?
by Caleb James DeLisle 07 May '10

07 May '10

I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great. Caleb

7 18

[xwiki-devs] [Idea] Sanity check wiki pages for admins in XE
by Vincent Massol 07 May '10

07 May '10

Hi, Right now we check pages in our functional tests (xhtml validity, no error when executing the page, no failing macro). I was wondering about the idea of having the checks done inside wiki pages so that we could provide a sanity check wiki page in the admin section for admins. Then we would use that page from our junit test and people would also be able to run it too from inside their wiki. Thus killing 2 birds with one stone I think we're lacking such kind of tools for wiki admins and it could be interesting. WDYT? Thanks -Vincent

5 6

Re: [xwiki-devs] [Proposal] Support choosing pagination size in livetable UI
by Jerome Velociter 06 May '10

06 May '10

----- "Denis Gervalle" <dgl(a)softec.lu> wrote: > On Thu, May 6, 2010 at 15:43, Jerome Velociter <jerome(a)xwiki.com> > wrote: > > > Hi Denis, > > > > It's pretty nice. > > > > I've added an annotation on the patch > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer… > > > > The annotation dropped the end of my selection, it actually concerns > the > > following lines : > > > > + #if($!hasPageSize) > > + document.observe("xwiki:livetable:${divid}:loadingEntries", > function() > > { $('${divid}-pagesize').addClassName("hidden"); } ); > > + document.observe("xwiki:livetable:${divid}:loadingComplete", > > function() { $('${divid}-pagesize').removeClassName("hidden"); } ); > > + #end > > > > > Well, I do not follow. The JS is able to display one or more control, > anywhere you want. As well as it could be able to do the hiding on all such controls (LiveTablePageSizer has a references on all said domNodes) Choosing to put only one, and in the same place > then the > loading bar is just a design choice, that is the responsability of the > code > that produce the markup (the macro here). And the behavior of hiding > the > control is related. I don't see why placing it somewhere else (or having more) you would want a different behavior. In my opinion the macro should just consume the livetable JS constructor. If you need more JS code, it's probably that you need new options in the constructor (options which possibly be callback functions, not necessarly just flags/values). Finally, I think the proper behavior here would be to disable the control, instead of hidding its container. WDYT? Jerome. This is why I choose to add a additional even to > the > table, and put the observe in the macro. > > Denis > > > > Jerome. > > > > ----- Original Message ----- > > From: "Guillaume Lerouge" <guillaume(a)xwiki.com> > > To: "XWiki Developers" <devs(a)xwiki.org> > > Sent: Thursday, May 6, 2010 3:10:01 PM GMT +01:00 Amsterdam / Berlin > / Bern > > / Rome / Stockholm / Vienna > > Subject: Re: [xwiki-devs] [Proposal] Support choosing pagination > size in > > livetable UI > > > > Hi, > > > > On Thu, May 6, 2010 at 15:05, Denis Gervalle <dgl(a)softec.lu> wrote: > > > > > On Thu, May 6, 2010 at 14:55, Guillaume Lerouge > <guillaume(a)xwiki.com> > > > wrote: > > > > > > > Hi, > > > > > > > > On Thu, May 6, 2010 at 14:33, Denis Gervalle <dgl(a)softec.lu> > wrote: > > > > > > > > > Hi devs, > > > > > > > > > > Currently the number of rows displayed in a livetable is fixed > at > > > > creation > > > > > time. > > > > > I proposed to add UI controls (currently select) that allows > to > > change > > > > the > > > > > pagination size freely by the end user. > > > > > > > > > > This patch is be both a change in livetable.js to support > these > > > controls > > > > > (one or more), and a change in the livetable macro to allow > > displaying > > > > > them. > > > > > I have already a patch and some screenshots as well as bare > > > > documentation, > > > > > you can review them all at > > > > > > > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer > > > > > > > > > > I am currently testing different browsers to ensure there is > no > > > > regression. > > > > > > > > > > WDYT ? > > > > > > > > > > > > > Sounds very nice to me, I was asked about it in the past so I'm > +1. > > > > > > > > Only question -> is the preference remembered for the user? I > guess not > > > and > > > > that the default still is the number chose by the livetable > creator, > > but > > > > thought I'd ask. > > > > > > > > > > Well this is mainly a new functionality on the livetable, no > change in XE > > > in > > > my patch currently. My feeling is that keeping the information for > the > > user > > > should not be done by the livetable itself (JS), but by the caller > (the > > > macro, why not). It would not be so difficult to do with cookies, > it > > would > > > be a little bit more work to store the information in the user > profile. > > > Anyway, this is a second step. > > > > > > By the way, I have not proposed to change the current pages of XE, > but it > > > could be a nice idea. Do not hesitate to propose page you want me > to > > > improve. The other way, we may also set this new feature as a > default, so > > > it > > > will apear on all existing livetables using the macro, and allow > > disabling > > > it. WDYT ? > > > > > > > Yes, I'd make this available by default to all livetables, with a > > configuration parameter allowing to disable it on a case-by-case > basis. > > > > Guillaume > > > > > > > Denis > > > > > > -- > > > Denis Gervalle > > > SOFTEC sa - CEO > > > eGuilde sarl - CTO > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > -- > > Guillaume Lerouge > > Product Manager - XWiki SAS > > Skype: wikibc > > Twitter: glerouge > > http://guillaumelerouge.com/ > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

2 1

[xwiki-devs] [Proposal] Support choosing pagination size in livetable UI
by Denis Gervalle 06 May '10

06 May '10

Hi devs, Currently the number of rows displayed in a livetable is fixed at creation time. I proposed to add UI controls (currently select) that allows to change the pagination size freely by the end user. This patch is be both a change in livetable.js to support these controls (one or more), and a change in the livetable macro to allow displaying them. I have already a patch and some screenshots as well as bare documentation, you can review them all at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer I am currently testing different browsers to ensure there is no regression. WDYT ? Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

3 5