xwiki-devs September 2010

xwiki-devs@xwiki.org

40 participants
96 discussions

[xwiki-devs] [proposal] Dashboard macro implementation

by Anca Luca

Hi devs, knowing that gadgets will be xwiki macros instances (in any of the approaches) we need a way to add all these in a dashboard. Proposed options are at http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HDashboardMacr… . Currently implemented solution is 1/ which has a few drawbacks: it defines a meta syntax for its content and this syntax doesn't allow more complex layouts than a number of columns. The new proposal is 4) http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HOption429Colu… , which basically proposes to use nested column macros ( http://svn.xwiki.org/svnroot/xwiki/contrib/projects/xwiki-macro-column/ ) to do layouting and extend the section macro with a dashboard macro which would be used on the first level to mark that the columned content is a dashboard and not just regular wiki content. For more details about the approach see the description in the design page, as well as for the advantages of this proposal. my +1, I like this approach, I will try to prove the concept in the next days. WDYT? Thanks, Anca

13 years, 11 months

[xwiki-devs] Fwd: [xwiki-notifications] r31169 - in platform/web/trunk/standard/src/main/webapp: resources/js/xwiki/editors resources/js/xwiki/usersandgroups templates

by Jerome Velociter

Hello, See below. ---------- Forwarded message ---------- From: abusenius <platform-notifications(a)xwiki.org> Date: Sun, Sep 19, 2010 at 2:37 PM Subject: [xwiki-notifications] r31169 - in platform/web/trunk/standard/src/main/webapp: resources/js/xwiki/editors resources/js/xwiki/usersandgroups templates To: platform-notifications(a)xwiki.org > Author: abusenius > Date: 2010-09-19 14:37:25 +0200 (Sun, 19 Sep 2010) > New Revision: 31169 > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/editors/dataeditors.js > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js > platform/web/trunk/standard/src/main/webapp/templates/addnewgroup.vm > platform/web/trunk/standard/src/main/webapp/templates/attachmentsinline.vm > platform/web/trunk/standard/src/main/webapp/templates/attachwysiwyg.vm > platform/web/trunk/standard/src/main/webapp/templates/changeavatar.vm > platform/web/trunk/standard/src/main/webapp/templates/changemyavatar.vm > platform/web/trunk/standard/src/main/webapp/templates/commentsinline.vm > platform/web/trunk/standard/src/main/webapp/templates/copy.vm > platform/web/trunk/standard/src/main/webapp/templates/delete.vm > platform/web/trunk/standard/src/main/webapp/templates/documentTags.vm > platform/web/trunk/standard/src/main/webapp/templates/edit.vm > platform/web/trunk/standard/src/main/webapp/templates/editclass.vm > platform/web/trunk/standard/src/main/webapp/templates/editgroup.vm > platform/web/trunk/standard/src/main/webapp/templates/editinline.vm > platform/web/trunk/standard/src/main/webapp/templates/editobject.vm > platform/web/trunk/standard/src/main/webapp/templates/edituser.vm > platform/web/trunk/standard/src/main/webapp/templates/editwysiwyg.vm > platform/web/trunk/standard/src/main/webapp/templates/editwysiwygnew.vm > platform/web/trunk/standard/src/main/webapp/templates/getgroupmembers.vm > platform/web/trunk/standard/src/main/webapp/templates/historyinline.vm > platform/web/trunk/standard/src/main/webapp/templates/importinline.vm > platform/web/trunk/standard/src/main/webapp/templates/passwd.vm > platform/web/trunk/standard/src/main/webapp/templates/recyclebinlist.vm > platform/web/trunk/standard/src/main/webapp/templates/registerinline.vm > platform/web/trunk/standard/src/main/webapp/templates/registeruser.vm > platform/web/trunk/standard/src/main/webapp/templates/renameStep1.vm > platform/web/trunk/standard/src/main/webapp/templates/resetversions.vm > platform/web/trunk/standard/src/main/webapp/templates/rightsUI.vm > platform/web/trunk/standard/src/main/webapp/templates/rollback.vm > platform/web/trunk/standard/src/main/webapp/templates/userinactive.vm > Log: > XWIKI-5462: Added CSRF tokens to all default templates [snip] > Modified: platform/web/trunk/standard/src/main/webapp/templates/editgroup.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/editgroup.vm 2010-09-18 23:58:17 UTC (rev 31168) > +++ platform/web/trunk/standard/src/main/webapp/templates/editgroup.vm 2010-09-19 12:37:25 UTC (rev 31169) > @@ -71,7 +71,8 @@ > //<![CDATA[ > (function() { > var startup = function() { > - tabl = new ASSTable("$url", 15, "display1", "scrollbar1", "memberstable", displayMembers, true); > + var callback = function(row, i, table) { return displayMembers(row, i, table, form_token) }; > + tabl = new ASSTable("$url", 15, "display1", "scrollbar1", "memberstable", callback, true); I think something is missing here. For me the form_token you pass here to displayMembers is always undefined. Am I missing something ? Thanks, Jerome.

