xwiki-users

xwiki-users@xwiki.org

10408 discussions

by Adrian Hall

I have xWiki 0.9.840 up and running now. Question: I want to have optional sections of the menu bar appear when members of certain groups are logged in. For example, I'd like to have a restricted space (which I now have), but not have the link appear on the left hand menu unless the user is allowed to visit that space. How can I do this? -- Adrian Hall Sr. Product Line Manager, Administration and Identity Management e. ahall(a)mirapoint.com; t. +1 (408) 720-3856; c. +1 (408) 667-4977

19 years

How can I create a restricted websearch?

by Adrian Hall

I see the standard WebSearch searches all spaces, regardless of function. Is there a method by which I can create a WebSearch page that searches just the current space? On a related note, is there a function that I can use to create an RSS feed for what's new for a single space? -Adrian -- Adrian Hall Sr. Product Line Manager, Administration and Identity Management e. ahall(a)mirapoint.com; t. +1 (408) 720-3856; c. +1 (408) 667-4977

19 years

Build 0.9.1037 Bad performance

by Stefan Mueller

Hello everybody, because I had trouble with the last stable version 0.9.840 as somebody out of the community mentioned: - the changes I made are registered in the database - they are displayed on the view page - but they are not on the edit page ...I have installed the unstable build 0.9.1037. This bug is now fixed but version 0.9.1037 seems to be terribly slow. Does anybody have any ideas? Kind regards, Stefan

19 years

On Usability and UI

by Aldo Bucchi

Hi all, I have installed several wiki-ish/collab apps within my intranet so we can test drive them and pick one by the end of the month ( twiki, mediawiki, confluence, xwiki, jspwiki, snipsnap, sharepoint, etc ). So far xwiki is one of the best from the dev point of view. It is free, flexible ( makes for a nice platform for quick day-to-day inhoues apps ), and 100% java. And since we are all geeks, it makes for a nice toy. But from the usability POV it lags behind. * Forms and buttons are not polished ( interaction is awkward and feedback is sometimes ambigous ) * There is too much on the screen I really believe you should focus on improving the UI, as it accounts for a large part of the perceived value... take a look at twiki, confluence or SnipSnap ( and even mediakiwi and it's sound simplicity ). Is something on these lines planned for the next release? Dates? I am tweaking the templates to see how far I can go, but I'd rather stay aligned with you guys. Great work ;), Aldo -- ::::: Aldo Bucchi ::::: mobile (56) 8 429 8300

19 years

AW: [xwiki-users] Access Control and Rights

by Frank Häfemeier

>Hi All, > >Now, this, I think, will allow Xwiki.ahall the ability to edit the rights, >and do other things that "Admin" can do, but it doesn't. I don't get the >"Admin" menu option, and I don't get all the extra options under "More >Actions" There is a caching issue on group rights. (Take a look here: http://mail-archive.objectweb.org/xwiki-users/2006-02/msg00102.html) Try $xwiki.flushCache() in a XWiki document or restart the tomcat instance. Bye Frank

19 years

Access Control and Rights

by Adrian Hall

Hi All, I am attempting to set up a new Wiki for our Intranet running on Jboss 4.0.3SP1 with Tomcat 5.5.16 and MySQL database. I need access control with the following specs: Everyone in Admin Group gets to do anything "Admin" can. People in specific groups get to edit/add content to specific spaces Registered users get to view everything Guests get view access only to Main (and I can turn that off if necessary) I have a user XWiki.ahall (which is me) I added this user to XWiki.XWikiAdminGroup, so that group now contains XWiki.Admin and XWiki.ahall. I have other groups named (for instance) Xwiki.KBGroup to control access further. There are a whole bunch of these. In my Xwiki access rights, I have Xwiki.XWikiGlobalRights 0: Xwiki.XWikiAdminGroup -> Group: Xwiki.XWikiAdminGroup -> Permissions: view,edit,admin,comment -> Users: <blank> -> Allow/Deny: Allow 1: Xwiki.XWikiAllGroup -> Group: Xwiki.XWikiAllGroup -> Permissions: view -> Users: <blank> -> Allow/Deny: Allow 2: Xwiki.XWikiGuest -> Group: <blank> -> Permissions: view -> Users: <blank> -> Allow/Deny: Allow (this last one is what I think will allow me to turn on/off guest). Now, this, I think, will allow Xwiki.ahall the ability to edit the rights, and do other things that "Admin" can do, but it doesn't. I don't get the "Admin" menu option, and I don't get all the extra options under "More Actions" Is there something I am missing here? The reason I want to do this is so I can turn on LDAP authentication - our LDAP server doesn't have an Admin user, so I won't be able to log in as an admin after I turn LDAP Authentication on, so I need an alternate Administrator. -- Adrian Hall Sr. Product Line Manager, Administration and Identity Management e. ahall(a)mirapoint.com; t. +1 (408) 720-3856; c. +1 (408) 667-4977

19 years

by CAROLINA RAMIREZ

All, Someone knows if exist a search in which I can see the name of the document and the content of the document, but only a short content of the document like google. In my wiki http://www.siac.net.co/uso I have a search that it shows a short content of a document, but sometimes it shows a bad content. Thanks

19 years

[xwiki-users] Using VelocityTools 1.2 with XWiki

by Robin Fernandes

Hi all, Is it possible to get VelocityTools v1.2 working with XWiki v0.9.840? http://jakarta.apache.org/velocity/tools/generic/ In particular I'm trying to get ListTools working. I tried copying all the jars from the VelocityTools1.2 archive into the XWiki lib dir, removing the older libs, and editing the toolbox.xml as appropriate. But this must be causing incompatibilities, and results in a bunch of exceptions on startup. Cheers, Robin.

19 years

RE: [xwiki-users] #include<what?>

by THOMAS, BRIAN M (SBCSI)

Ludovic: Thanks for your explanation, which was very helpful; sorry I haven't replied before this. Looking at the source, it was clear that one directive turned on a "pre" flag and the other didn't, but the implications of this which you explained had not occurred to me, especially since the $xwiki methods that implement them also allowed a flag of the same type. However, I am already using #includeMacros, as I mentioned, so unfortunately it doesn't solve my problem. I had the issues confused in my mind, but it now appears that it doesn't have to do with which directive I use to include it, because it isn't a question of whether the included content is rendered before or after inclusion, but whether a macro definition file ever loads. Our wiki is configured as by default up to this point - i.e. the "view" action calls $xwiki.includeForm("$menudoc", false), which (If I understand it correctly) effectively includes the content of $menudoc (which is XWiki.Menu in our case) WITHOUT any interpretation. Our copy of XWiki.Menu has been modified to use #includeTopic("Main.FoldingMenu") (causing Main.FoldingMenu to be interpreted in a separate context BEFORE being inserted into the including document -- correct?). Main.FoldingMenu uses #includeMacros("Main.MenuMacro") and, after setting up the necessary stylesheets and javascript functions, calls the one macro defined in it, #doMenu, on $doc, where the top-level menu entry objects reside. When the wiki is started, the #includeMacros directive apparently fails, because the name "doMenu" is not the name of a macro definition in the context when called, so that instead of executing the macro, Velocity simply renders it as #doMenu(com.xpn.xwiki.api.Document@7a3a97). So the content of the menu document is being rendered (witness the expansion of its single argument, which was $doc), but at the time that it is, the macro definition was not in the context. After some activity ranging from just opening Main.FoldingMenu as a regular document (calling the "view" action on it) to opening it in the editor to actually saving a new version of it, the macro document finally loads and the macro executes. Friday (while I was out, naturally), none of that worked for the people who were here and they replaced it with a hard-coded list. First, it appears that I need to check the logs to see whether there was some failure in the loading of the macro document and troubleshoot that. It may be that a permission problem exists, though I doubt that this could have been the problem - first, every time the problem was corrected, the person who seems to have fixed the problem also experienced it first, and second, the history of the menu document shows that they apparently tried some manipulations of this sort without effect. Neither of these discounts the idea, of course, so neither will I, but I'm not hopeful. Meanwhile, has anyone any ideas? I will, of course, try adding the macro definition to macros.vm, but I suspect that this would only decrease the incidence of the problem rather than eliminating it. It happens seldom enough that it's hard to reproduce as it is, and can't be done at all without restarting the wiki, which is getting to be fairly popular. For one thing, is there a programmatic way to know when an #include directive fails, or do I have to examine the logs? I wouldn't argue for muddying a template language with such a feature, certainly, but if there's some background magic available to administrative users for troubleshooting purposes, it could be useful. I think there's probably still a little too much that needs server administrator access to troubleshoot. brain[sic] -----Original Message----- From: Ludovic Dubost [mailto:ludovic@xwiki.com] Sent: Sunday, April 09, 2006 8:48 AM To: xwiki-users(a)objectweb.org Subject: Re: [xwiki-users] #include<what?> Hi, #includeTopic -> includes and executes any code in the context of the INCLUDED document (variables are the one from the included document) #includeForm -> includes and executres any code in the context of the INCLUDING document (variables are the one from the including document) #includeMacros -> used to embed macros to solve the problem that you are having Another way to solve it is to put your macro in /templates/macros.vm and restart XWiki. This will make your macro global. It's actually better for performance. Ludovic THOMAS, BRIAN M (SBCSI) a écrit : > The various kinds of #include directives have always puzzled me, but > now I think I may have a serious need to understand them. > > I have seen that some of them are implemented by methods on $xwiki > (includeForm, includeTopic, in two incarnations each - with or without > rendering, I assume), but I have no understanding of why they are all > different. Add in the parse directives and XWiki methods and I am > completely confused. > > Can anyone give me a synopsis of what these are all about? I > understand this much: that Velocity directives are read once at parse > time, whereas methods can be invoked multiple times in a loop. > > The problem I need to solve, however, may be a Velocity problem or a > caching problem. A menu is called from the left-side navigation menu > XWiki.Menu. I have included it via #includeTopic, and it use > #includeMacros to bring in a macro that reads a document with a list > of objects describing menu items, with a menu label, an href, and a > long description. If the href field is a complete URL, it's output as > a plain link; if it's a local Wiki document, it's output with XWiki's > bracket syntax and its place is held in the menu as a navigational > aid. If it is also in the Web reserved for such documents, it's a > submenu, and the menu macro is called again (thanks to the earlier > thread, I did use a copy of the argument, which is call-by-reference, > and saved headaches). > > All of this works just fine except the first time it's called after > the server starts. Instead of the menu text, all I see is the > invocation of the macro. Viewing the menu document directly (as I did > when I sought to debug it) fixes the problem for all until the next > reboot. > > So what is this? I read some discussion on the velocity-user mailing > list about when and how macro templates are loaded, but didn't > understand it well; in addition, there is all this confusion about > when to include in what way. > > brain[sic] > > > ---------------------------------------------------------------------- > -- > > > -- > You receive this message as a subscriber of the > xwiki-users(a)objectweb.org mailing list. To unsubscribe: > mailto:xwiki-users-unsubscribe@objectweb.org > For general help: mailto:sympa@objectweb.org?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws > -- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic

19 years

RE: [xwiki-users] SQL hair-pulling

by THOMAS, BRIAN M (SBCSI)

Frank: Thanks. Now, to refine the question a bit: is the set of columns available within each virtual table equivalent to the set of all the Velocity "properties" of each object - which means, as I understand it, all attributes represented by public methods named "get" and "set", declared locally or inherited, by the object's class? It doesn't seem that I have been able to depend on that, but I've gotten pretty turned around dealing with all the metadata and meta-metadata. It seems that the "virtual" schema is supported by the data in the documented schema, though it's not clear that everything needed is there. Further, I don't think I quite understand how to parse the returned result. From the javadoc, I can see that XWiki.search() returns a java.util.List. Through Java reflection I find that the List is actually a java.util.ArrayList, and that each ArrayList element is a java.lang.Object, which is itself an array of java.lang.Object, or depending on how I look at it, of java.lang.reflect.Field. I get the expected number of objects in the array(the number of requested fields in the query), and each one is of the expected type, with the expected value, which is great, but it doesn't seem from the analysis that it ought to. Again, I've probably just confused myself unnecessarily... The real difficulty I have is in directly addressing any field of a returned row. I can loop through it and see what each one is, but without doing that and assigning each field based on the iteration count, I can't just use each field as I can with the returned list from getObjects. I've tried using the get() method that takes an integer index, but that doesn't seem to work; among other things, there's also another get() that takes a string for the field name. I haven't tried that one... Thanks again for a clear answer; this message is both further question and open-ended comment, in hope of stimulating more discussion in order to gain a more solid understanding of what can be done. However much I love to tinker, I am not primarily a developer but an architect and designer, so I need to concentrate on making sure that the tools our developers use are up to the jobs that I give them. It does appear that XWiki is, although the metadata gymnastics needed to navigate the schema are probably a bit too tedious for the average application programmer, let alone the average wiki user. I'm seriously considering building a tool to make those queries more straightforward, though my job rarely permits such luxuries as merely improving the productivity of all our staff... Of course, I can always go to the sources, and I will if I don't get an answer here (and if I have time). More than that, I will share it with the list, on the off chance that someone else needs it... brain[sic] -----Original Message----- From: Frank Häfemeier [mailto:frank@haefemeier.net] Sent: Thursday, March 23, 2006 10:39 AM To: xwiki-users(a)objectweb.org Subject: AW: [xwiki-users] SQL hair-pulling >As mentioned in an earlier message, I got into the $xwiki.search() >world yesterday, and am thoroughly confused. > >The main problem seems to be that the XWiki database schema and the >schema used in all of the $xwiki.search() queries I have found are >completely disjoint. > >Instead of the documented tables and columns, what seems to be used is >a schema which reflects the object model within XWiki. This would >really be convenient if true; is it? This is right. Bye Frank

19 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-users