xwiki-devs July 2012

xwiki-devs@xwiki.org

33 participants
98 discussions

[xwiki-devs] Functional tests failing in platform

by Vincent Massol

Hi Thomas, I've analyzed why Functional tests are failing in the platform, more specifically why the IRCBot one is failing The reason is because there's no XWiki.WikiMacroClass anymore and thus the wiki macro I have in the IRCBot application is not registered when the wiki is started. Could you look at that or tell me how to fix it? Thanks -Vincent

12 years, 1 month

[xwiki-devs] Request for access to Balsamiq Mockups.

by savitha sundaramurthy

Hi Devs, I would like to work on mock ups for Search GUI. From Google, I came across this Balsamiq Mock Ups ( XWiki Partners - http://www.xwiki.com/xwiki/bin/view/Partner/Balsamiq). And Mockups for XWiki Products are hosted at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/WebHome, Is it still active. Can you give me access to this site. I tried to login using my dev.xwiki.org credentials, its resulting in Invalid credentials error. Can you create an account for me with Username : "savis" -- Thanks, Savi

12 years, 1 month

[xwiki-devs] [VOTE] Release 4.2M1 tomorrow (17h July)

by Marius Dumitru Florea

Hi devs, I'm going to be the RM for 4.2.x and for a start I'd like to release 4.2M1 tomorrow (17th July). Note that the release was previously planned for 9th so we're late by a week. If you are working on something that needs to be included in 4.2M1 please reply to this mail. We currently have to blockers: XWIKI-8057: IllegalArgumentException on annotation creation and deletion (Edy is handling it) XWIKI-8060: Script service installed on a wiki (not on root) is not found by script manager (Thomas is handling it) Any other blockers? At the same time we have some functional/integration tests failing for some time: 2 in xwiki-platform ( http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-in… and http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-ir… ), failing for the past 65 builds.. Vincent, can you take a look? 2 in xwiki-enterprise-test-storage ( http://ci.xwiki.org/job/xwiki-enterprise-test-storage/org.xwiki.enterprise$… ) failing for the past 6 builds. Caleb, can you take a look? 1 flicker in xwiki-enterprise-test-selenium (I'll look at it). Thanks, Marius

12 years, 1 month

[xwiki-devs] [VOTE] Add xwiki-platform-git module to xwiki-platform

by Vincent Massol

Hi devs, I've been sitting on this for a few months already. Basically I've implemented this git module: http://extensions.xwiki.org/xwiki/bin/view/Extension/Git+Module My plan is to use it on xwiki.org to provide committer statistics. Thus I'd like to propose to commit it in xwiki-platform (with our rule of committing there what we use for xwiki.org, similar to xwiki-platform-jira). Of course it wouldn't be bundled by default in XE. Here's my +1 Thanks -Vincent PS: The code is small: it's one class

12 years, 1 month

Re: [xwiki-devs] [GSOC] [REMINDER] Mid-term evaluation deadline

by Jonathan Solichin

Hello friends, First I want to thank the community again for this wonderful opportunity. I definitely have learned a lot and am still learning. Additionally, Thank you for the reminder to do the midterm evaluation. 1. Please make sure that your project's page [2] is updated and that the > *progress* field contains an up to date description of your current > progress/status/etc. This is important for those that did not follow your > evolution closely and it is also useful for you to better manage your > work/time. It might also contribute to your evaluation, so please do not > neglect it. I also wanted to apologize at my failure to do this. I misunderstood, and have been updating only the design page. I have since updated the gsoc page, and it is hopefully sufficient. Please do not hesitate to let me know any issues, or any improvement that I should make (eg. if I am being too detailed/not detailed enough). Finally, I want to thank specifically Jerome and Caty, who have given me great advice and support on my project throughout the first part of gsoc. Definitely made the experience much more comfortable. And of course to everyone who dropped by to give their input; every single one made the responsive skin project better. Thank you everyone for your patience, and continual support! Best regards, Jonathan Solichin

