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

[xwiki-devs] Create Object by Default with a new Page

by Matthias Wegner

Hi, i didnt find a documentation for creating an XObject to a Wiki-Page when a new Page is created. I think it must something like that, but who do i place it? EntityReference entRef = doc.resolveClassReference("Space.WhateverClass"); int objectIndex = doc.createXObject(entRef, getXWikiContext()); BaseObject o = doc.getXObjects(entRef).get(objectIndex); I know i can create a new object and page by velocity (http://extensions.xwiki.org/xwiki/bin/view/Extension/Create+Page+With+Object), but i want to add a default and predefined object when a user add a new page. Is there a way to do this from plugin-side? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Create-Object-by-Default-with-a-new-Page-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 10 months

2
5
0 0

[xwiki-devs] Object Handling

by Matthias Wegner

Hello, i programmed some Objects which can be related to any page. Then i draw a graph (see an example at http://jsfiddle.net/7aMBr/3/). I programmed it as a service which creates a html5-canvas and the javascript for the drawing (Here a screen http://s1.directupload.net/file/d/3421/3a4twrov_jpg.htm). Is is done with {{velocity}} $services.graph.calculate(640, 320, "Hierarchic") {{/velocity}} I defined some type-classes which can predefine the node or edge style, for example the icon or the arrow layout (here a preview http://s14.directupload.net/file/d/3421/hxkwe5bs_jpg.htm). Here now my questions: 1. I use a defined id which uses Space.PageName.NodeLabel (ObjectUUID). This references the Graph-Elements to others or the types. Everything works fine, but now i realised that the change of the label in the object forces an error in the ClassBuilder because all depended elements did't realize the change. Is there a objectchange listener i can use for every change? 2. I programmed also a remove- and create-method in the ScriptService. As you can see in one picture i defined a custom menubar. So i want to create a link which can start a service. Is that possible? {{velocity}} $services.graph.removeNode("Main.Test.N2 (94c5fe2d-a92f-413e-ba1d-efc35bb7f84f)") {{/velocity}} Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Object-Handling-tp7587724.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 10 months

1
1
0 0

Re: [xwiki-devs] [Reminder] BFD#41 (RESULT)

by Thomas Mortagne

Forgot to send that mail, see http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+41 for the result. On Thu, Oct 24, 2013 at 8:38 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > Hi devs, > > Today is Bug Fixing Day 41. > > We're currently at 3387 bugs created over 1500 days vs 3366 closed, ie > 21 bugs behind: > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 > > Good luck everyone ! > > Here's the BFD#41 dashboard to follow the progress during the day: > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11791 > > -- > Thomas Mortagne -- Thomas Mortagne

11 years, 10 months

1
0
0 0

[xwiki-devs] [Proposal] From Signed Scripts to Signable Macros

by Denis Gervalle

Hi devs, As you may know, I have taken over the work done by Thomas Delafosse regarding security in XWiki, and in particular, a very good idea initially proposed by Alex Busenius in the early days of the security mailing list in June 2010, replacing PR by Signed Scripts ! A lot of discussions had already been done around the subject, mainly on the security mailing list and Thomas D. has written a very interesting PoC that demonstrate the feasibility and also some drawbacks and issues with our initial concept. I have therefore reviewed all those information, and I have try to draw a conclusion that I am now sharing with you in an open design proposal: http://dev.xwiki.org/xwiki/bin/view/Design/SignedScripts I know you are all really busy with your stuffs and that this is not a short document, but introduction of this change in XWiki will not be a small event, and it may become really difficult to properly evolve if we made it wrong. So I strongly insist that all of you read this proposal and comment on any point that looks odd. For those who would not be at ease with cryptographic matters, a small cryptographic introduction is also included, so (I hope) you may understand the document. There are still some open points in the proposal, marked TODO, on which I would be please to receive your suggestions. I will continue to evolve the proposal based on your comments, until we reach an acceptable solution, but I also start the implementation. Thanks in advance for your time, -- Denis Gervalle SOFTEC sa - CEO

11 years, 10 months

1
0
0 0

[xwiki-devs] Questions about migration path when documents or macros are renamed

by Guillaume "Louis-Marie" Delhumeau

Hi! I have two jira issues that I need to fix for 5.3: * http://jira.xwiki.org/browse/XWIKI-9558 - Rename {{workspaces /}} gadget to {{wikis /}} * http://jira.xwiki.org/browse/XWIKI-9491 - Rename "WorkspaceInformationPanel" to "WikiInformationPanel" The implementation is very trivial. In both cases I just rename a document, and in one case I only change the field "name" of the WikiMacro. But how do we handle upgrade? A: If someone has used the {{workspaces /}} macro in her content, she will not see the expected result anymore. B: If WorkspaceInformationPanel is used in a layout, should we automatically update this layout to use WikiInformationPanel? Do we consider we should let the user fix this issues herself, or should we provide an automatic solution to that? If so, how could we do? Thanks for your help, Louis-Marie.

11 years, 10 months

3
2
0 0

[xwiki-devs] [Discussion] Should technical pages hide the bottom tabs?

by Sergiu Dumitriu

Hi devs, For content pages, the bottom tabs (comments, attachments, history, information) are very useful features. But does it make sense to keep those active for very technical pages? For example, when viewing details about a tag, (Main/Tags?do=viewTag), why should people be allowed to comment? They might wrongly think that they're commenting on a tag, but that's just one complex page that handles almost everything about tags, so a comment like "this tag has a typo" doesn't help at all. Other pages should have no bottom tabs as well: user directory, blog category management, the whole scheduler space, share by email... While the homepage is a technical page (by default), it does make sense to leave the comments active, since it's the entry point for every user (although I think that the messaging system is a better way to send global messages). IMO, the advantage is that we're hiding actions that are rarely useful, but could be misused. The disadvantage is that we're breaking the universality of the UI. I'm +1 for hiding, fewer mis-usable features is always better. -- Sergiu Dumitriu http://purl.org/net/sergiu/

11 years, 10 months

7
11
0 0

[xwiki-devs] [Reminder] BFD#41

by Thomas Mortagne

Hi devs, Today is Bug Fixing Day 41. We're currently at 3387 bugs created over 1500 days vs 3366 closed, ie 21 bugs behind: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Good luck everyone ! Here's the BFD#41 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11791 -- Thomas Mortagne

11 years, 10 months

1
0
0 0

[xwiki-devs] Need Release Manager for 5.3 ASAP

by Vincent Massol

hmm seems we've missed the release date yesterday for 5.3M1… :( We need a Release Manager to step forward for 5.3 ASAP. Any volunteer? Reminder: here are the scores so far for RMs: http://dev.xwiki.org/xwiki/bin/view/Community/ReleaseManagerRoster Note that on http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/WebHome we have: * Marius: 11 * Thomas: 11 * Vincent: 11 * Caleb: 6 * Edy: 4 * Sergiu: 1 * Jerome: 1 * Denis: 1 * Fabio: 1 We need to release ASAP. Thanks -Vincent PS: I'm on holiday starting tomorrow till the end of the week.

11 years, 10 months

2
2
0 0

[xwiki-devs] Regarding highlighting the text

by Prachi Maheshwari

Hey everyone, I have created various spaces/apps and their different forms within. Now when users fill in the forms, I want the respective titles to be in different text format as compared to text. May be highlighted, Different font, etc. I need to change it in the class or template or sheet files of that space. Can anyone please help and tell me where can I do such things. Or if there is any help related to it online. Thank you, Prachi

11 years, 10 months

1
0
0 0

Re: [xwiki-devs] [Proposal] Wiki API

by Guillaume "Louis-Marie" Delhumeau

Hi 2013/10/17 Eduard Moraru <enygma2002(a)gmail.com> > Hi, > > On Wed, Oct 16, 2013 at 12:18 PM, Guillaume "Louis-Marie" Delhumeau < > gdelhumeau(a)xwiki.com> wrote: > > > Hi Edy > > > > > > 2013/10/11 Eduard Moraru <enygma2002(a)gmail.com> > > > > > Hi, > > > > > > On Thu, Oct 10, 2013 at 11:46 AM, Guillaume "Louis-Marie" Delhumeau < > > > gdelhumeau(a)xwiki.com> wrote: > > > > > > > Hi Eduard, > > > > > > > > > > > > 2013/10/9 Eduard Moraru <enygma2002(a)gmail.com> > > > > > > > > > Hi, > > > > > > > > > > On Tue, Oct 8, 2013 at 4:41 PM, Guillaume "Louis-Marie" Delhumeau < > > > > > gdelhumeau(a)xwiki.com> wrote: > > > > > > > > > > > Thanks for all your answers. > > > > > > > > > > > > I continue to iterate until we reach something nice. You can see > > the > > > > work > > > > > > there: > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/gdelhumeau/xwiki-platform/tree/feature-wiki-properties-g… > > > > > > > > > > Side note: I`ve noticed that you have 2 branches where you work, both > > > feature-wiki-properties-group that you`ve linked to now and > new-wiki-api > > > that you`ve linked to in the initial post. Please use only one since > it`s > > > already quite confusing and hard to follow. > > > > > > > > > > > > > > > > > > I think my mistakes until now was the fact that I didn't want to > > > > deviate > > > > > > too much from the wiki-descriptor module of Vincent. But now, I > > > > > understand > > > > > > it is better to make something new. > > > > > > > > > > > > Now, the API has a complete javadoc. > > > > > > > > > > > > = Modularity = > > > > > > == Reduce responsibility == > > > > > > > > > > > > The first advantage of creating several modules is to reduce the > > > > > > responsibility of each module. I want one API to handle the wiki > > > > creation > > > > > > and basic management, one API for the template feature (which > could > > > be > > > > > > optional as soon as we have flavors), > > > > > > > > > > > > > > > This transition will most certainly require some considerable > > > refactoring > > > > > and possibly some method deprecating, for which we already have a > > > > strategy, > > > > > at least for the workspaces UI. > > > > > > > > > > > > > Currently, the workspaces UI is a kind of a hack. > > > WorkspaceManager.Install > > > > create a new template where we install a standard XAR UI + Workspace > > > > Template Feature (that overwrites some standard pages) + delete some > > > pages > > > > that we don't need, etc... It forces us to ask the user to create > > > > workspacetemplate first, it does not work out of the box. > > > > > > > > > Neither does wiki manager work out of the box. The current technical > > > limitations require that the user first creates a template wiki that is > > > used in the creation of new wikis/workspaces. > > > > > > > Yes, and it is bad, IMO. Today, we have the Distribution Wizard which is > > launched the first time we go to the wiki. There is no reason to force > > having a template anymore. > > > > > > > > > > > > > > And we need to > > > > have 2 distinct XARs to handle the 2 use-cases: farm and workspaces. > It > > > is > > > > definitively not clean. > > > > > > > > When talking with Vincent about this, we decided that it would be > > better > > > to > > > > create a unique XAR that handle the 2 use-cases. > > > > > > > > > But again, this does not fix the "out-of-the-box" issue. > > > > > > > > > > It will just look at the > > > > wiki configuration to know if we have local users or not, what is the > > > > membership type of the wiki, etc... > > > > > > > > > > The idea was that an admin could come with his own customized XAR that > > > would then be "adapted" to be used as a workspace template, if the > admin > > > did not already do that. It was not desired that the user be limited to > > the > > > standard XE xar, since that would have been rather easy to implement > and > > > automatically "install". > > > > > > > > About the ability to create a template that is automatically "adapted" to > > be a workspace template, I have the feeling that there are more drawbacks > > than benefits: > > - it's too complex > > - it is useless for the majority of users > > - the wiki creation does not work out of the box > > - we have to write documentation about this... > > - If a user wants to create his own customized XAR, he can start from the > > default we provide > > > > You also need to be aware that when this application (workspaces) was > developed, it was to be developed as an addon. Even the minor and almost > necessary "hacks" (read "IFs") that were added into platform for the top > menus were frowned upon even to this date. Stating that the current > implementation is not optimal when viewing this no longer as an added > feature, but a basic and integrated feature is, basically, comparing apples > to oranges. > > My only concern is that, whatever approach we chose, we preserve the > ability of an admin to provide his own, customized, workspace template, > either through a xar, a flavour or whatever, just as long as he still has > the means to build it and deploy it (without having to publish it to a > public extension repository, since it can be private stuff). > I understand. That is why I still have the notion of "wiki templates". An admin can create a new template, customize it, and propose it at the wiki creation. > > > > > > > > > So, I apologize to not having talk here about that. I think that we > > > should, > > > > indeed, refactor a lot of things to have a very clean multiwiki > feature > > > in > > > > 5.3. > > > > > > > > > > > > > > > > > > Basically, you`d right now be using a > > > > $services.wiki.createWiki('newWiki') > > > > > to create the wiki followed by a > > > > > $services.wikiTemplate.apply('someWikiTemplateName', 'newWiki') to > > > > > initialize the wiki with content. > > > > > When we`d have flavours, you`d probably follow the creation step > > with a > > > > > $services.extension.install('someFlavourExtensionID', 'newWiki') > to > > > > > initialize the wiki with the content of a flavour extension. > > > > > We`d probably also want to keep the option of importing the content > > > from > > > > a > > > > > XAR, so that might be a option too. > > > > > > > > > > So this wikiTemplate service would probably contain some methods > > like: > > > > > - create/convert (since the argument would probably be a wikiID to > > mark > > > > as > > > > > template. The content of that wiki would have previously be > > initialized > > > > > from an extension of from a XAR) > > > > > > > > > > > > > I have proposed setTemplate(boolean template); > > > > > > > > > > Maybe setTemplate(String wikiID) as in, > > > $services.wikiTemplate.setTemplate('someWiki') > > > > > > ...or even setTemplate(String wikiID, boolean isTemplate) to avoid > > having a > > > second removeTemplate(String wikiID) method. > > > > > > > Yes, I like this one. > > > > > > > > > > > > > > > > > > > > > > > - list/getAll (wikis marked as templates) > > > > > - delete/revert (remove the template mark, resulting in a regular > > wiki > > > > once > > > > > again) > > > > > - isTemplate (wikiID) > > > > > - apply (as seen above, copy the content to an empty wiki) > > > > > > > > > > > > > I was thinking about createWikiFromTemplate() instead, but maybe it > > does > > > > not provide enough flexibility. > > > > > > > > > > Didn`t you mention something earlier about separation of concerns? :) > > > > > > > > I see the template feature as an helper for the creation of a wiki. We > > don't need template for anything else than the creation of a wiki. So it > > does not disturb me to have createWikiFromTemplate() (which internally > call > > createWiki). > > > > > > > > > > > > > > > > > > > > > Side Note1: It could get a bit ugly fast when having to list wikis. > > > What > > > > do > > > > > you do with templates? What do users see, what do admins see if you > > > plan > > > > to > > > > > have a single view(UI) for everything? Probably 2 UIs would fit > best > > > > > (similar to what we have not with WikiManagerUI and WorkspacesUI). > > The > > > > > WikiManager part would probably go in the main wiki's > administration > > > (for > > > > > admins) and the WorkspacesUI part would be in the main wiki's > > WikiIndex > > > > > (for users). > > > > > > > > > > > > > That is an interesting question. I did not think that much about the > UI > > > > until now. I wanted to have a clean API first. > > > > > > > > > > > I propose, with Caty: > > * 1 UI which is the "Wiki Directory" that display only wikis that users > can > > use > > > * 1 UI, in the administration, to manage templates only. > > > > > > > > > > > > > > > > > > > Side Note2: While thinking about templates, I thought that we might > > > need > > > > > some "copy" and "rename" methods for the WikiManager API, since > they > > > > might > > > > > operations that the user might want to perform without having to > use > > > > > templates or some other weird operations. > > > > > > > > > > > > > - Rename would be hard to implement (copy the wiki and delete it?) > > > > > > > > > > No, just rename the database and the descriptor. Is there any > limitation > > to > > > that? > > > > > > > > There is nothing in the XWikiStoreInterface to rename a database. > > > > - DB2 does not support the database renaming: > > http://bytes.com/topic/db2/answers/185194-i-want-rename-table-schema > > - Derby neither: > > http://apache-database.10148.n7.nabble.com/Rename-Schema-td95708.html > > - Neither oracle: > > > > > http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3002019… > > > > But it's OK for PostGreSQL, MySQL and HSQLDB. > > > > So, if we want to rename the database from A to B, we can: > > - create the database B > > - import all the data from A into B > > - delete the database A. > > > > > We had the same problem with renaming documents. We did not take it into > account in the initial API/model and then we had to fake it with a > delete+remove. If we have to do the same for wikis, fine, but IMO we have > to include these common sense operations or we will hit them in the future > and we will be forced to do even dirtier things, or worse, leave the user > to have to do them. > > Also, implementation would not be hard (we already do wiki copy and > delete). We`d just need to be careful :) > OK. > > > > > > > > - What "copy a wiki" means? Should we copy the history of every pages > > > too? > > > > Should we copy the recycle bin? I did not want to provide a copy > > feature > > > > because of these questions. The template feature actually does a copy > > > > operation but with its own opinion concerning this aspects : no > history > > > > copied, no recycle bin. > > > > > > > > > > 1-to-1 copy of the source wiki. This means everything. > > > > > > Sure, there might be some applications that use custom mapping and add > > some > > > tables to the source database that might not be copied in the process. > > But, > > > if we have no way of detecting and copying this data, I think it's not > a > > > bit problem. History and recycle bin are core notions of which we have > > full > > > control so they should not be an issue. > > > > > > > Then we need an option to not copy history and recycle bin, because when > > you create a wiki from a template, you don't care about deleted documents > > and the history. Only the template creator needs them. > > > > > > > > > > Anyway, since we`re reviewing these processes and thinking about them > > now, > > > maybe we should do it right. Copy and Rename are basic operations that > > > should not miss from any data model. > > > > > > I agree. > > > > > > > We should *at least* include them in > > > the API and implement them when time allows (and expose them in the UI > > when > > > implemented). It would be a shame to have yet another half baked API. > > > > > > > Can we create an implementation with missing features? > > > > We do things iteratively. I don`t see why we can`t apply that to > implementations of an API, as long as we don`t have any UI using it, thus > risking to crash. > OK. Thanks, Louis-Marie.

11 years, 10 months

1
0
0 0

Re: [xwiki-devs] [Reminder] BFD#40 (RESULT)

by Thomas Mortagne

Forgot to send that mail, see http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+40 for the result. On Thu, Oct 17, 2013 at 8:19 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > Hi devs, > > Today is Bug Fixing Day 40. > > We're currently at 3404 bugs created over 1500 days vs 3376 closed, ie > 28 bugs behind: > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 > > 28 is doable so lets see what we got ;) > > Here's the BFD#40 dashboard to follow the progress during the day: > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11790 > > -- > Thomas Mortagne -- Thomas Mortagne

11 years, 10 months

1
0
0 0

[xwiki-devs] Get rid of xwiki-trunks

by Thomas Mortagne

Hi devs, Just seen that https://github.com/xwiki/xwiki-trunks is broken since we moved XEM. I don't use it and I'm pretty sure most of you don't use it either so I propose to get rid of it. I never found it really useful so I propose to stop maintaining it. WDYT ? -- Thomas Mortagne

11 years, 10 months

6
14
0 0

[xwiki-devs] [Idea] Comparison feature for Extension Manager UI

by Vincent Massol

Use case: Be able to compare an existing wiki with an extension. For example compare my wiki with xwiki-enterprise-common-ui to see the differences I have in my wiki. Implementation idea: We could imagine an extra action in the EM UI: when listing an Extension, you can now Install/Remove/Upgrade. We could imagine a secondary option to "Compare". Clicking it would compare the extension with the current pages in the wiki, showing diffs for all pages contained in the extension vs pages on the wiki. For example if you pick the Blog UI, the "Compare" button would compare the blog app in the listed version with the current blog pages in the wiki. And if you select the xwiki-enterprise-common-ui extension it'll do the same but comparing a lot more pages. We could also imagine listing pages available in the wiki but not listed in the extension selected. WDYT? Real use case: I'd like to verify on xwiki.org wikis their state and what differences they have with the default "distribution". It would also be interesting and useful for us to verify the DW works well and doesn't do anything strange. And it would allow building trust with users. Subsidiary question: how hard would it be to implement this? Thanks -Vincent

11 years, 11 months

1
0
0 0

[xwiki-devs] Query for self-defined objects

by Matthias Wegner

Hello, i programmed a class /Node/ which is here used as /n/ and a class /NodeType/ which is reference by Node. In the ClassBuilder from Node i use this method to get the NodeType try { List<XWikiDocument> docs = getXWikiContext().getWiki().getStore().searchDocuments(" ", getXWikiContext()); for (XWikiDocument xWikiDocument : docs) { List<BaseObject> objects = xWikiDocument.getXObjects(xWikiDocument.getDocumentReference()); if (objects != null) { for (BaseObject bo : objects) { if (bo.getName().contains("QuarXs.NodeTypeClass")) { DefaultNodeType nt = new DefaultNodeType(); nt.setName(bo.getStringValue("name")); nt.setGuid(bo.getGuid()); n.setType(nt); } } } } } catch (Exception ee) { System.out.println("Error: " + ee); } To test this i defined a class from a wiki-page named "NodeTypeClass" in Space "QuarXs". But now i used /AbstractMandatoryDocumentInitializer/ to initialize everything. The Initialization works fine and looks great, but now my upper method is not working. I can define objects and reference to NodeType, but can't find objects of type "NodeType" with the upper method. Can you give me a hint? I checked it with {{groovy}} import org.rogatio.quarxs.Node; for (Node node : services.component.getComponentManager().getInstanceList(Node.class)) { println("* "+node.getPrettyId() ) println("** "+node.getType()) // gives back null. Reason: No BaseObject of class "QuarXs.NodeTypeClass" found with upper method // println("** "+node.getType().getName()) // worked fine when i made the classes by hand } {{/groovy}} If you like i post my code. Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Query-for-self-defined-objects-tp7587586.… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 11 months

2
2
0 0

[xwiki-devs] [Proposal] Add a wiki filling event

by Guillaume "Louis-Marie" Delhumeau

Hi devs! When we create a subwiki from a template, we import a lot of documents that are then displayed in the Activity Stream, and it should not (cf: http://jira.xwiki.org/browse/XWIKI-9489 ). Following the Sergui's advice, I have created a Pull Request that create a new interface called TransientEvent. A transient event means an event that should not be seen by users but that the system can care about it. Moreover, coupled with begin/end events, it means that every events related to a transient event should not be shown to users neither. I don't really like this name because, in my opinion, all events are ephemerals. But at least this interface can solve this problem. But we don't want to hide the fact that a new wiki has been created. Displaying a message concerning the creation of a wiki is a valid use-case. What we want to hide is the import of a lot of documents during the "initialization" phase of that wiki. That is why I propose to create a new event: WikiFillingEvent, which will be transient. It will be associated to a begin/end events so every document creation during this filling process will be hidden in the AS. I'm not sure about the name, but I think we need it. WDYT? LM

11 years, 11 months

3
3
0 0

[xwiki-devs] [QA] Feedback for 5.3M1

by Manuel Smeria

Hi devs, XWiki 5.3M1 is scheduled to be released the next Monday. I'll go through the list of bugs fixed for it and also take a look at the new features. Besides these, do you want something else tested as well ? Thank you, Manuel

11 years, 11 months

1
0
0 0

[xwiki-devs] [Reminder] BFD#40

by Thomas Mortagne

Hi devs, Today is Bug Fixing Day 40. We're currently at 3404 bugs created over 1500 days vs 3376 closed, ie 28 bugs behind: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 28 is doable so lets see what we got ;) Here's the BFD#40 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11790 -- Thomas Mortagne

11 years, 11 months

1
0
0 0

[xwiki-devs] [Proposal] Roadmap for XWiki 5.3

by Vincent Massol

Hi devs, Here's some proposal based on discussions with various committers (those from XWiki SAS) and based on our past roadmap leftovers: Content ======= * We need to ensure the SOLR Search is working perfectly well so that it can replace our Lucene search. We've recently found a big limitation (http://jira.xwiki.org/browse/XWIKI-9508) which prevents it from being used in the same way the Lucene search was used before. In addition there are some improvements to make to it (the list of jira issues need to be reviewed). I've discussed with Marius and he's ok to work on this for 5.3. * Continue working on the workspaces integration by default in XWiki Enterprise - Guillaume Delhumeau - integrate creation of "farm mode wiki" (i.e. local users allowed) - internal refactoring to move all wiki-related code to new xwiki-platform-wiki modules - and more… * Finish scalable import/export (and make it the default) - Thomas Mortagne * Implement Confluence import using wikistream - Thomas Mortagne * Improvements on EM/DW - Thomas Mortagne and Marius as time permits (secondary priority compared to SOLR search and import/export+confluence import) * Security: Continue work started by Thomas Delafosse on Script signing - Denis Gervalle * If time permits: AWM improvements (export and publish of applications + others) - Marius Here are also some JIRA issues that were raised as important (in this order of importance): * XWIKI-9117: When upgrading a wiki, do not display what happened (files edited, etc.) in the Activity Stream * XWIKI-9046: Improve document save performance by not loading the full history * XWIKI-6700: Copying a page over an existing one does not warn user * XWIKI-7377: AWM Add the ability to publish an application as an extension * XWIKI-5146: Support LiveTable text filtering on DBListclass columns * XWIKI-9156: The Wiki UIExtensions should check the rights before executing extension points * XWIKI-8763: Improve AWM for it to deal with error messages directly in the edit mode * XWIKI-9227: Extend the link creation feature for XEM * XWIKI-8757: Support 2 roles for users for app within minutes: application creator and data creator * XWIKI-9233: Cannot save a wiki page containing a link towards a page with a full name >255 For committers for whom I've suggested a name next to items above, is it ok for you to work on this in 5.3? Please make sure you create ASAP the full list of JIRAs that you're committing to work on for XWiki 5.3 and that you put them on the roadmap page at http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome For committers not listed, anything special you wish to work on for 5.3? Dates ===== 5.3M1: 21st of October (2-3 weeks depending on when we release 5.2 final) 5.3M2: 4th of November (2 weeks) 5.3RC1: 18th of November (2 weeks) 5.3Final: 25th of December (1 week) This allows to keep the November period for 5.3 final as planned initially so that we can have 5.4 in December and 5.5 in January. WDYT? Thanks everyone! -Vincent

11 years, 11 months

3
5
0 0

[xwiki-devs] Unable to add user to group after Xwiki update

by echocoder

I am currently running Tomcat 7.0.39 as well the Xwiki 5.0.3 WAR. I imported the Xwiki database into MySQL from an older version of Xwiki which could be the cause of the problems below... When I enter "Administer Xwiki" and choose "Groups" I am sent to the following which lists the groups as expected. /xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladmin&section=Groups#|t=groupstable&p=1&l=10&wiki=local When I click on the "pencil icon" to add a user to a group the same page URL is refreshed and shows a lot of white space followed by a list of users in that group at the bottom of the page. There is no option to add the user to a group. So somewhere along the line I believe something became corrupt during my Xwiki update. I tried copying some VMs from the templates subdir back to my main webapp directory but that didn't work. Any suggestions on where to look? Screenshot attached. <http://xwiki.475771.n2.nabble.com/file/n7585667/part2.png> -- View this message in context: http://xwiki.475771.n2.nabble.com/Unable-to-add-user-to-group-after-Xwiki-u… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 11 months

3
6
0 0

[xwiki-devs] Gource - git/hg log history visualization tool [NWR]

by Jeremie BOUSQUET

Hello guys, Just for fun, I encountered this: https://code.google.com/p/gource/ This is pretty much completely useless, but this log visualization is very beautiful and fascinating. I tried it on the rendering project. It cought me for more time than I had to spend ... ;-) BR, Jeremie

11 years, 11 months

4
8
0 0

[xwiki-devs] Web Viewers

by Ludovic Dubost

Hi, With Caleb we are working on http://www.webviewers.org/ which documents a new standard for portable javascript web viewer and editors which can be used to view and edit files of supported format (current text, pdf, spreadsheet) in any web applications (starting with XWiki). We are demoing this technology on Friday at the Open World Forum in paris. We would need a mailing list to complement the wiki. There are multiple options for that list: - have it maintained by xwiki.org webviewers(a)xwiki.org - open a google group - open a google plus space - open some other web support space What would you think is better, knowing that the objective will be to have participants from developers working on javascript viewers and developers working on web applications. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

11 years, 11 months

2
3
0 0

[xwiki-devs] [Reminder] BFD#39

by Vincent Massol

Hi everyone, Today is BFD 39. We're currently at 3405 bugs created over 1500 days vs 3363 closed, ie 42 bugs behind: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Let's reduce this gap even more today! Here's the BFD#39 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11706 Let's crush bugs! Thanks -Vincent

11 years, 11 months

1
1
0 0

[xwiki-devs] Need BFD organizer for this Thursday

by Vincent Massol

Hi devs, I'll be speaking at a conference this Thursday and won't be available all day. Sorry about that. Could some dev volunteer to organize this BFD? Thanks -Vincent

11 years, 11 months

2
3
0 0

[xwiki-devs] Using XWQL and HQL on panel

by Prachi Maheshwari

Hey everyone, I wrote a panel in XWiki to do some kind of filtering and retrieving data using both XWQL and HQL, and it works fine on the panel Editing page. But when I try including that panel on some other page, it throws errors. Caused by: org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id [xwiki:Panels.Event Summary] Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'execute' in class org.xwiki.query.internal.DefaultQuery threw exception org.xwiki.query.QueryException: Full form statements requires programming right. Query statement = [select doc.name from XWikiDocument doc, BaseObject as obj, StringProperty prop where doc.fullName = obj.name and prop.id.id=obj.id and prop.name='shortText5' and prop.value='USA' and obj.className = 'Event revised.EventrevisedClass'] at xwiki:Panels.Event Summary[line 14, column 278] Caused by: org.xwiki.query.QueryException: Full form statements requires programming right. Query statement = [select doc.name from XWikiDocument doc, BaseObject as obj, StringProperty prop where doc.fullName = obj.name and prop.id.id=obj.id and prop.name='shortText5' and prop.value='USA' and obj.className = 'Event revised.EventrevisedClass'] I don't know what could be possibly wrong. So, Please help. Thanks, Prachi

11 years, 11 months

2
2
0 0

Re: [xwiki-devs] devs Digest, Vol 76, Issue 19

by Prachi Maheshwari

Hey everyone, I wrote a panel in XWiki to do some kind of filtering and retrieving data using both XWQL and HQL, and it works fine on the panel Editing page. But when I try including that panel on some other page, it throws errors. Caused by: org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id [xwiki:Panels.Event Summary] Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'execute' in class org.xwiki.query.internal.DefaultQuery threw exception org.xwiki.query.QueryException: Full form statements requires programming right. Query statement = [select doc.name from XWikiDocument doc, BaseObject as obj, StringProperty prop where doc.fullName = obj.name and prop.id.id=obj.id and prop.name='shortText5' and prop.value='USA' and obj.className = 'Event revised.EventrevisedClass'] at xwiki:Panels.Event Summary[line 14, column 278] Caused by: org.xwiki.query.QueryException: Full form statements requires programming right. Query statement = [select doc.name from XWikiDocument doc, BaseObject as obj, StringProperty prop where doc.fullName = obj.name and prop.id.id=obj.id and prop.name='shortText5' and prop.value='USA' and obj.className = 'Event revised.EventrevisedClass'] I don't know what could be possibly wrong. So, Please help. Thanks, Prachi

11 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs