xwiki-devs December 2010

xwiki-devs@xwiki.org

32 participants
70 discussions

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

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

14 years

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

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

14 years

[xwiki-devs] [Activity Stream Plugin][Proposal] Modify or depricate searchUniquePages() method

by Raluca Stavro

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.

14 years

[xwiki-devs] [Proposal] Remove logging to xwiki.log by default

by Vincent Massol

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

14 years

[xwiki-devs] [Proposal] Modify or depricate the searchUniquePages() method from activitystream plugin

by Raluca Stavro

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

14 years

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

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/

14 years

[xwiki-devs] [proposal] Filesystem based attachment storage.

by Caleb James DeLisle

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.

14 years

[xwiki-devs] Questions Regarding Relational storage

by mbryant

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.

14 years

[xwiki-devs] [Investigation] [UX] Extension Manager

by Ecaterina Moraru (Valica)

Hi, Since XE 2.5 we have a beta version for the Extension Manager <http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…>. The scope of the Extension Manager is to manage XWiki extensions. I've made a page on Incubator with all the information I gathered about the ExtMng http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ExtensionManager The purpose of this mail thread is to brainstorm about the UI for the ExtMng. Feel free to contribute ideas. Thanks, Caty

14 years

[xwiki-devs] Fwd: [ANNOUNCE] Apache Velocity Engine 1.7

by Vincent Massol

fyi.... At some point we'll need to migrate. Some things I've noticed from the release notes: - their new syntax #[[...]]# is going to be fun for us... :( - the velocimacro.context.localscope replacement is important for us -Vincent Begin forwarded message: > From: Nathan Bubna <nbubna(a)apache.org> > Date: December 1, 2010 7:46:29 AM GMT+01:00 > To: announce(a)apache.org, Velocity Developers List <dev(a)velocity.apache.org>, Velocity Users List <user(a)velocity.apache.org>, general <general(a)velocity.apache.org> > Subject: [ANNOUNCE] Apache Velocity Engine 1.7 > > The Apache Velocity Team announces the immediate availability of the > of Apache Velocity Engine 1.7. This release is fully compatible with > the previous release and includes significant improvements in > performance, stability and features. > > Apache Velocity is well-known in the Java field as a lightweight, > easy-to-use templating library for creating dynamic web sites and > performing other text-generation tasks. > > Much work in this release has gone to making Velocity more > user-friendly, adding some long-desired features and improving many > others. Apart from this, numerous bugs were fixed (both common and > obscure), deprecation warnings were added to push people toward the > eventual 2.0 version, and performance continues to be improved. Some > details are listed below: > > * There are four new syntax features: > - #[[ This is a literal text block. It is not parsed, but directly > fed into the output. ]]# > - #@yourMacro() can now have body content. Just remember to add the > @ when calling it with a body! #end > - You can use brackets to get and set values in lists (and arrays). > e.g. #set( $foo[2] = $bar[$i] ) > - Quotes, both single and double, may be escaped in string literals > via doubling. e.g. #set( $foo = "Like ""this""!" ) > > * There are five notable deprecations: > - $velocityCount should be changed to $foreach.index (0-base) or > $foreach.count (1-base) > - $velocityHasNext should be changed to $foreach.hasNext, > $foreach.last or $foreach.first > - The #literal directive has been replaced by #[[ the much superior > textblock ]]# > - The velocimacro.context.localscope setting is being phased out; > please get/set local #macro references as members of the optional, > context-aware and self-documenting $macro "namespace" object. (e.g. > #set( $macro.foo = 'bar' ) and $macro.foo). Enable this by setting > macro.provide.scope.control=true in your properties. > - The directive.evaluate.context.class setting is being phased out; > please get/set local #evaluate references as members of the $evaluate > "namespace" object. Enable this by setting > evaluate.provide.scope.control=true in your properties. > > * The are three important changes: > - The #stop directive now stops rendering instead of parsing, making > it much more useful. > - The #break directive can now be used in any scope, not just in a > nested #foreach. It will terminate the nearest content "block", > whether a directive, a macro body, or an entire template. > - All templates, standard block (aka "content") directives, macros, > macro bodies, #evaluate content and #define blocks can be easily > configured to have an automatically-provided, context-aware and > self-documenting namespace reference in which you can safely and > securely #set and get any "local" references to keep them out of the > global context. > > See the change log for a more complete explanation of any and all of > these, or ask us about them at user(a)velocity.apache.org. > > Documentation Velocity 1.7 can be found here: > http://velocity.apache.org/engine/releases/velocity-1.7/ > > The change log is here: > http://velocity.apache.org/engine/releases/velocity-1.7/changes-report.html > > Apache Velocity 1.7 can be downloaded here: > http://velocity.apache.org/download.cgi > > For the Apache Velocity Team > Nathan Bubna > > --------------------------------------------------------------------- > To unsubscribe, e-mail: announce-unsubscribe(a)apache.org > For additional commands, e-mail: announce-help(a)apache.org > >

14 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2010