In xwiki 4.1.3, there is a document index page that uses live table. It lists authors by first/last name, not their real user name. E.g. if author is user name XWiki.jgibbs, with first/last names "Joe Gibbs", the table shows "Joe Gibbs".
But if I enter "joe" in the search box, I get nothing because it is actually searching the user name (XWiki.jgibbs), which does not have "joe" in it. This seems like a bug because the text shown is not the text being searched for.
Has this been fixed in 4.2 or the upcoming 4.3?
--
Mark Wallace
Principal Engineer, Semantic Applications
Modus Operandi, Inc.
Hi devs,
I've just added 3 items on http://dev.xwiki.org/xwiki/bin/view/Community/Testing#HSelenium2-basedFrame… and I'd like to ensure that we agree about them (if not I'll remove them):
* Tests must not depend on one another. In other words, it should be possible to execute tests in any order and running only one test class should work fine.
* Test chat need to change existing configuration (e.g. change the default language, set specific rights, etc) must put back the configuration as it was
* Tests are allowed to create new documents and don't need to remove them at the end of the test
Here's my +1
Thanks
-Vincent
Hi devs,
Ok BFD #7 which was planned for the 1st of November has been cancelled since it was a day off in France (and I was on holiday at that time so I couldn't follow up on it).
Hence I propose to do it on Thursday the 22nd of November (i.e. in 11 days from now).
Let me know if you can attend it.
Thanks
-Vincent
Hi devs and contributors,
According to a past vote we had [1] we are having a BFD every month on the
first Thursday of every month, with the goal of reducing drastically the
bug count.
This month the BFD is on 1st November, which means Today. This mail is a
reminder that today we are counting :)
As a practice: Once you close an issue (whether you fixed it or mark it
with "duplicate", "won't fix", etc) please ensure you label it with
"bugfixingday" so that we can easily count them at the end of the day.
You can see the current status of issues fixed during all our past Bug
Fixing Days at
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11196
Let's make a dent in this stat:
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R…
Thanks,
Caty of behalf of the XWiki Development Team
[1] http://markmail.org/thread/np65udilrwnuekyh
How can we set javascript variable to a velocity variable? Please reply
with a solution for this. If you have sample it would be more helpful.
Thanks,
Firmusoft
Hi,
while working on a project I developed this simple system for managing the
execution of long running execute-once tasks. It uses the scheduler and it
provides a nice framework for logging and error reporting.
The main use case for this extension is batch import of data, but also
execute-once maintenance operations. Basically every task that is too long
or heavy to be carried on in a single request, and doesn't really qualify
to be a scheduler job.
You can think of this system as a task queue that is processed in the
background.
I am contributing it to xwiki contrib.
Thanks,
Fabio
Hi,
I'd like to register servlets in the component manager and have them called by their hint.
The oldcore struts servlet would be @Named("bin") and the rest servlet would be @Named("rest")
Reasons to want to do this:
* There are things which are currently impossible without a servlet, things like REST, GWT and WebDav.
* If somebody has servlet code and they want to make it run in XWiki, this is a real answer for them whereas "rewrite your app using XWiki actions" isn't.
* Even if we had an Actions system which made it *possible* to implement REST, GWT, and WebDav entry points, we would have to rewrite the universe since all external libraries use Servlet.
* Web.xml is an eyesore, it's full of content which is the concern only of a particular module, this could (mostly) be fixed by using injected servlets.
The big reason not to like it is because it could undermine the proposal for Actions.
The JIRA issue for actions http://jira.xwiki.org/browse/XWIKI-4713 was opened on January 1 of 2010.
It is stalled because nobody really knows how to make an abstraction which represents Servlets or Portlets without any lost features.
If we make it easier for servlets to be used, we might begin down a slippery slope toward everything being done using servlets and then we lose portlet compatibility.
But the alternative as I see it is to block progress in this direction and hope that somebody steps up to implement Actions which are fully compatible with portlets and servlets.
WDYT?
Are there reasons not to do this which I missed?
Caleb
Hi devs,
Following the discussion about general architecture of the new
localization module here is a more detailed proposal for the
dynamically registered wiki translations pages.
Here is how I propose to indicate that a document contains key=value
pair translations:
* put an object of class "XWiki.TranslationDocumentClass"
* set the "visibility" field to "Global", "Current wiki", "Current user"
As for the content of the document it will stay the same as in
preferences based documents for now.
I have other fields in mind for later (on demand, translation message
syntax, etc.) but this is a 4.3 proposal here.
WDYT ?
Here is my +1.
--
Thomas Mortagne
Hi devs,
I would like your vote on merging the 'feature-solr-search' branch with
'master' for 4.3M2 as planned in the Roadmap.
Merge Notes:
- A first version of the Solr search is bundled by default as experimental
with XE, but Lucene is still the default search engine.
--- Lucene has been upgraded to 3.6.1 [1] and Solr has been downgraded to
the same (3.6.1) version in order to achieve the peaceful cohabitation
between the 2 search versions. If we want Solr 4.0, we need to work a bit
more on the Lucene search, since Lucene 4.0 comes with a considerable
number of refactorings.
----- I have just noticed Jerome's feature-lucene-4.0.0-upgrade [2] branch.
- The admin needs to use the Search Administration to switch from Lucene to
Solr and back. (each engine has its own index)
- The back-end contains a SolrIndex for add/delete operations and a
QueryExecutor to query the index trough XWiki's Query API using the 'solr'
language.
- Indexing is only manually performed for now, from the Search
Administration, blocking the request until the operation is complete.
- Search highlighting is available
- The default search looks only for Documents. Filtered/Advanced search
options can be used to change some of the search parameters.
- Lucene/Solr syntax is supported in the query string
- Faceted search is currently hidden because it is not yet in an usable
state.
- SearchSuggest is still using Lucene, no matter what the configuration in
Search Administration says
- The merge also contains a fix for a pretty nasty yet easily fixable
Lucene deadlock [3] (introduced 10 months ago) and some Search Admin UI
improvements [4]
The pull requests [5][6] are available for reviewing so start shooting :)
Thanks,
Eduard
----------
[1] http://jira.xwiki.org/browse/XWIKI-8407
[2]
https://github.com/xwiki/xwiki-platform/tree/feature-lucene-4.0.0-upgrade
[3] http://jira.xwiki.org/browse/XWIKI-8406
[4] http://jira.xwiki.org/browse/XWIKI-8408
[5] https://github.com/xwiki/xwiki-platform/pull/73
[6] https://github.com/xwiki/xwiki-enterprise/pull/34