- xwiki-devs@xwiki.org - lists.xwiki.org

Re: [xwiki-devs] [xwiki-notifications] r33282 - in platform/xwiki-plugins/trunk/activitystream/src/main/java/com/xpn/xwiki/plugin/activitystream: api impl plugin
by Vincent Massol 07 Dec '10

07 Dec '10

On Dec 7, 2010, at 2:30 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-12-07 02:30:38 +0100 (Tue, 07 Dec 2010) > New Revision: 33282 > > Modified: > platform/xwiki-plugins/trunk/activitystream/src/main/java/com/xpn/xwiki/plugin/activitystream/api/ActivityStream.java > platform/xwiki-plugins/trunk/activitystream/src/main/java/com/xpn/xwiki/plugin/activitystream/impl/ActivityStreamImpl.java > platform/xwiki-plugins/trunk/activitystream/src/main/java/com/xpn/xwiki/plugin/activitystream/plugin/ActivityStreamPluginApi.java > Log: > XPLUCENE-74: Add a method to return the list of pages with events grouped by days and sorted by the event date Error in JIRA issue? Thanks -Vincent

2 1

[xwiki-devs] [PROPOSAL] Rename Document*Event + new events before document save
by Jerome Velociter 07 Dec '10

07 Dec '10

Hi devs, This is a buy one, get two proposal. I propose that first we rename DocumentUpdateEvent and DocumentSaveEvent to respectively DocumentUpdatedEvent and DocumentCreatedEvent. Which would be both more clear and would comply to the naming rules we've agreed on (see http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I don't mean real rename, but deprecation of the old events and creation of two new ones. Then I propose we introduce two new events : DocumentCreatingEvent and DocumentUpdatingEvent, that would be fired before the actual save. This is a pretty common use case for code that needs to hook on save to perform any kind of verification/pre-computation/etc. This is the same idea as the "preverify" method of the legacy notification mechanism. The events would actually be fired from the same place as the preverify method in old XWiki.java. WDYT ? I'm +1 and if we agree I volunteer to make those changes on 3.0 branch - and maybe the 2.7 too if we agree we want that too (I do).

4 9

Re: [xwiki-devs] [xwiki-notifications] r33290 - in platform: core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/packaging web/trunk/standard/src/main/webapp/resources/js/xwiki/importer web/trunk/standard/src/main/webapp/templates
by Thomas Mortagne 07 Dec '10

07 Dec '10

