xwiki-devs

xwiki-devs@xwiki.org

9399 discussions

[xwiki-devs] [PROPOSAL] Introduce a HAS_PR bit to XWikiDocument

by Caleb James DeLisle

Hello All, It's been a long time since we first discussed hardening XWiki Programming Rights by way of signing scripts in the wiki. As I recall the idea was spawned some time around 2011 in a conversation between me and Denis but it has had difficulty getting off the ground. Alex Busenius and I worked together on an early crypto API for XWiki but we fell short on getting it tied in to the scripting infrastructure. Denis Gervalle picked up the task and redeveloped the crypto API but still had not been able to reach a consensus on how the Signed Scripts should operate. Thanks to James Kettle reporting some arguably-buggy behavior to us, I started thinking maybe there is an easier way. I would like to propose a more simple alternative to see if the community supports it. 1. Introduce a HAS_PR bit to XWikiDocument, if this bit is set then the document has programming rights. 2. Every time a document is saved (at the database level), if the contentAuthor does not have programming rights, we clear the bit. 3. The save action will set the bit if appropriate but other methods of saving a document will not (to prevent bad scripts from tricking users into granting PR). 4. Upon upgrade, we will do a database migration and any document which would have PR now will have the bit set. 5. XAR Exports will contain the value of the bit. The idea of the bit is that we can more clearly express intent, if we are quite sure that not only does the editor have PR but indeed they *want* to grant it to the script, only then do we set the bit. Furthermore the bit is resistant to schenanigans because it is inaccessible to velocity scripting, as is an XObject which could otherwise also be used for this purpose. The bit can reside in the XWD_ELEMENTS field of the xwikidoc table which is intended for this purpose. WDYT? Caleb

10 years

[xwiki-devs] [VOTE] Page Identifier or Page Name?

by Eduard Moraru

Hi, With the latest changes to the create UI [1] we`ve changed (mostly following the agreed-ish proposal [2]) the old "Page Name" label in the create UI to "Identifier" because we believed that having both "Page Title" and "Page Name" on the same page would confuse users and they would not know which one to use. Now, I`d like your quick vote on which one to stick with, since some might consider that "Page Name" is better. One argument for page name (i.e. against "identifier") is that an "identifier" is usually globally unique and in our case this is only true within the same parent. Also, copying a document to a new location and preserving its "identifier" can feel a bit odd to some, since they would expect the need for a new "identifier". Feel free to express your other arguments. Another argument for identifier besides the one already mentioned is that it also better reflects its "technical" nature and should "discourage" users from working with it and they should be using the document's title instead of their needs (both in the create step and further along). Here's my +1 for "identifier". WDYT? Thanks, Eduard ---------- [1] http://jira.xwiki.org/browse/XWIKI-12231 [2] http://design.xwiki.org/xwiki/bin/download/Proposal/NestedCreate/createTitl…

10 years

[xwiki-devs] [Proposal] Postpone the 7.2M3 release to Thursday 27th

by vincent＠massol.net

Hi devs, Today was supposed to be the 7.2M3 release but we’re late. We still have 12 outstanding issues that we’d like to see fixed for 7.2M3: http://jira.xwiki.org/issues/?jql=labels%20%3D%20NestedSpaces%20and%20resol… I propose to move the release to Thursday 27th. WDYT? Note that I’ve gone through all issues related to NS and put some fix versions. We now have 20 open issues for 7.2RC1: http://jira.xwiki.org/issues/?jql=labels%20=%20NestedSpaces%20and%20resolut… And 14 for 7.3M1 and later: http://jira.xwiki.org/issues/?jql=labels%20=%20NestedSpaces%20and%20resolut… Thanks -Vincent

10 years

Re: [xwiki-devs] [Proposal] Best practice: use References in JS code

by vincent＠massol.net