13 years, 11 months

[xwiki-devs] Fwd: [xwiki-notifications] XWiki updates, 4 documents have been modified since 2010/09/17 00:00

by Jerome Velociter

Hi Anca, See below ---------- Forwarded message ---------- From: <notifications(a)xwiki.org> Date: Sat, Sep 18, 2010 at 12:00 AM Subject: [xwiki-notifications] XWiki updates, 4 documents have been modified since 2010/09/17 00:00 To: notifications(a)xwiki.org [snip] > lucaa - (16:59): I would need this to be able to implement the Main.Dashboard page as a dashboard with gadgets > lucaa - (17:01): any opinions? > jvdrean - (17:03): lucaa: what do you need exactly ? having macros in the default enterprise won’t resolve the PR problem right ? > lucaa - (17:03): well, i would like to implement the Main.Dashboard as a dashboard with gadgets > lucaa - (17:04): and since gadgets are macros, the components of the Main.Dashboard (spaces, recent changes, tag cloud) should be macros > lucaa - (17:04): now, they could be java macros, but the problem is that they will be harder to modify > lucaa - (17:04): which I don’t like, in general > lucaa - (17:05): another solution is to use the {{include }} macros and leave them as pages... > lucaa - (17:05): but > lucaa - (17:05): in this case > lucaa - (17:05): they won’t be configurable using macro parameters > lucaa - (17:06): the good part though, is that anyone with edit rights would be able to change them Actually only global visibility (across wikis) needs programming rights. Local wiki visibility only requires the user to have edit on the macro document. See org.xwiki.rendering.internal.macro.wikibridge.DefaultWikiMacroManager#isAllowed We still need to agree we want to have wiki macros in the default wiki. Jerome. [snip]

13 years, 11 months

[xwiki-devs] [proposal] Add a document XWiki.ChangePassword and deprecate the passwd.vm template.

by Caleb James DeLisle