On Tue, Dec 7, 2010 at 11:39, Jean-Vincent Drean <jv(a)xwiki.com> wrote: > On Tue, Dec 7, 2010 at 11:26 AM, jvdrean > <platform-notifications(a)xwiki.org> wrote: >> Author: jvdrean >> Date: 2010-12-07 11:26:25 +0100 (Tue, 07 Dec 2010) >> New Revision: 33290 >> >> Modified: >> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/packaging/PackageAPI.java >> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/importer/import.js >> platform/web/trunk/standard/src/main/webapp/templates/importinline.vm >> platform/web/trunk/standard/src/main/webapp/templates/javascript.vm >> Log: >> XWIKI-5724 : On import document author is not the current user >> >> Replaced the need of programming rights by a dedicated right retrieved from the packager plugin (impl: admin rights on the same wiki). > > read: _main_ wiki. Note that it's possible to modify a svn log. > >> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/packaging/PackageAPI.java >> =================================================================== >> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/packaging/PackageAPI.java 2010-12-07 04:42:49 UTC (rev 33289) >> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/packaging/PackageAPI.java 2010-12-07 10:26:25 UTC (rev 33290) >> @@ -121,6 +121,25 @@ >> { >> this.plugin.setBackupPack(backupPack); >> } >> + >> + /** >> + * Indicate if the current user has the right to import a package as a backup pack. In this implementation, to be >> + * able to import has backup pack the user must have the admin right on the XWiki.XWikiPreferences document from >> + * the main wiki (xwiki:XWiki.XWikiPreferences). The goal is to prevent local wiki administrators from importing >> + * documents saved with a global administrator as the author (rights escalation). >> + * >> + * @return true if the current user has the rights to import a package as a backup pack, false otherwise >> + */ >> + public boolean hasBackupPackImportRights() >> + { >> + try { >> + return context.getWiki().getRightService() >> + .hasAccessLevel("admin", context.getUser(), "xwiki:XWiki.XWikiPreferences", context); >> + } catch (XWikiException e) { >> + e.printStackTrace(); >> + return false; >> + } >> + } >> >> public boolean isVersionPreserved() >> { >> >> Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/importer/import.js >> =================================================================== >> --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/importer/import.js 2010-12-07 04:42:49 UTC (rev 33289) >> +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/importer/import.js 2010-12-07 10:26:25 UTC (rev 33290) >> @@ -252,7 +252,7 @@ >> .insert( new Element("input", { 'type':'radio','name':'historyStrategy', 'value': 'reset' }) ) >> .insert(translations["resetHistory"] ) ); >> >> - if (XWiki.hasProgramming) { >> + if (XWiki.hasBackupPackImportRights) { >> var importAsBackupCheckbox = new Element("input", { 'type':'checkbox', 'name':'importAsBackup', 'value':'true' }); >> if (infos.backup) { >> importAsBackupCheckbox.checked = true; >> >> Modified: platform/web/trunk/standard/src/main/webapp/templates/importinline.vm >> =================================================================== >> --- platform/web/trunk/standard/src/main/webapp/templates/importinline.vm 2010-12-07 04:42:49 UTC (rev 33289) >> +++ platform/web/trunk/standard/src/main/webapp/templates/importinline.vm 2010-12-07 10:26:25 UTC (rev 33290) >> @@ -194,7 +194,7 @@ >> $msg.get('core.importer.resetHistory') >> </div> >> </div> >> - #if($xwiki.hasProgrammingRights()) >> + #if($packager.hasBackupPackImportRights()) >> <div class="importOption"> >> <input type="checkbox" name="importAsBackup" value="true" #if($packager.isBackupPack())checked="checked"#end/> >> $msg.get('core.importer.importAsBackup') >> >> Modified: platform/web/trunk/standard/src/main/webapp/templates/javascript.vm >> =================================================================== >> --- platform/web/trunk/standard/src/main/webapp/templates/javascript.vm 2010-12-07 04:42:49 UTC (rev 33289) >> +++ platform/web/trunk/standard/src/main/webapp/templates/javascript.vm 2010-12-07 10:26:25 UTC (rev 33290) >> @@ -40,6 +40,7 @@ >> XWiki.blacklistedSpaces = [ #foreach($space in $blacklistedSpaces)#if($velocityCount > 1),#end"$space"#end ]; >> XWiki.hasEdit = $hasEdit; >> XWiki.hasProgramming = $hasProgramming; >> +XWiki.hasBackupPackImportRights = $xwiki.package.hasBackupPackImportRights(); >> window.docviewurl = "${doc.getURL('view')}"; >> window.docediturl = "${doc.getURL('edit')}"; >> window.docsaveurl = "${doc.getURL('save')}"; >> >> _______________________________________________ >> notifications mailing list >> notifications(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/notifications >> > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > -- Thomas Mortagne

1 0

Re: [xwiki-devs] [xwiki-notifications] r33291 - platform/core/branches/xwiki-core-2.6/xwiki-core/src/main/java/com/xpn/xwiki/plugin/packaging
by Thomas Mortagne 07 Dec '10

07 Dec '10