On 27 Aug 2015 at 10:34:17, Caleb James DeLisle (cjd@cjdns.fr(mailto:cjd@cjdns.fr)) wrote: > Ahh ok, +1 to explosing the absolute cannonical reference, however I will point out > that use of "this" in javascript is dangerous and should be avoided. It looks like > you're attaching it to the global namespace (aka window) but "this" has different > meanings depending on where you are in the code. Better XWiki.doc.reference or similar IMO. I was referring to modifying this existing code: XWiki.Document = Class.create({ /** * Constructor. All parameters are optional, and default to the current document location. */ initialize : function(page, space, wiki) { this.page = page || XWiki.Document.currentPage; this.space = space || XWiki.Document.currentSpace; this.wiki = wiki || XWiki.Document.currentWiki; }, so that instead (or rather in addition to not break backward compat), we can also pass a full reference. Thanks -Vincent > Thanks, > Caleb > > > On 27/08/15 10:23, vincent(a)massol.net wrote: > > > > > > > > > > > > On 26 Aug 2015 at 18:23:42, Caleb James DeLisle (cjd@cjdns.fr(mailto:cjd@cjdns.fr)) wrote: > > > >> A bit late to the game but can't we pass a cannonicalized absolute string to the JS ? > >> eg: wiki:space.sp\.ace.sp\\ace.page > >> and then just warn the js devs that they should use functions to manipulate the > >> string representation instead of hacking it manually ? > > > > This is indeed my original proposal in the first mail: > > > > “[…]I’m proposing to change our best practice and instead to pass a full reference, as in: > > > > this.sourceReference = XWiki.Model.resolve(this.element.down('.metadata .source').innerHTML, XWiki.EntityType.DOCUMENT); > > “ > > > > Thanks > > -Vincent > > > >> That's what nodejs does for URLs and I will say without reservation that the > >> user-friendlyness of their their URL parsing API is not even compatible to the > >> disaster that was java.net.URL. > >> > >> > >> On 26/08/15 17:36, Guillaume "Louis-Marie" Delhumeau wrote: > >>> I don't really understand the solution 2. > >>> > >>> We already have an EntityReference class in entityReference.js, with a > >>> string serializer and a string parser. > >>> > >>> If we use a JSON format to describe a reference, we will still have to > >>> parse it to create an EntityReference object, and this parser does not > >>> exist yet. > >>> > >>> So what is the benefit? > >>> > >>> I only see drawbacks: > >>> - A JSON reference is a lot more verbose. > >>> - From the java side, we need to serialize the reference to a JSON > >>> representation which is probably more costly than serializing to a string. > >>> - We use string representations in a lot of places, and suddenly we should > >>> use JSON but only when we do JavaScript... > >>> > >>> So +1 for the solution 1. > >>> > >>> In any case, it seems a good idea to use references in JS code. > >>> > >>> Thanks, > >>> Guillaume > >>> > >>> 2015-08-06 14:25 GMT+02:00 Eduard Moraru : > >>> > >>>> I agree with Thomas that it would be best to use EntityReference -> JSON as > >>>> much as possible (when passing the reference from velocity to javascript, > >>>> server-side), however, man times when you need a reference you also end up > >>>> building a new reference (on the client-side, i.e. javascript) so we can`t > >>>> really avoid having a strong javascript EntityReference API + > >>>> serializer/resolver. > >>>> > >>>> Also, making a HTTP request from JS to resolve a string reference on the > >>>> server (and getting a JSON result) is not really an option IMO (specially > >>>> if you do that a lot). > >>>> > >>>> So +1 to using reference in javascript code. > >>>> > >>>> Thanks, > >>>> Eduard > >>>> > >>>> On Thu, Jul 30, 2015 at 11:50 AM, Thomas Mortagne < > >>>> thomas.mortagne(a)xwiki.com > >>>>> wrote: > >>>> > >>>>> Direct EntityReference -> JSON serialisation would provide a strong > >>>>> standard (we already have tool to make sure we never break > >>>>> EntityReference) and it would make JS and Java sides more consistent. > >>>>> Now In some cases we will still need to support parsing a String > >>>>> reference in JS I think. > >>>>> > >>>>> On Thu, Jul 30, 2015 at 10:38 AM, vincent(a)massol.net > >>> > >>>>> wrote: > >>>>>> Hi Marius/all, > >>>>>> > >>>>>> On 30 Jul 2015 at 10:26:49, Marius Dumitru Florea ( > >>>>> mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) > >>>>> wrote: > >>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> Another option could be to pass a JSON serialization of the reference. > >>>>>>> Thomas has recently fixed some issues that were preventing JSON > >>>>>>> serialization of an entity reference. It should work fine now: > >>>>>>> > >>>>>>> $jsontool.serialize($documentReference) > >>>>>>> > >>>>>>> should produce something close to: > >>>>>>> > >>>>>>> { > >>>>>>> name: 'Page', > >>>>>>> type: 'DOCUMENT', > >>>>>>> parent: { > >>>>>>> name: 'Space2', > >>>>>>> type: 'SPACE', > >>>>>>> parent: { > >>>>>>> ... > >>>>>>> } > >>>>>>> } > >>>>>>> } > >>>>>>> > >>>>>>> It's more verbose obviously. For this we need to modify a bit > >>>>>>> entityReference.js though, because it expects the entity type to be an > >>>>>>> int. > >>>>>> > >>>>>> Indeed there are only 2 global solutions: > >>>>>> * Solution 1: Pass the seralized String reference and have the js > >>>>> perform the resolve. This also means that the java code may need to do a > >>>>> serialize. So this has the drawback of doing a serialize + resolve. It > >>>> has > >>>>> the advantage of being a one-liner from JS. > >>>>>> * Solution 2: Pass the individual elements of a reference so that the > >>>> JS > >>>>> doesn’t have to call resolve. This can be done in several ways: > >>>>>> > >>>>>> option 1: > >>>>>> > >>>>>> > > > >>>>>> > > wiki > > > >>>>>> > > page > > > >>>>>> > > > >>>>>> > > space1 > > > >>>>>> > > space2 > > > >>>>>> > > > >>>>>> > > > >>>>>> > >>>>>> option 2: > >>>>>> > >>>>>> The JSON you suggest above. However, how would the java code pass this > >>>>> into HTML? Inside a tag’s text, as in: > >>>>>> > >>>>>> > > > >>>>>> … json here?... > >>>>>> > > > >>>>>> > >>>>>> Inside a > > _______________________________________________ > > 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

10 years

[xwiki-devs] [Proposal] Best practice: use References in JS code

by vincent＠massol.net

Hi devs, In the past we use to pass the wiki, space and page as 3 variables to JS code. For example in dashboard.js we currently have: this.sourcePage = this.element.down('.metadata .sourcepage').innerHTML; this.sourceSpace = this.element.down('.metadata .sourcespace').innerHTML; this.sourceWiki = this.element.down('.metadata .sourcewiki').innerHTML; Now that we need to handle Nested Spaces, it’s more complex and I’m proposing to change our best practice and instead to pass a full reference, as in: this.sourceReference = XWiki.Model.resolve(this.element.down('.metadata .source').innerHTML, XWiki.EntityType.DOCUMENT); More generally the idea would be to do the same as we do in Java code, i.e. to start stopping passing several parameters to functions and instead to use XWiki.EntityReference (or XWiki.DocumentReference, etc). For example for dashboard.js this allows to replace: var link = new Element('a', {'href' : this.sourceURL}); link.update(this.sourceWiki + ':' + this.sourceSpace + '.' + this.sourcePage); With: var link = new Element('a', {'href' : this.sourceURL}); link.update(XWiki.Model.serialize(this.sourceReference)); WDYT? Thanks -Vincent

10 years

[xwiki-devs] [Proposal] Drop the space administration navigation element and use the breadcrumbs instead

by Eduard Moraru

Hi, Initially, we wanted to update the administration UI to support nested spaces and, in particular, to replace the select input for navigating between space administrations with a tree. However, it now seems that dropping it completely is a better alternative and that we could consider the administration mode as either part of a Nested Document's administration mode or part of the wiki's administration mode. We really don`t need to switch between one-another, like we don`t switch between pages in edit mode. Any navigation we might need should be handled by the breadcrumbs and the new (to come) tree displayer [1]. The wiki administration is accessible from the drawer [2] component. Please see the issue [3] for some more details:. Here's my +1. Thanks, Eduard P.S.: I`m not really sure if that feature was ever really used that much. ---------- [1] http://design.xwiki.org/xwiki/bin/download/Proposal/NestedTreeLocation/Sol5… [2] http://jira.xwiki.org/browse/XWIKI-12189 [3] http://jira.xwiki.org/browse/XWIKI-12172

