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