On Tue, Dec 7, 2010 at 11:33, jvdrean <platform-notifications(a)xwiki.org> wrote: > Author: jvdrean > Date: 2010-12-07 11:33:35 +0100 (Tue, 07 Dec 2010) > New Revision: 33291 > > Modified: > platform/core/branches/xwiki-core-2.6/xwiki-core/src/main/java/com/xpn/xwiki/plugin/packaging/PackageAPI.java > Log: > XWIKI-5724 : On import document author is not the current user > > Replaced the need of programming rights by a dedicated right retrieved from the packager plugin (impl: admin rights on the same wiki). It is equivalent > with one exception, this method allows guests to import the initial XAR as backup pack in an empty wiki. > > Merged from trunk @ r33290. > > > > Modified: platform/core/branches/xwiki-core-2.6/xwiki-core/src/main/java/com/xpn/xwiki/plugin/packaging/PackageAPI.java > =================================================================== > --- platform/core/branches/xwiki-core-2.6/xwiki-core/src/main/java/com/xpn/xwiki/plugin/packaging/PackageAPI.java 2010-12-07 10:26:25 UTC (rev 33290) > +++ platform/core/branches/xwiki-core-2.6/xwiki-core/src/main/java/com/xpn/xwiki/plugin/packaging/PackageAPI.java 2010-12-07 10:33:35 UTC (rev 33291) > @@ -121,6 +121,25 @@ > { > this.plugin.setBackupPack(backupPack); > } > + > + /** > + * Indicate if the current user has the right to import a package as a backup pack. In this implementation, to be > + * able to import has backup pack the user must have the admin right on the XWiki.XWikiPreferences document from > + * the main wiki (xwiki:XWiki.XWikiPreferences). The goal is to prevent local wiki administrators from importing > + * documents saved with a global administrator as the author (rights escalation). > + * > + * @return true if the current user has the rights to import a package as a backup pack, false otherwise > + */ > + public boolean hasBackupPackImportRights() > + { > + try { > + return context.getWiki().getRightService() > + .hasAccessLevel("admin", context.getUser(), "xwiki:XWiki.XWikiPreferences", context); You should never use "xwiki" and instead as the main wiki name to the API. > + } catch (XWikiException e) { > + e.printStackTrace(); > + return false; > + } > + } > > public boolean isVersionPreserved() > { > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > -- Thomas Mortagne

1 0

[xwiki-devs] [Activity Stream Plugin][Proposal] Modify or depricate searchUniquePages() method
by Raluca Stavro 07 Dec '10

07 Dec '10

Hello, The current searchUniquePages() method from the activitystream plugin returns the list unique page names sorted by max(event.date) desc. Because each page appears once in the list, the events for a page on previous days are not being displayed in the activity stream (on dashboard, user profile and tags). What searchUniquePages() method should actually return is the list of unique pages GROUPED and ordered BY DAY. Since this method is used only once, in the activity macro, the query inside it could be modified, so that the result list to match the activity stream requirements. Otherwise, I would have to create a new method, something like: searchUniquePagesPerDay() and depricate the searchUniquePages() method. What do you think that the best solution would be in this case? Raluca.

3 3

[xwiki-devs] [Proposal] Remove logging to xwiki.log by default
by Vincent Massol 06 Dec '10

06 Dec '10

Hi devs, I'd like to propose removing the log to xwiki.log by default in our log4j.properties file. The rationale is: * This is causing problems with a lot of users since by default we log in the current directory and there are lots of cases when users start xwiki from a directory where you don't have correct permissions * We don't control where xwiki.log is created Proposal: * We only log to stdout: ** tomcat is already configured to capture stdout/stderr and to redirect them to catalina.out ** I have a modification ready for Jetty to do the same, here it is in case you want to see it:    <New id="ServerLog" class="java.io.PrintStream"> <Arg> <New class="org.mortbay.util.RolloverFileOutputStream"> <Arg><SystemProperty name="jetty.home" default="."/>/logs/yyyy_mm_dd.stderrout.log</Arg> <Arg type="boolean">false</Arg> <Arg type="int">90</Arg> <Arg><Call class="java.util.TimeZone" name="getTimeZone"><Arg>GMT</Arg></Call></Arg> <Get id="ServerLogName" name="datedFilename"/> </New> </Arg> </New> <Call class="org.mortbay.log.Log" name="info"><Arg>Redirecting stderr/stdout to <Ref id="ServerLogName"/></Arg></Call> <Call class="java.lang.System" name="setErr"><Arg><Ref id="ServerLog"/></Arg></Call> <Call class="java.lang.System" name="setOut"><Arg><Ref id="ServerLog"/></Arg></Call> WDYT? Thanks -Vincent

10 12

[xwiki-devs] [Proposal] Modify or depricate the searchUniquePages() method from activitystream plugin
by Raluca Stavro 04 Dec '10

04 Dec '10

I'm sending this message again because I think it didn't get on the mailing list. Raluca. On Sat, Dec 4, 2010 at 6:02 PM, Raluca Stavro <raluca.morosan(a)xwiki.com> wrote: > Hello, > > The current searchUniquePages() method from the activitystream plugin > returns the list unique page names sorted by max(event.date) desc. > Because each page appears once in the list, the events for a page on > previous days are not being displayed in the activity stream (on > dashboard, user profile and tags). > What searchUniquePages() method should actually return is the list of > unique pages GROUPED and ordered BY DAY. > Since this method is used only once, in the activity macro, the query > inside it could be modified, so that the result list to match the > activity stream requirements. > Otherwise, I would have to create a new method, something like: > searchUniquePagesPerDay() and depricate the searchUniquePages() > method. > What do you think that the best solution would be in this case? > > Raluca. >

1 0

Re: [xwiki-devs] [xwiki-notifications] r33253 - in contrib/sandbox/xwiki-store/xwiki-store-filesystem-attachments/src/main/java: com/xpn/xwiki/doc com/xpn/xwiki/store org/xwiki/store org/xwiki/store/filesystem/internal org/xwiki/store/generic
by Sergiu Dumitriu 03 Dec '10

03 Dec '10

On 12/02/2010 11:43 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-12-02 23:43:19 +0100 (Thu, 02 Dec 2010) > New Revision: 33253 > > Added: > contrib/sandbox/xwiki-store/xwiki-store-filesystem-attachments/src/main/java/org/xwiki/store/generic/ Why don't you use org.apache.commons.io.input.AutoCloseInputStream instead? > contrib/sandbox/xwiki-store/xwiki-store-filesystem-attachments/src/main/java/org/xwiki/store/generic/CloseAtEndInputStream.java > Modified: > contrib/sandbox/xwiki-store/xwiki-store-filesystem-attachments/src/main/java/com/xpn/xwiki/doc/FilesystemAttachmentContent.java > contrib/sandbox/xwiki-store/xwiki-store-filesystem-attachments/src/main/java/com/xpn/xwiki/store/FilesystemAttachmentStore.java > contrib/sandbox/xwiki-store/xwiki-store-filesystem-attachments/src/main/java/org/xwiki/store/filesystem/internal/DefaultFilesystemStoreTools.java > Log: > [filesystem-attachment-store] Fixed a nasty lock contension bug caused by other code not closing the stream. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] [proposal] Filesystem based attachment storage.
by Caleb James DeLisle 03 Dec '10

03 Dec '10

I now have a working model of attachment storage in the sandbox. http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-… I can upload and download attachments with it simply by adding the .jar file to the /lib/ dir and changing the attachment store in the xwiki.cfg. This introduces a 2 major changes to the storage direction which I want to go over: 1. TransactionRunnable. This is a closure (like java.lang.Runnable) which does a job inside of a transaction, it also provides hooks for rollback, commit and complete events. The underlying concept is that code which is to run inside of a transaction is passed as an object to the storage engine where the transaction is opened and it is run. This will make the exception catching generic for all storage and Transaction is an interface independent of Hibernate or SQL. See the bottom part of: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-… NOTE: I have TransactionRunnable as a nested class while it is in development and I intend to move it out when it becomes more mature. 2. Filesystem hierarchical storage: An attachment called 30579.jpg a document called xwiki:Main.WebHome will be stored in a file at the path: work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg The names are URL encoded for security. The directory ~this contains a character which is URL invalid and thus insures that if nested spaces are implemented, a document called xwiki:Main.WebHome.attachments will not cause a collision. The "attachments" directory is a directory dedicated to attachments for the given document. The "30579.jpg" directory under the attachments directory is dedicated to all information related to that directory. This opens the possibility for attachment history to be stored along side the attachment content. WDYT? Caleb PS. This code currently contains no tests, I do not want to go any further until I know this path is agreed upon.

5 8

[xwiki-devs] Questions Regarding Relational storage
by mbryant 03 Dec '10

03 Dec '10

Hey Guys, I asked this in the user group a couple of days ago and I didn't get a response so I figured I would try to ask here. In the creation of List type properties for Xwiki objects, the option for relational storage is presented. My question is mainly what do I gain/lose by checking the relational storage option? How does it affect how the list is stored so on so forth? Thanks Martin Bryant -- View this message in context: http://xwiki.475771.n2.nabble.com/Questions-Regarding-Relational-storage-tp… Sent from the XWiki- Dev mailing list archive at Nabble.com.

1 0