10 years

[xwiki-devs] Export xwiki pages to Sharepoint (2013)

by Sophie Gendron

Hi, we need to export a big amount of xwiki pages (xwiki 2.7.1) to Sharepoint 2013 pages. Does somebody know if some tools exist to do that ? Thank you -- Accédez aux meilleurs tarifs Air France, gérez vos réservations et enregistrez-vous en ligne sur http://www.airfrance.com Find best Air France fares, manage your reservations and check in online at http://www.airfrance.com Les données et renseignements contenus dans ce message peuvent être de nature confidentielle et soumis au secret professionnel et sont destinés à l'usage exclusif du destinataire dont les coordonnées figurent ci-dessus. Si vous recevez cette communication par erreur, nous vous demandons de ne pas la copier, l'utiliser ou la divulguer. Nous vous prions de notifier cette erreur à l'expéditeur et d'effacer immédiatement cette communication de votre système. Société Air France - Société anonyme au capital de 126 748 775 euros - RCS Bobigny (France) 420 495 178 - 45, rue de Paris, Tremblay-en-France, 95747 Roissy Charles de Gaulle CEDEX The data and information contained in this message may be confidential and subject to professional secrecy and are intended for the exclusive use of the recipient at the address shown above. If you receive this message by mistake, we ask you not to copy, use or disclose it. Please notify this error to the sender immediately and delete this message from your system. Société Air France - Limited company with capital of 126,748,775 euros - Bobigny register of companies (France) 420 495 178 - 45, rue de Paris, Tremblay-en-France, 95747 Roissy Charles de Gaulle CEDEX Pensez à l'environnement avant d'imprimer ce message. Think of the environment before printing this mail.

