Hi Devs,
I have a requirement to customize XWiki to integrate with Communities in
a Social Networking Site that I am developing. Members of a Community
should be able to view/edit documents created by other members of the
same community but they should not be able to view/edit documents
created by members of other communities. Essentially, we want to
introduce a 'Community Scope' in XWiki.
The number of communities and members grows with time, obviously.
I think such a feature is not available out of the box. I am planning to
do some customization on the Groups feature of XWiki to achieve this
requirement.
Here is an outline of the approach.
1. When a new community gets created in the social site, create a new
Group of corresponding name in XWiki programatically. (need to know what
API to call).
2. When a user joins a community, automatically add the user to the
XWiki group associated to that community.
3. When a user creates a new document in the community's XWiki, gives
rights to the associated community's Group to that document.
The Rights module of XWiki will automatically take care of the
authorization when that document is requested by any user.
The challenge seems to be identifying the right places in code to make
changes for 1 and 3. (#2 I can try to achieve by overriding
XWikiUser.isUserInGroup() to plugin my custom implementation).
Any pointer in this regard will be greatly appreciated. If there is an
alternative approach to what I am planning, that would be great too.
Thanks,
Rupinder
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
Hello,
What's the current status with:
1) Captcha support on registration?
2) Captcha support on anonymous comments?
(And by captcha I mean something more complicated than "what's 2 + 2?")
3) Sending e-mails with "thanks for registering, click link-here to
activate your account"?
4) Ability to set a SMTP server which requires username+password?
Please, there are many systems where an open smtp, even on localhost,
simply can't / won't be allowed.
5) Ability to delete all comments from a specific user?
6) ... specific IP?
7) ... specific IP range?
8) ... all anonymous comments from a page?
I saw "xwiki.plugin.captcha=" option in xwiki.cfg but it doesn't seem to
do anything?
I really can't see how XWiki can be run in "public mode" without all or
most of the above :/ , preferably enabled out-of-the-box.
Greetings, Lilianne
Hi devs,
To implement the above functionality I have created the following UI:
http://i43.tinypic.com/28l7x2u.png which was dervied from the mockups
located at
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/ImportCompositeDocument
Descriptions of various fields are as follows:
* Document - The office document to be uploaded (and imported)
* Style filtering - Whether to filter office styles or not
* Heading level to split - If the user wishes to split the imported document
into multiple wiki pages, he has to select the heading level (h1, h2, h3...
h6) to be used when splitting the document. If the user does not select a
heading level, the document will be imported as it is (no splitting).
* Custom split regex - If the user wants to further refine the split
criterion (based on the content of header) this field allows him to specify
that criterion through a regular expression.
Example regular expression: <b>Section<b>.*
Open Question: Aren't regular expressions bit too technical for users?
* Target space - This is where the resulting document(s) will land.
* Target (master) page - The main document holding the TOC (in case of
splitting), otherwise this is the name of resulting wiki page.
* Child pages naming method - If the document is split into multiple pages,
pages should be named according to some criterion. This combo box allows
users to specify that criterion.
Regarding the implementation, we have two possible approaches.
1. Implement the splitting in w3c dom level (xhtml)
2. Implement the splitting in XDOM level
* In the first approach we will navigate through the child elements directly
under <body> tag and find matching heading elements. For the regex, we will
have to serialize the heading element so that the regex can be evaluated.
Heading elements can be serialized as explained here:
http://forums.sun.com/thread.jspa?threadID=698475
* In the second approach we can either use XDOM operations or use a
SplittingChainingListener. But I don't know whether regex matching is
possible with this scheme.
Also, regardless of the method we follow, there will be a problem with large
office documents (say 100MB or so). Loading such a file into memory (dom or
xdom) would not be a good idea.
I haven't decided which method to go with yet. So it will be really great if
we can sort this out as soon as possible.
Thanks.
- Asiri
Norguir Bellagio wrote:
> Hi,
>
> I have crawled the mailing lists and support forums on this but I am
> unable to figure out the answer.
>
> I am evaluating Xwiki and love Workspaces from what I've seen so far.
> The one thing that really bogs me down is the inability to register an
> authenticated SMTP server. I have read there is a patch from Liliane,
> and the feature is included on 1.6 but I just can't seem to understand
> how to get is to work. In an evaluation perspective (and very much so as
> well in production), not being able to use authenticated SMTP server is
> a no go for me.
> Could you please point me to a resource that clarifies what the
> situation is and possibly, the steps to enable it on 1.7.
>
> Thanks !
>
> norguir
Actually I'm still waiting for it :/
I just made a quick check and it looks like that patch was not
committed, there's no support for setting username and password in
Administration, and registration mails still go via deprecated
XWiki.sendMessage, which is using Apache Commons SMTPClient (made
obsolete by JavaMail ages ago) and has no support for username/password
and extra properties.
As for mail.smtp.starttls.enable=true, AFAIK when used alone it simply
does not make sense.
_Please_ do something about it :/
If I remember correctly last time the main issue was that the code had
to be integrated in core instead of mail plugin, please, can't we have
the thing working at all first, worry about module separation later?
Basic mail support _is_ core functionality. For me it's a showstopper,
and I don't have enough time to maintain a private fork, either smtp
auth goes in, or I'm going out :/
And before someone says it's open source and I should stop bitching and
submit a patch - I _did_ submit a patch months ago :/
Greetings, Lilianne
Hi Sergiu,
> Since you only committed in the trunk, should this be @since 1.9M1? The
> same for all the other @since tags.
Merged with 1.8 branch today.
> This is good for a standalone Java program. When it comes to webapps,
> the lifecycle is much more complex, since a webapp can be stopped and
> reloaded at will, in a clustered environment it can be moved from one
> computer to another, or it can even be stopped from within the
> application itself. This code is good for the moment, but it will have
> to be changed as soon as we introduce lifecycle events in the
> observation component.
>
I agree :)
Creating the bridge for each new context is a waste of CPU and RAM.
> Since the bridge is stateless, it can be a member initialized in the
> constructor.
>
> > + context.put(VELOCITY_CONTEXT_KEY, new
> OpenOfficeServerManagerVelocityBridge(oomanager, docBridge));
> > + }
> > +}
> >
>
Fixed.
> Why not override toString()?
>
> > + public String getDescription()
> > + {
> > + return this.stateDescription;
> > + }
> > + }
>
Fixed.
>
> in in
>
> > + * These configuration properties are defined in in XWiki's global
> configuration file using the prefix of
> > + * "officeimporter".
> > + * </p>
> > + *
> > + * @version $Id$
> > + * @since 1.8RC3
> > + */
> > +public interface OpenOfficeServerConfiguration
>
Fixed.
> I'm not sure that checking for specific values is a good decision.
> Perhaps checking for non-null, non-empty and non-negative?
>
> > +
> assertEquals(OfficeUtils.getDefaultOfficeHome().getAbsolutePath(),
> configuration.getHomePath());
> > +
> assertEquals(OfficeUtils.getDefaultProfileDir().getAbsolutePath(),
> configuration.getProfilePath());
> > + assertEquals(50, configuration.getMaxTasksPerProcess());
> > + assertEquals(30000, configuration.getTaskExecutionTimeout());
> > + }
> > +}
>
Fixed.
> Is this attachment used anywhere?
>
> > +<attachment>
> > +<filename>icon.png</filename>
> > +<filesize>8674</filesize>
> > +<author>XWiki.Admin</author>
> > +<date>1236277246000</date>
> > +<version>1.0</version>
> > +<comment></comment>
> > +</attachment>
>
Yes, it's used as the openoffice server administration icon in
XWikiPreferences page. This icon will be replaced by a better one (I have
asked laurent).
> I usually delete the tag objects from the XML file before committing.
>
Fixed (Removed tag objects)
> > +#if($hasAdmin)
> > + #info($msgConfiguration)
> > + #if($request.action && $request.action=="stop")
>
> This is best done like this:
> #if("$!request.action" == 'stop')
>
> > + #if(!$oomanager.stopServer())
> > + #error($oomanager.lastErrorMessage)
> > + #end
> > + #elseif($request.action && $request.action=="start")
> > + #if(!$oomanager.startServer())
> > + #error($oomanager.lastErrorMessage)
> > + #end
> > + #elseif($request.action && $request.action=="restart")
>
> Since you're using it several times, you could store the action in a
> variable at the top:
> #set($currentAction = "$!request.action")
>
Fixed (learnt about $! just now)
> What's with the paragraphs? IMO they aren't needed, just write:
>
> $msgServerPath | $serverPath
>
> > +<p>$msgServerPath</p>|<p>$serverPath</p>
> > +<p>$msgServerProfile</p>|<p>$serverProfile</p>
> > +<p>$msgServerState</p>|<p>$currentState</p>
>
Well, without the paragraphs the table looks bit too tight.
>
> Better:
>
> Setting for the OpenOffice instance controlled by the office importer
> plugin.
>
> > +# OpenOffice
> >
> +#-------------------------------------------------------------------------------------
> > +
>
Fixed.
>
> Since 1.9M1?
>
> > +#-# [Since 1.8RC3]
> > +#-# Path to openoffice installation.
> > +# openoffice.homePath=/opt/openoffice.org3/
> > +
> > +#-# [Since 1.8RC3]
> > +#-# Path to openoffice execution profile.
>
> Is this right? For me it's /home/user/.ooo3/
>
> > +# openoffice.profilePath=/home/user/.openoffice.org/3
>
This is the default path structure returned by jodconverter. I think this is
valid for most Linux systems.
Thanks.
- Asiri
Hi,
Some time ago we agreed that component implementations should be
located in the internal package. I now believe it's wrong if we want
to allow users to use our modules separately from the rest of XWiki as
standard java beans. I think it's a good property to have that users
can integrate our modules into their own code without taking the whole
of XWiki. This is what I'm trying to do with the rendering module.
Thus I'm proposing to move the components out of the internal module
*only* for the rendering module for now even though I suspect that
we'll want to do that for all modules eventually.
Here's my +1
Thanks
-Vincent
Hi devs,
We have to make a decision about that.
So here are the proposals:
1) remove the block leading and trainling spaces
* The main goal is to make source formatting for tables for example
more readable
2) make the spaces inside paragraph non meaningfull
* Meaning an HTML like behavior where multiple spaces give one space
3) in case of 1) or 2) use ~<space> as non breaking space
WDYT ?
+0,5 for 1) it's not critical for me but i'm not against it and we
already decided to remove space before list item, headers etc.
-0 for 2) I don't see the need for that and it's a lot easier for the
parser to make spaces meaningfull (what to do when you have "test **
bold**" and things like that)
+1 for 3)
On Sat, Feb 28, 2009 at 15:44, Vincent Massol <vincent(a)massol.net> wrote:
> Hi,
>
> This is our last chance to change this behavior. We've found several
> places where having meaningful spaces are counter-productive:
>
> * in table cells since we can't align table anymore. For example:
>
> |= column1 Â Â Â Â Â Â Â |= column2
> | this is some para  | second column
> | hello             | world
>
> (not sure this will be rendered nicely in mail but you see what I mean)
>
> * in scripts since having meaningful spaces prevents us from aligning
> velocity or groovy scripts. For ex we can't write:
>
> #if (....)
> Â Â #if (...)
> Â Â Â Â do something
> Â Â # end
> #end
>
> To see a better example have a look at http://tinyurl.com/ahz669
>
> What I think users real want are meaningful new lines but I see cons
> overweighting pros for having meaningful white spaces. Thus I'm think
> we should strip whitespaces at beginning and end of lines including
> for line breaks.
> I'm slightly less sure for multiple spaces between words but even
> there I think we could strip them have users use {{{ }}} to put a non
> breaking space for ex (or introduce a {{space/}} macro or another
> special syntax although I'd rather we don't introduce a new syntax).
>
> WDYT?
>
> Thanks
> -Vincent
> http://xwiki.com
> http://xwiki.org
> http://massol.net
>
>
>
>
>
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
http://jira.xwiki.org/jira/browse/XE-391
I believe this issue occurs when there is only one initial revision to a
> document, and 'history' is selected and attempts to diff between version 1
> (which exists) and version 2 (which doesn't).
>
> The code needs to be special-cased for this
> http://en.wikipedia.org/wiki/Off-by-one_error#Fencepost_error
>
> Here's some recent examples, caused by search engines:
>
> 2009-03-03 14:44:16,472 [/xwiki/bin/view/XWiki/SchedulerJobClass?viewer=changes&rev1=$%7Brev1%7D&rev2=$%7Brev2%7D] [TP-Processor35] ERROR api.XWiki - Failed to read versioned document
> org.suigeneris.jrcs.rcs.InvalidVersionNumberException: ${rev1}
> at org.suigeneris.jrcs.rcs.Version.<init>(Version.java:120)
>
> What's with scheduler job class? one revision:
>
> History of SchedulerJobClass
> Version Editor Date Comment
> 1.1 NielsMayer.com Administrator Dec 15, 2006 03:45:59 GMT-08:00
>
> Another:
>
> 2009-03-07 03:24:39,164 /xwiki/bin/view/XWiki/WebPreferences?viewer=changes&rev1=$%7Brev1%7D&rev2=$%7Brev2%7D] [TP-Processor6] ERROR api.XWiki - Failed to read versioned document
> org.suigeneris.jrcs.rcs.InvalidVersionNumberException: ${rev2}
> at org.suigeneris.jrcs.rcs.Version.<init>(Version.java:120)
>
> What's with WebPreferences? One revision:
>
> Version Editor Date Comment
> 1.1 NielsMayer.com Administrator Apr 20, 2007 09:17:52 GMT-08:00
>
> [ Show » <http://jira.xwiki.org/jira/browse/XE-391> ]
Niels Mayer, http://nielsmayer.com<http://jira.xwiki.org/jira/secure/ViewProfile.jspa?name=nielsmayer>added
a comment - 08/Mar/09
19:04 - edited I believe this issue occurs when there is only one initial
revision to a document, and 'history' is selected and attempts to diff
between version 1 (which exists) and version 2 (which doesn't). The code
needs to be special-cased for this
http://en.wikipedia.org/wiki/Off-by-one_error#Fencepost_error Here's some
recent examples, caused by search engines:
2009-03-03 14:44:16,472
[/xwiki/bin/view/XWiki/SchedulerJobClass?viewer=changes&rev1=$%7Brev1%7D&rev2=$%7Brev2%7D]
[TP-Processor35] ERROR api.XWiki - Failed to
read versioned document
org.suigeneris.jrcs.rcs.InvalidVersionNumberException: ${rev1}
at org.suigeneris.jrcs.rcs.Version.<init>(Version.java:120)
What's with scheduler job class? one revision:
History of SchedulerJobClass
Version Editor Date Comment
1.1 NielsMayer.com Administrator Dec 15, 2006 03:45:59 GMT-08:00
Another:
2009-03-07 03:24:39,164
/xwiki/bin/view/XWiki/WebPreferences?viewer=changes&rev1=$%7Brev1%7D&rev2=$%7Brev2%7D]
[TP-Processor6] ERROR api.XWiki - Failed to read
versioned document
org.suigeneris.jrcs.rcs.InvalidVersionNumberException: ${rev2}
at org.suigeneris.jrcs.rcs.Version.<init>(Version.java:120)
What's with WebPreferences? One revision:
Version Editor Date Comment
1.1 NielsMayer.com Administrator Apr 20, 2007 09:17:52 GMT-08:00
Niels
http://nielsmayer.com