To fix "XWIKI-5469: Change password feature does not use validation" ( http://jira.xwiki.org/jira/browse/XWIKI-5469 ) I would like to add a document for helping the user change their password. passwd.vm is only referenced in one place in XWiki.XWikiUserPreferencesSheet so as a template it is unused unless the Enterprise XAR is installed. To avoid a "rat's nest" dependency graph, I do not like templates to have statically defined document names so I'd like to avoid the method used in registerinline.vm. Also any proposal which moves code from the /templates/ directory to the inside of wikiland has my +1. WDYT? Caleb

13 years, 11 months

[xwiki-devs] [proposal] Add xcontext.dropPermissions() function to take away all programming/script author permissions when called.

by Caleb James DeLisle

I think this function would be useful, I have used code like it to make sure scripts didn't run with PR when they shouldn't and I think it deserves a place in the api. The function doesn't need any special privileges to run, but after it's run, api.Api#hasProgrammingRights will always return false and api.Document#saveAsAuthor will be attempting to save as the guest instead of the real document author. (likewise with getDocumentAsAuthor and deleteAsAuthor) Once permissions have been dropped, they cannot be regained (for the duration of the request.) This depends on another function in api.Api which is package private. String getEffectiveScriptAuthorName() returns the name given by XWikiContext.getDoc().getAuthor() unless dropPermissions() has allready been called or XWikiContext.getDoc() == null in which case it returns the guest username. Why in the old api.Context? I envision in the future a SecurityManager component will exist which distrusts not only script but core java as well. I think the option to drop privileges when unneeded should also be present in the final security manager implementation. Since security managers require a large secure code base to be useful, I am proposing api.Context#dropPermissions() as an interim solution. WDYT? Caleb

13 years, 11 months

Re: [xwiki-devs] [xwiki-notifications] r31124 - platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources

by Vincent Massol

Hi Alex, On Sep 15, 2010, at 8:00 PM, abusenius (SVN) wrote: > Author: abusenius > Date: 2010-09-15 20:00:02 +0200 (Wed, 15 Sep 2010) > New Revision: 31124 > > Modified: > platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm > Log: > XWIKI-5461: Added configuration for CSRF protection > > Modified: platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm > =================================================================== > --- platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm 2010-09-15 17:59:36 UTC (rev 31123) > +++ platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.properties.vm 2010-09-15 18:00:02 UTC (rev 31124) > @@ -267,3 +267,23 @@ > #crypto.passwd.keyDerivationFunctionPropertiesForPasswordVerification = millisecondsOfProcessorTimeToSpend = 200 > #crypto.passwd.keyDerivationFunctionPropertiesForPasswordVerification = numberOfKilobytesOfMemoryToUse = 1024 > #crypto.passwd.keyDerivationFunctionPropertiesForPasswordVerification = derivedKeyLength = 32 > + > +#------------------------------------------------------------------------------------- > +# CSRF token component > +#------------------------------------------------------------------------------------- > + > +#-# [Since 2.5M2] > +#-# Controls whether secret token validation mechanism should be used (to prevent CSRF attacks). > +#-# > +#-# If enabled, all actions requiring "comment", "edit", "delete", "admin" or "programming" rights > +#-# will check that the parameter "form_token" with the value of a random secret token is present > +#-# in the request. > +#-# This feature requires CSRFToken component. I think we could remove this last sentence since the CSRFToken component is bundled with the platform and this message will probably confuse the user who's not going to know how to check if he has this component or not. It'll make him/her ask himself questions, which we don't want IMO. > +#-# > +#-# Valid values: > +#-# 0: Disabled > +#-# 1: Enabled > +#-# > +#-# Default value is 0 > +# core.csrftoken.enabled = 0 I guess we're going to turn it on by default when the implementation is finished? Thanks -Vincent

13 years, 11 months

[xwiki-devs] [discussion] Remove XWatch modules for building standalone distribution

by Anca Luca

Hi devs, I updated locally XWiki Watch trunk to work with XWiki Enterprise 2.3.2 (right now it's 1.8.4 version) and I would like to commit this in the Watch trunk. There is a little issue though, with the modules for building the standalone distribution(s) (distribution, database, installers, web), which need to be handled, for which there are 3 options: 0/ update the distribution related modules to make them compatible with 2.3 and the process is not straightforward due to Watch particularities (this would mean extra work and since I don't know when I will be able to do it, it means not commit right away) 1A/ remove the distribution related modules from the watch trunk and leave it installable as a .xar + component (as described at http://watch.xwiki.org/xwiki/bin/view/Main/Installation#HXWikiWatchoveranex… ) drawback is that users installing it need to edit the web.xml which is not that easy for everyone. 1B/ leave the distribution related modules, just exclude them from the default build since they will fail, until 0/ can be fixed right. I would go for 1B since I think partial update to 2.3 is better than nothing (current version on 1.8.4 is not really useful in most cases) and earlier is better than later. WDYT? Thanks, Anca

13 years, 11 months

[xwiki-devs] [VOTE] Move component related events to their own project

by Thomas Mortagne

Hi devs, For http://jira.xwiki.org/jira/browse/XWIKI-5490 I need to make ObservationManager itself listen to ComponentDescriptorAddedEvent events. There is two issue here: - currently ComponentDescriptorAddedEvent is in the same project than the component manager implemenation which is pretty much the same thing as behing internal since there is no reason to force to depends on a specific implementation of component manager just to listen on some generic events that has nothing to do with it - i can move them to component-api because that would produce a circular dependency with observation project which depends on component-api So the only technical solution I can see is to create a new project with theses events. I propose to name it xwiki-core-component-observation and to move ComponentEventManager from component-api to it too. Note: i took ObservationManager here because it's a core one but a lot of other components will probably have the exact same need to support properly installed/uninstalled extensions WDYT ? -- Thomas Mortagne

13 years, 11 months

[xwiki-devs] XEclipse part of URL to xwiki is hardcoded

by Andriy Vovchyna

Hi, We meet one unpleasant issue with current XEclipse (standalone version <http://forge.objectweb.org/project/download.php?group_id=170&file_id=11944> xwiki-eclipse-rcp-win32-win32-x86-1.2-rc-1.zip) We tried to use XEclipse for our xwiki based application browsing. But when we are trying to find some object stored in a page we are getting error "This data manager is connected to an XWiki that does not support object management." After deep investigation we found problem place in XEclipse code. There is hardcoded "expectation" of "xwiki" string in URL of connection in DataNamager.Connect() http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse. core/src/main/java/org/xwiki/eclipse/core/DataManager.java. public void connect() throws XWikiEclipseException, CoreException { ..... if (serverInfo.getBaseUrl().contains("xwiki")) { ...... } else { /* We are talking to a confluence server */ .... supportedFunctionalities.remove(Functionality.OBJECTS); ..... } .... } So, simple fixing of problem is renaming of web context on xwiki web server (e.g. war file renaming) with adding "xwiki" string. Are there plans to move this "hardcoding" on the connection configuration level (UI options like version selections - xwiki, confluence etc.)? Thanks, Andriy V.

13 years, 11 months

by Marius Dumitru Florea

On 09/15/2010 06:34 PM, mflorea (SVN) wrote: > Author: mflorea > Date: 2010-09-15 17:34:58 +0200 (Wed, 15 Sep 2010) > New Revision: 31119 [snip] > Property changes on: platform/web/branches/xwiki-web-2.4/standard > ___________________________________________________________________ > Added: svn:mergeinfo > + /platform/web/trunk/standard:31118 > > > Property changes on: platform/web/branches/xwiki-web-2.4/standard/src/main/webapp/resources/icons/silk > ___________________________________________________________________ > Deleted: svn:mergeinfo > - > > > Property changes on: platform/web/branches/xwiki-web-2.4/standard/src/main/webapp/resources/js/prototype/prototype.js > ___________________________________________________________________ > Deleted: svn:mergeinfo > - > > > Property changes on: platform/web/branches/xwiki-web-2.4/standard/src/main/webapp/resources/js/scriptaculous > ___________________________________________________________________ > Deleted: svn:mergeinfo > - > > > Property changes on: platform/web/branches/xwiki-web-2.4/standard/src/main/webapp/resources/js/xwiki/accordion/accordion.js > ___________________________________________________________________ > Deleted: svn:mergeinfo > - > > > Property changes on: platform/web/branches/xwiki-web-2.4/standard/src/main/webapp/resources/js/xwiki/chartwizard/chwSampleBarChart.png > ___________________________________________________________________ > Deleted: svn:mergeinfo > - ..do you know how can we get rid of this? It makes the diff almost unreadable. Thanks, Marius

13 years, 11 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2010