12 years, 1 month

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends, You could re-write the whole macro in your template (as a macro - or not). > This way you can change it without overriding the whole macros.vm. Also > know that you can macros.vm "empty" and override macros here selectively, > instead over overloading everything - at least that's as far as I can > remember. Ah, so I only need to write in the macros i specifically need in my macros.vm (that is, my macros.vm will not overwrite the template macros.vm, but will load on top of it?). I tested this and deleted all the macros except the one I changed, and it seems to be working. However, I wanted to make sure, since macros.vm is a big file and that I am not messing anything up. Thanks for the tip. I realized that there is a bug in the skin that prevented some pages from being displayed correctly, or being redirected incorrectly. Those pages would redirect to "[correct url]?viewer=comments" and I realized it was because of the way the commentsinline.vm is integrated into the skin. If my attempt to solve the bug and understanding of xwiki is correct, this is a result of the redirectIfActionNotView macro. Specifically, I think that "#if(!$requestedByAjax && $xcontext.getAction() != 'view' && $xcontext.getAction() != 'get')" on line 85 of commentsinline.vm is causing the redirect issue because the comments are no longer being requested by ajax in my skin (it loads everything and the skin just scrolls to the correct place). This seems to be confirmed as if I remove the ! in front of $requestedByAjax, the document would show up correctly. However, this does not seem to be the correct solution, since if I do this, the page won't be refreshed if I add a comment (manually refreshing the page reveals that the comment has been successfully added). I tried deleting $requestedByAjax and permutting different conditions to load this correctly, but to no avail. Can you point me in the right direction for an elegant solution at this? Also, I am planning to make the livetables work responsively (since they are an integral part of xwiki, and it seems to break the responsiveness of the skin). Presently, my research is pointing me to this solution: http://filamentgroup.com/lab/responsive_design_approach_for_complex_multico…. What are your thoughts/comments? Finally, this was sort of brought up in the semantics thread, but I was wondering whether I should also skin applications (eg. blog)? If I understand correctly, the skin files do not touch upon them? Actually, I guess the css will. Should I just skin them through css, or should I do more? Thank you again!

12 years, 1 month

[xwiki-devs] [Proposal] Improve the QA Manual Test Reporting

by Sorin Burjan

Hello XWiki Community, I would like to propose a change in the visibility of manual testing. The Problem: As you know, we have a manual test report found here: http://www.xwiki.org/xwiki/bin/view/TestReports/ManualTestReportTemplate This report is being copied for each major, minor and intermediary version. Performing a full manual test takes approximately 4-5 days, on one browser. Since we support 4 browsers and 4 databases it would take a very large amount of time to test on everything before every release, since I'm the only one following this manual test report. This is why most of time I perform partial testing on some browsers. Please note that ATM, we stage only one day the artefacts before we release them. Currently our Manual Test Reports is a huge page with a lot of tables. This makes it a little bit hard to test because for each test case, I have to manually add Passed/Failed or No Tested. At the moment there is not enough visibility because we only list the Browsers we support, but we don't give exact information on which testcase has been ran on which browser. I'd like to encourage more users from the community to participate in testing XWiki, and ATM this might be hard because everything is on a single monolithic page. In order to make it as visible as I can, I have the following proposal. The Proposal: Create a dedicated subwiki for QA (maybe qa.xwiki.org), which in future could grow with other QA related things. For the moment, I would like to break the current manual test report in several pages, and several spaces. Each single test would be a wiki page, which will have objects attached to it. The space names will be the features, like WYSIWYG, Administration Application, etc. Also, if this proposal gets voted I'd like in the future to add a new field so we can mark tests that are already automated. This would again, greatly ease my work since I know what is already tested automatically, thus reducing the work needed for manual testing. After brainstorming this idea with Marius and Silvia, we have agreed on the following model: * the MTR will be organized in 2 levels - spaces that will contain feature/testcase suites with pages that hold the individual tests. - pages that will contain individual testcases. Each singular test will also have one or multiple tags attached with the features it belongs to * the following classes to model this: QA.TestClass attached to each page containing a test description (TextArea) - Tells what is the test about e.g: "Tests that images are uploaded fine after a preview." Note that the test name will be the wiki page name and the steps to perform the test will be stored in the document content QA.ExecutionClass (this will contain all information about a test execution) platform (DBList) - linked to QA.PlatformClass browser (DBList) - linked to QA.BrowserClass passed (Boolean) - value to indicate if the test has passed or failed. Absence of an object for a specific platform/browser means not tested jira (String) - link to JIRA issue (if any) tester (User) - user that performed the test date (Date) - date when test was executed QA.PlatformClass (this will contain the version of XE that have been tested/currently being tested) name (String) XE version (String) 4.1.2 QA.BrowserClass (this will contain the browser versions that we support) name (String) Mozilla Firefox version (String) 13 In the same manner we can have this for databases in the future. Final result: - If this is implemented there will be a page with a (custom) lievtable that contains all existing tests. There will be filtering options per feature for example. - There will be also a tag cloud above the livetable (similar with what we have on extensions.xwiki.org) - Marking a test as executed would require 3 clicks maximum (AJAX) right from the LiveTable (Similar to Document/Space Index with Copy/Delete/Rename/Rights), thus improving the speed of manual testing (the "fill in what you tested" part). - Going to the page of an individual test will show all XE versions and browsers on which this has been tested - Easier for everybody to see what has been tested and what not In the future, there will also be a proposal/brainstorming about how to link this with the automated tests. I consider we could be a little bit more visible about this too. Also, there is no visible link between the manual tests and the automated tests. It would be nice if everybody could see for which manual test we have an automated one. I am waiting for your feedback since I am eager to start working on this. Regards, Sorin B.