10 years

[xwiki-devs] [Contrib] Check the PR on the video macro

by Mohamed Boussaa

Hello devs, I created a PR on the Video macro ( https://github.com/xwiki-contrib/macro-video). I added the possibility to play a video attachment using Video.js library ( http://www.videojs.com/). I invite you to check the PR. https://github.com/xwiki-contrib/macro-video/pull/1 Thanks, Mohamed

10 years

[xwiki-devs] [Iteration][UX] Nested: Page Actions

by Ecaterina Moraru (Valica)

Hi devs, This iterations covers page actions: create, delete, rename, copy, move. Also it contains a proposal on the tree displayer inside page actions. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions Thanks, Caty

10 years

[xwiki-devs] The future of the Spaces macro in the context of Nested Spaces/Documents

by Marius Dumitru Florea

Hi guys, The wiki home page displays, by default, the list of spaces that exist in the wiki (hidden or not, depending on the user profile settings). This is done using the http://extensions.xwiki.org/xwiki/bin/view/Extension/Spaces+Macro . As we have started to work on adding support for nested spaces/documents, we need to review the purpose of this macro. Is it still relevant to display a list of spaces when there is a tree hierarchy? It only makes sense if you want to display just the list of direct children of a given node. I see the following options: (1) Display the list of top level nodes (space/document) on the wiki home page. No tree. The rationale is that loading the tree (even if done lazy) is more expensive that displaying a static list of links. For this we can extend the Spaces Macro with a parameter to specify the parent node. When this parameter is not specified the macro will list the top level nodes. (In the context of nested documents we could introduce a new macro Document List instead) (2) Display the tree hierarchy on the wiki home page, using http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro .Of course, the tree will be lazy loaded, and only the top level nodes are displayed initially. If we do this then we can probably deprecate the Spaces Macro and advice the users to use the Document Tree Macro instead. WDYT? Thanks, Marius

10 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs