Re: [xwiki-users] How to track user activity?

[Ezequiel Scott]

Hi All,

Thanks for the response.
Activity Stream seems to be a great candidate for my purpose, but It
doesn't log "view" events. However, I found it:
http://jira.xwiki.org/browse/XWIKI-6450
I explored xwiki database scheme and I founded two tables:
"xwikistatsvisit" and "activitystream_events". The first one, records view
events, recording  but it
doesn't save WHAT page. The second, records events  but doesn't recognize VIEW as a event.
Have any idea about how to merge this info by querys (if is possible)? Is
possible append a column "page" or "url" to "xwikistatsvisits", so that I
will see  ?

Thanks!

2012/9/24 Sergiu Dumitriu 

> On 09/20/2012 12:31 PM, Ezequiel Scott wrote:
>
>> Hello,
>>
>> Since XWiki support user accounts, enabling visitors to create an account
>> and sign in to the site, Can you tell me if It's possible with a little
>> bit
>> of effort track the activity of logged users? This can include recording
>> activities such as what pages were visited as well as what actions were
>> performed. May be it is possible implementing a plugin with Velocity or
>> extracting the data from database. Have any idea how to do it?
>>
>> Thanks!!
>>
>>
> You can implement your own component [1] that listens [2] for action
> events [3]. You could then see what's the current user [4] and the current
> action [5] and do whatever you want with that information.
>
> [1] 
> http://platform.xwiki.org/**xwiki/bin/DevGuide/**WritingComponents
> [2] http://extensions.xwiki.org/**xwiki/bin/Extension/**
> Observation+Module+Local
> [3] https://github.com/xwiki/**xwiki-platform/blob/**
> 489f4f7c2d3dd6255f8f8ea32ffe8f**d98c9e5b57/xwiki-platform-**
> core/xwiki-platform-bridge/**src/main/java/org/xwiki/**bridge/event/**
> ActionExecutedEvent.java
> [4] https://github.com/xwiki/**xwiki-platform/blob/**
> ff8bc0ee9f22f5e7f4ee0bab6d9437**f53e0b3f1f/xwiki-platform-**
> core/xwiki-platform-bridge/**src/main/java/org/xwiki/**
> bridge/DocumentAccessBridge.**java#L603
> [5] https://github.com/xwiki/**xwiki-platform/blob/**
> 79ec59265415fd89a8b251abe447e0**8b76de1f02/xwiki-platform-**
> core/xwiki-platform-bridge/**src/main/java/org/xwiki/**bridge/event/**
> AbstractActionExecutionEvent.**java#L65
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
>
> __**_
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/**mailman/listinfo/users
>



-- 
*Ezequiel Scott**
*
ezequielsc...@gmail.com
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki Enterprise and XWiki Enterprise Manager 4.2 Release Candidate 1 released

[Eduard Moraru]

The XWiki development team is proud to announce the availability of XWiki
Enterprise 4.2 Release Candidate 1.

This is the first and hopefully final release candidate of the 4.2 release
cycle. Being a release candidate, this release contains bugfixes and
polishing, most of them focused on the new distribution wizard.

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise42RC1

Thanks
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] Problem with XHTML support in XWIKI 4.2-MILESTONE-3

[rradziej]

Hi, 

When I add the XHTML language as the default, and try to create a new page,
the following window displays:
 

The contents oif stacktrace are:


Error number 4001 in 4: Error while parsing velocity page
/templates/xwikivars.vm Wrapped Exception: Failed to evaluate content with
id [/templates/xwikivars.vm]
Error number 4001 in 4: Error while parsing velocity page
/templates/xwikivars.vm
Wrapped Exception: Failed to evaluate content with id
[/templates/xwikivars.vm]
com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while parsing
velocity page /templates/xwikivars.vm
Wrapped Exception: Failed to evaluate content with id
[/templates/xwikivars.vm]
at
com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:110)
at com.xpn.xwiki.XWiki.evaluateTemplate(XWiki.java:1765)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1705)
at com.xpn.xwiki.api.XWiki.parseTemplate(XWiki.java:854)
at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173)
at
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
at
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:369)
at
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at
org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:216)
at
org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:311)
at
org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
at
org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
at
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
at
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106)
at
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
at
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:224)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:184)
at
com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:105)
at com.xpn.xwiki.XWiki.evaluateTemplate(XWiki.java:1765)
at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:155)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:241)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:116)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:120)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:144)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:66)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChai

Re: [xwiki-users] User rights?

[Sergiu Dumitriu]

On 09/24/2012 04:18 AM, Matt Lamoureux wrote:

Thanks Sergiu - I think that does help my understanding.  Something still
doesn't make sense about this part though:

Another piece of the puzzle is that en explicit answer doesn't have to

match the current user, since the way an answer is read isn't "also allow
this right for this user/group on this document/space/wiki", but as "this
user/group is the one that's allowed this right on this
document/space/wiki", *so if GroupA is allowed access explicitly, then
anybody else that's not in GroupA is denied access implicitly.*



My space is set to "allow" for view/edit/delete for both GroupA &
XWikiAllGroup, and all of the pages in that space have "blank" rights (so
they "inherit" rights from the space).  If I choose a page and grant *explicit
*"allow" view/edit/delete access to GroupA (leaving XWikiAllGroup rights as
blanks), that should exclude any non-GroupA user from accessing that page -
right?If so, that is not working properly - the non-GroupA members are
still able to see that page...  The only way I seem to be able to prohibit
"everyone-but-GroupA" from seeing a single page is by using "deny" on the
page level and taking the GroupA members out of the XwikiAllGroup.  I just
don't seem to be able to configure this using the explicity "allow" to
accomplish what you described...




Are you 100% sure about that? This isn't what I see happening on my wiki.

Keep in mind what I said about admin rights always granting any other 
right, regardless of specific space or document rights. So if a user has 
wiki admin rights, it doesn't matter if he's in GroupA or not, he will 
always have access rights on that document.






On Mon, Sep 24, 2012 at 3:08 AM, Sergiu Dumitriu  wrote:


On 09/24/2012 01:58 AM, Matt Lamoureux wrote:


Hmm.  I was hoping to not have to create a separate space just for secured
pages.

I'm confused about how "deny" rights can be stronger than "allow" rights.
If my wiki-level permissions allow View, but have blocked edit and delete,
then how can I go into the space-level rights and grant edit and delete
rights there?  Wouldn't the wiki-level permissions override the
space-level?  If not, then why wouldn't the page-level permissions
override
the space-level?  What am I missing?



I should have been more explicit: Deny rights are always stronger that
allow rights *at the same level*. Rights work on three kind of levels:

1. Document rights override space rights, which override wiki rights.
2. User rights override group rights.
3. Deny rights override allow rights.

So each rights check is done at a 3-dimensional coordinate, such as "check
if there are any rights at (space, users, allow)". This process goes from
the most specific to the most generic, until an *explicit* answer is found
at one of these coordinates.

Another piece of the puzzle is that en explicit answer doesn't have to
match the current user, since the way an answer is read isn't "also allow
this right for this user/group on this document/space/wiki", but as "this
user/group is the one that's allowed this right on this
document/space/wiki", so if GroupA is allowed access explicitly, then
anybody else that's not in GroupA is denied access implicitly.

And there are other extra factors that influence the final outcome, such
as "wiki admin rights automatically grant any other right regardless of any
other deny rights for the user", "a document's creator has implicit delete
rights for that document", "some rights are implicitly allowed if there's
NOTHING explicit said about that right anywhere, while other are implicitly
denied", and so on. The only complete specification about how rights work
is the source code:
https://github.com/xwiki/**xwiki-platform/blob/master/**
xwiki-platform-core/xwiki-**platform-oldcore/src/main/**
java/com/xpn/xwiki/user/impl/**xwiki/XWikiRightServiceImpl.**java



On Mon, Sep 24, 2012 at 1:42 AM, Sergiu Dumitriu 
wrote:

  On 09/24/2012 12:53 AM, Matt Lamoureux wrote:


  Can someone please confirm that I understand user rights properly?


I have a wiki in which I have loaded all of our custom pages into a
space
called "1".  We use LDAP, so every user is automatically added to the
XWikiAllGroup.  We have a small team that wants to utilize secured
pages,
so I created a group called GroupA.  I then went through and added team
members to GroupA (without removing them from XWikiAllGroup).

At the wiki level, I have granted both groups "view" access, but blocked
everything else.
At the "1" space level, I have granted both groups "edit" and "delete"
rights

Now, in that space, there are some pages that we only want GroupA to
see.
I thought it was simple - I could just go into each page, block
XWikiAllGroup from view/edit/delete, and grant view/edit/delete access
to
GroupA.  Apparently that

Re: [xwiki-users] Default value for 'static list' class property

[Ryszard Łach]

On 09/24/12 09:53, Marius Dumitru Florea wrote:
> Yes, but not in the class. What we usually do is create a "template"
> page that has an object of that type (class) and set there the default
> value for each object property. Then we use this template to create
> new pages. See 
> http://platform.xwiki.org/xwiki/bin/view/DevGuide/FAQTutorial#HAuthoringTemplatesandPageDesignSheets
> and http://platform.xwiki.org/xwiki/bin/view/Features/Forms .
>
> Hope this helps,

Yes, I'm using templates too. No idea why I didn't found the simpliest
solution ;-), thanks.

Cheers,

R.



___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] User rights?

[Matt Lamoureux]

Thanks Sergiu - I think that does help my understanding.  Something still
doesn't make sense about this part though:

Another piece of the puzzle is that en explicit answer doesn't have to
> match the current user, since the way an answer is read isn't "also allow
> this right for this user/group on this document/space/wiki", but as "this
> user/group is the one that's allowed this right on this
> document/space/wiki", *so if GroupA is allowed access explicitly, then
> anybody else that's not in GroupA is denied access implicitly.*


My space is set to "allow" for view/edit/delete for both GroupA &
XWikiAllGroup, and all of the pages in that space have "blank" rights (so
they "inherit" rights from the space).  If I choose a page and grant *explicit
*"allow" view/edit/delete access to GroupA (leaving XWikiAllGroup rights as
blanks), that should exclude any non-GroupA user from accessing that page -
right?If so, that is not working properly - the non-GroupA members are
still able to see that page...  The only way I seem to be able to prohibit
"everyone-but-GroupA" from seeing a single page is by using "deny" on the
page level and taking the GroupA members out of the XwikiAllGroup.  I just
don't seem to be able to configure this using the explicity "allow" to
accomplish what you described...






On Mon, Sep 24, 2012 at 3:08 AM, Sergiu Dumitriu  wrote:

> On 09/24/2012 01:58 AM, Matt Lamoureux wrote:
>
>> Hmm.  I was hoping to not have to create a separate space just for secured
>> pages.
>>
>> I'm confused about how "deny" rights can be stronger than "allow" rights.
>> If my wiki-level permissions allow View, but have blocked edit and delete,
>> then how can I go into the space-level rights and grant edit and delete
>> rights there?  Wouldn't the wiki-level permissions override the
>> space-level?  If not, then why wouldn't the page-level permissions
>> override
>> the space-level?  What am I missing?
>>
>>
> I should have been more explicit: Deny rights are always stronger that
> allow rights *at the same level*. Rights work on three kind of levels:
>
> 1. Document rights override space rights, which override wiki rights.
> 2. User rights override group rights.
> 3. Deny rights override allow rights.
>
> So each rights check is done at a 3-dimensional coordinate, such as "check
> if there are any rights at (space, users, allow)". This process goes from
> the most specific to the most generic, until an *explicit* answer is found
> at one of these coordinates.
>
> Another piece of the puzzle is that en explicit answer doesn't have to
> match the current user, since the way an answer is read isn't "also allow
> this right for this user/group on this document/space/wiki", but as "this
> user/group is the one that's allowed this right on this
> document/space/wiki", so if GroupA is allowed access explicitly, then
> anybody else that's not in GroupA is denied access implicitly.
>
> And there are other extra factors that influence the final outcome, such
> as "wiki admin rights automatically grant any other right regardless of any
> other deny rights for the user", "a document's creator has implicit delete
> rights for that document", "some rights are implicitly allowed if there's
> NOTHING explicit said about that right anywhere, while other are implicitly
> denied", and so on. The only complete specification about how rights work
> is the source code:
> https://github.com/xwiki/**xwiki-platform/blob/master/**
> xwiki-platform-core/xwiki-**platform-oldcore/src/main/**
> java/com/xpn/xwiki/user/impl/**xwiki/XWikiRightServiceImpl.**java
>
>
>> On Mon, Sep 24, 2012 at 1:42 AM, Sergiu Dumitriu 
>> wrote:
>>
>>  On 09/24/2012 12:53 AM, Matt Lamoureux wrote:
>>>
>>>  Can someone please confirm that I understand user rights properly?

 I have a wiki in which I have loaded all of our custom pages into a
 space
 called "1".  We use LDAP, so every user is automatically added to the
 XWikiAllGroup.  We have a small team that wants to utilize secured
 pages,
 so I created a group called GroupA.  I then went through and added team
 members to GroupA (without removing them from XWikiAllGroup).

 At the wiki level, I have granted both groups "view" access, but blocked
 everything else.
 At the "1" space level, I have granted both groups "edit" and "delete"
 rights

 Now, in that space, there are some pages that we only want GroupA to
 see.
 I thought it was simple - I could just go into each page, block
 XWikiAllGroup from view/edit/delete, and grant view/edit/delete access
 to
 GroupA.  Apparently that is not true - the fact that they are still in
 XWikiAllGroup prevents them from viewing those pages, since that group
 is
 blocked?  I expected the fact that they are p

Re: [xwiki-users] Default value for 'static list' class property

[Marius Dumitru Florea]

On Fri, Sep 21, 2012 at 3:52 PM, Ryszard Łach  wrote:
> Hi.
>

> Is it possible to assign default value for class property of 'static list' ?

Yes, but not in the class. What we usually do is create a "template"
page that has an object of that type (class) and set there the default
value for each object property. Then we use this template to create
new pages. See 
http://platform.xwiki.org/xwiki/bin/view/DevGuide/FAQTutorial#HAuthoringTemplatesandPageDesignSheets
and http://platform.xwiki.org/xwiki/bin/view/Features/Forms .

Hope this helps,
Marius

>
> TIA,
>
> R.
>
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] User rights?

[Sergiu Dumitriu]

On 09/24/2012 01:58 AM, Matt Lamoureux wrote:

Hmm.  I was hoping to not have to create a separate space just for secured
pages.

I'm confused about how "deny" rights can be stronger than "allow" rights.
If my wiki-level permissions allow View, but have blocked edit and delete,
then how can I go into the space-level rights and grant edit and delete
rights there?  Wouldn't the wiki-level permissions override the
space-level?  If not, then why wouldn't the page-level permissions override
the space-level?  What am I missing?



I should have been more explicit: Deny rights are always stronger that 
allow rights *at the same level*. Rights work on three kind of levels:


1. Document rights override space rights, which override wiki rights.
2. User rights override group rights.
3. Deny rights override allow rights.

So each rights check is done at a 3-dimensional coordinate, such as 
"check if there are any rights at (space, users, allow)". This process 
goes from the most specific to the most generic, until an *explicit* 
answer is found at one of these coordinates.


Another piece of the puzzle is that en explicit answer doesn't have to 
match the current user, since the way an answer is read isn't "also 
allow this right for this user/group on this document/space/wiki", but 
as "this user/group is the one that's allowed this right on this 
document/space/wiki", so if GroupA is allowed access explicitly, then 
anybody else that's not in GroupA is denied access implicitly.


And there are other extra factors that influence the final outcome, such 
as "wiki admin rights automatically grant any other right regardless of 
any other deny rights for the user", "a document's creator has implicit 
delete rights for that document", "some rights are implicitly allowed if 
there's NOTHING explicit said about that right anywhere, while other are 
implicitly denied", and so on. The only complete specification about how 
rights work is the source code:

https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/impl/xwiki/XWikiRightServiceImpl.java



On Mon, Sep 24, 2012 at 1:42 AM, Sergiu Dumitriu  wrote:


On 09/24/2012 12:53 AM, Matt Lamoureux wrote:


Can someone please confirm that I understand user rights properly?

I have a wiki in which I have loaded all of our custom pages into a space
called "1".  We use LDAP, so every user is automatically added to the
XWikiAllGroup.  We have a small team that wants to utilize secured pages,
so I created a group called GroupA.  I then went through and added team
members to GroupA (without removing them from XWikiAllGroup).

At the wiki level, I have granted both groups "view" access, but blocked
everything else.
At the "1" space level, I have granted both groups "edit" and "delete"
rights

Now, in that space, there are some pages that we only want GroupA to see.
I thought it was simple - I could just go into each page, block
XWikiAllGroup from view/edit/delete, and grant view/edit/delete access to
GroupA.  Apparently that is not true - the fact that they are still in
XWikiAllGroup prevents them from viewing those pages, since that group is
blocked?  I expected the fact that they are part of GroupA and GroupA is
authorized, they would be authorized.

If that is true, what is the solution to this?  What is the simplest way
to
secure a page from everyone except the members of GroupA?  If I remove
GroupA members from XWikiAllGroup, that seems to cause other issues with
skins and such.

Any suggestions?



 From 
http://markmail.org/message/**32zfathwmj3pzjre

"Deny rights are always stronger than allow rights. There is no group
ordering, no notion of a "more specific" group."

 From 
http://markmail.org/message/**jzxb2mtzn6kcx6yi

"Specifying an access right for a group automatically denies that right
for those that are not in that group."

So you should just "allow" GroupA, without any "deny".



--
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users