12 years, 1 month

[xwiki-devs] [VOTE] Let WARN level log pass in xwiki-commons-test

by Thomas Mortagne

Hi devs, Right now xwiki-commons-test has a special logback configuration to let only errors pass. Problem is that in some tests I actually need to get warn too. Also I don't think hidding warning is right, it usually mean there is something wrong. If a test really expect log to be produced it's very easy to isolate them using org.xwiki.loggingLogManager#pushLogListener(null). So the vote is about modifying the test logback configuration to include warn level too. WDYT ? Here is my +1 -- Thomas Mortagne

12 years, 1 month

[xwiki-devs] XWiki WebDAV for MSOffice read-write mode

by bouderbala＠nearbee.com

Hello all, I would like to use XWiki WebDAV for editing MSOffice documents online To do this in read-write mode, we must configure XWiki WebDav on ROOT. Instead of opening the document from: http://myserver.test/xwiki/webdav/spaces/test/msoffice/Bonjour.docx we must open it from: http://myserver.test/spaces/test/msoffice/Bonjour.docx This is what I did: - I am running Tomcat 7 / XWiki Enterprise V2.6 - I renamed the ROOT context xwiki - I changed the servlet-mapping like this <servlet-mapping> <servlet-name>webdav</ servlet-name> <url-pattern>/*</ url-pattern> </ servlet-mapping> Now I can't even request the document http://myserver.test/spaces/test/msoffice/Bonjour.docx I have response: HTTP Status 400 - Bad Request Is there any solution XWiki WebDAV to open MSOffice in read-write mode ? Thanks in advance

12 years, 1 month

[xwiki-devs] [Proposal] Applications panel and configurable menus

by Jean-Vincent Drean

Hi devs, in order to implement XWIKI-7927, "Create an entry point for all available applications inside the wiki" which I plan to commit before 4.2M2 we need to agree on a strategy. The discussions point to a panel in the right column called "Applications" which would list all the applications. Here are my current thoughts about it. We can: 1) Rely solely on application descriptors and list all those applications in the panel. - we don't have such a descriptor yet, the main reason is that what should goes in it can be discussed over and over, even by a single person. Thomas ? :) - it would require an additional mechanism if we wish to be able to edit (ordering, removal) the panel entries; and I think we will want that 2) Implement a menu component that would allow to build dynamic menus. I think applications should be able to plug themselves in the user UI in a manner similar to the way they plug themselves in the administration (ConfigurableClass). It would: - Be generic, we could re-use this mechanism to build both the applications panel and the other XWiki menus (top menu, content menu) - Allow to separate the presence of an application in the wiki with it's presence in the user UI - Allow applications to add entries to top and content menus It could look like this: XWiki.MenuEntryClass - id: String. Technical ID of the entry - menuId: String. ID of the menu the entry is part of - parentMenuEntryId: String. ID of a parent menu entry (optional). Allows to build submenus (example: top menu). - scope: Static list. List of actions the entry should appear for: view/edit/admin/preview. - position: Int. Position in the menu, we could use 0 as undefined (bottom) and order from 1 to n. Also used to position items in submenus. - label: String. Label of the entry. Would be evaluated (velocity ? wiki syntax ?) to allow i18n - target: String. Fullname of the wiki page to point to - enabled: Boolean. Allow to remove an entry from the menu without actual deletion - iconAttachment: String. Name of the attachment to use as the entry icon (optional) Notes: - Objects from this class would be stored in preferences documents since they'll hold configured positions and the enabled state - 'separator' could be a reserved entry ID XWiki.MenuClass - id: String. Technical ID of the menu This class would be associated with a XWiki.MenuSheet and would display the menu editor, which could be simple for a first version (no drag & drop). You might have guessed I'm more in favor of 2) even if I can't refactor the top and content menus for the moment. WDYT ? Thanks, JV.

12 years, 1 month

← 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 July 2012