Re: [xwiki-users] IE bug with top menu

[Haru Mamburu]

Actually the very fast solution is to turn on "compatibility mode" in IE 9. It 
works finally, but it's a problem still :-)


08 февраля 2012, 00:02 от Haru Mamburu :
  
  
Hi!

XE 3.4. IE 9 gives interesting bug: it doesn't show top menu. It exists, even 
works, but invisible. So, users can't find logout button :-(

http://jira.xwiki.org/browse/XWIKI-7496

Does anyone has a clue how to fix it fast?

Kind regards,

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

[xwiki-users] IE bug with top menu

[Haru Mamburu]

Hi!

XE 3.4. IE 9 gives interesting bug: it doesn't show top menu. It exists, even 
works, but invisible. So, users can't find logout button :-(

http://jira.xwiki.org/browse/XWIKI-7496

Does anyone has a clue how to fix it fast?

Kind regards,

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

Re: [xwiki-users] Workspace manager, WYSIWYG editor + 3-rd "new idea"

[Haru Mamburu]

Hi, All,

As we have now workspaces in addition to virtual spaces, it looks logic to 
provide following scenario in UI of WYSIWYG editor:

select virtual wiki/workspace -> Space -> Page -> Anchor

It would help much in multiworkspace environment. Is it difficult to implement? 
Please, vote if it looks useful for you at http://jira.xwiki.org/browse/XEM-209

Kind Regards,

Dmitry


01 февраля 2012, 15:36 от Eduard Moraru :
> Hi Dmitry,
> 
> I understand your concerns about programming rights. It has been and it
> still is a subject of debate.
> 
> However, please note that you do not need programming rights to do velocity
> scripting inside XWiki (whether it is on the main wiki or on a subwiki).
> You need PR only for groovy scripting (since it has access to the core java
> layer) and for some velocity methods that request access to the same core
> java layer that you should normally not need to access. Even so, there are
> rare times when you want to do some complex stuff that *really* needs
> groovy or privileged velocity APIs, so you can not completely escape the
> need of PR.
> 
> I`m not sure the PR wiki-level encapsulation you desire is easy to perform,
> since PR (as they are currently defined) are too powerful to be contained
> inside a wiki and generally tend to have access to everything. The current
> PR would need serious rethinking and maybe redefinition in order to obtain
> that, but it's good to have this encapsulation in consideration when it
> will come to that.
> 
> My 2 cents on the issue :)
> 
> Thanks,
> Eduard
> 
> On Wed, Feb 1, 2012 at 8:42 AM, Haru Mamburu  wrote:
> 
> > Hi, Eduard,
> >
> > Sorry to be unclear first time.
> >
> > Let's end it up:
> >
> > E.g. I set up my workspace AND I need to do some scripting on it. If I got
> > everything right, looks not possible without GLOBAL programming rights.
> > Programming rights actually should work even without admin rights. For now
> > we have no tool to "encapsulate" programming rights of user with
> > programming rights niether inside his own workspace (as a global user), nor
> > inside virtual wiki.
> >
> > "Ideal XWiki world" runs everything independently. It's how I understand
> > words "platform" and "engine".
> >
> > So, this "encapsulation" engine is another "new feature request". I'd like
> > to ask. Is it easy to implement?
> >
> > Finally:
> > http://jira.xwiki.org/browse/XEM-207 -  second level of virtualization
> > http://jira.xwiki.org/browse/XEM-208 -  programming rights incapsulation
> > inside workspaces and virtual wikis
> >
> > Hope, it helps.
> >
> > Kind Regards.
> >
> > Dmitry
> >
> >
> > 30 января 2012, 18:21 от Eduard Moraru :
> >
> >
> > Hi Dmitry,
> >
> > I`m not sure I fully understand your proposal or concerns.
> >
> > 1. You are saying that global admins are dangerous because they can get
> > programming rights and kill everything.
> >
> > They don`t need programming rights to kill everything if they have global
> > admin rights :) They just use the UI to delete everything. Also, I don`t
> > think XWiki`s scope is to protect you from yourself or from your trusted
> > people. If you assign global admin rights to someone, you`d better do it
> > carefully. The same goes with every collaborative system.
> >
> > 2. You are describing a usecase where only subwikis/workspaces are
> > launched in production and that the main wiki is restricted to regular
> > users, in an attempt to avoid global admins.
> >
> > Well... sure, but how is this different from you being the only main wiki
> > admin and the other users to be only subwiki admins (at best)? I`m not sure
> > it's ok to impose such a usecase to users instead of applying it only when
> > needed. Workspaces is already designed to fulfil this usecase by not
> > assigning any main wiki admins. It allows global users to create their own
> > workspaces (subwikis) and play as they wish inside them, no programming
> > rights or global admins involved.
> >
> > 3. I`m not sure I understand the proposed "flexible solution".
> >
> > If by "virtual wiki 2 -> workspaces -> workspaces (probably)" you mean to
> > allow subwikis to be created inside subwikis, then this, indeed is the "new
> > feature request" that I was referring to when suggesting that you create a
> > new jira. The idea is more general than your particular use case and can be
> > applied to various usecases

Re: [xwiki-users] Workspace manager free default pages set + 2 "new ideas"

[Haru Mamburu]

Hi, Eduard,

Sorry to be unclear first time.

Let's end it up:

E.g. I set up my workspace AND I need to do some scripting on it. If I got 
everything right, looks not possible without GLOBAL programming rights. 
Programming rights actually should work even without admin rights. For now we 
have no tool to "encapsulate" programming rights of user with programming 
rights niether inside his own workspace (as a global user), nor inside virtual 
wiki. 

"Ideal XWiki world" runs everything independently. It's how I understand words 
"platform" and "engine".

So, this "encapsulation" engine is another "new feature request". I'd like to 
ask. Is it easy to implement?

Finally:
http://jira.xwiki.org/browse/XEM-207 -  second level of virtualization
http://jira.xwiki.org/browse/XEM-208 -  programming rights incapsulation inside 
workspaces and virtual wikis

Hope, it helps.

Kind Regards.

Dmitry


30 января 2012, 18:21 от Eduard Moraru :
  
  
Hi Dmitry,

I`m not sure I fully understand your proposal or concerns.

1. You are saying that global admins are dangerous because they can get 
programming rights and kill everything.

They don`t need programming rights to kill everything if they have global admin 
rights :) They just use the UI to delete everything. Also, I don`t think 
XWiki`s scope is to protect you from yourself or from your trusted people. If 
you assign global admin rights to someone, you`d better do it carefully. The 
same goes with every collaborative system.

2. You are describing a usecase where only subwikis/workspaces are launched in 
production and that the main wiki is restricted to regular users, in an attempt 
to avoid global admins.

Well... sure, but how is this different from you being the only main wiki admin 
and the other users to be only subwiki admins (at best)? I`m not sure it's ok 
to impose such a usecase to users instead of applying it only when needed. 
Workspaces is already designed to fulfil this usecase by not assigning any main 
wiki admins. It allows global users to create their own workspaces (subwikis) 
and play as they wish inside them, no programming rights or global admins 
involved.

3. I`m not sure I understand the proposed "flexible solution".

If by "virtual wiki 2 -> workspaces -> workspaces (probably)" you mean to allow 
subwikis to be created inside subwikis, then this, indeed is the "new feature 
request" that I was referring to when suggesting that you create a new jira. 
The idea is more general than your particular use case and can be applied to 
various usecases.

Though I still think that one level of virtualization is enough for XWiki (as 
things are working right now), I accept the idea that some people might need 
more complex scenarios.

Thanks,
Eduard


 On Sat, Jan 28, 2012 at 7:41 PM, Haru Mamburu  wrote:
 Hi Eduard,

Thanks for explnation. I'm very happy to issue a "new idea", but idea itself is 
a bit wider and deeper, then described below. I would like to point out some 
reasons and effects to be more clear before "jiraing" it :-)

"Security leak" XE/XEM Usecase

XE/XEM + Workspace Manager. One main Wiki and let's say, hundreds of 
workspaces. To be more real we'd add Wiki Manager and tens of virtual wikis 
running on the same engine (something like XWiki.com running)

As my humble experience shows, nearly never in natural way XWiki would have 
only one User with Admin Rights on the Wiki level.
It's human to be all the time in a hurry and meanwhile XWiki becomes messy 
inside. It's not the big problem yet. :-)

As an Admin User on wiki level, I can easily gain programming rights. For now, 
it's completely uncontrolled and will run unnoticed.

So, let's imagine that all stars in solar system lined up in a bad way and one 
Admin became an AngryAdmin with a revenge as a primary goal of life. Let's make 
it even worth: AngryAdmin knows XWiki quite good and scripting for him is an 
open book. To make it more real: AngryAdmin doesn't have root access to the 
server. :-)

At this stage he has all necessary knowledge and access rights to ruin ALL 
WIKIs onboard. I didn't dig much in it, but if Workspace Manager has 
appropriate tools, then it's possible: one short script and it's over :-)

I didn't met such occasions before, but heard a lot of similar usecases (not 
with XWiki :-)

Thus, I NEVER run production on MAIN wiki!

It looks dangerous for me. I'd better be paranoic admin rather embarrased 
admin. If somebody will become an "angry-beaver-admin", he would be able to 
ruin only one space (now he has a front-end tool for this :-)) or more, but 
only inside one project and all running wikis will stay alive. Such workflow 
keeps my paranoia quiet :-)

SO, at last "new idea":  escape MAIN WIKI from production completely

Re: [xwiki-users] dafault DB name change

[Haru Mamburu]

Error.createSQLException(SQLError.java:1052) 
~[mysql-connector-java-5.1.18-bin.jar:na] at 
com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609) 
~[mysql-connector-java-5.1.18-bin.jar:na] at 
com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541) 
~[mysql-connector-java-5.1.18-bin.jar:na] at 
com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002) 
~[mysql-connector-java-5.1.18-bin.jar:na] at 
com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) 
~[mysql-connector-java-5.1.18-bin.jar:na] at 
com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618) 
~[mysql-connector-java-5.1.18-bin.jar:na] at 
com.mysql.jdbc.ConnectionImpl.setCatalog(ConnectionImpl.java:5086) 
~[mysql-connector-java-5.1.18-bin.jar:na] at 
org.apache.commons.dbcp.DelegatingConnection.setCatalog(DelegatingConnection.java:374)
 ~[commons-dbcp-1.3.jar:1.3] at 
org.apache.commons.dbcp.DelegatingConnection.setCatalog(DelegatingConnection.java:374)
 ~[commons-dbcp-1.3.jar:1.3] at 
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setCatalog(PoolingDataSource.java:333)
 ~[commons-dbcp-1.3.jar:1.3] at 
sun.reflect.GeneratedMethodAccessor164.invoke(Unknown Source) ~[na:na] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 ~[na:1.6.0_26] at java.lang.reflect.Method.invoke(Method.java:597) 
~[na:1.6.0_26] at 
org.hibernate.jdbc.BorrowedConnectionProxy.invoke(BorrowedConnectionProxy.java:74)
 ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final] at $Proxy213.setCatalog(Unknown 
Source) ~[na:na] at 
com.xpn.xwiki.store.XWikiHibernateBaseStore.setDatabase(XWikiHibernateBaseStore.java:620)
 ~[xwiki-platform-legacy-oldcore-3.4.jar:na] ... 69 common frames omitted






30 января 2012, 21:29 от Thomas Mortagne :
> On Mon, Jan 30, 2012 at 6:10 PM, Haru Mamburu  wrote:
> > Yes, I did.  :-(
> >
> > XEM 3.4
> >
> >  javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error number 
> > 3 in 0: Could not initialize main XWiki context
> >  Wrapped Exception: Error number 3202 in 3: Exception while reading 
> > document [name = [XWikiPreferences], type = [DOCUMENT], parent = [name = 
> > [XWiki], type = [SPACE], parent = [name = [xwiki], type = [WIKI], parent = 
> > [null
> >  Wrapped Exception: Error number 3301 in 3: Exception while switching to 
> > database xwiki
> >  Wrapped Exception: Access denied for user 'test'@'localhost' to database 
> > 'xwiki'
> 
> Do you have more ? Would be nice to get the full stack trace.
> 
> >
> >  And actually there is no DB xwiki in Mysql. Xwiki is completely right.
> >  The rest settings in xwiki.cfg are intact.
> >
> >  Kind regards
> >
> >  Dmitry
> >
> > PS. Sorry for the private mailing
> >>
> >> 30 января 2012, 20:46 от Thomas Mortagne :
> >> > On Mon, Jan 30, 2012 at 5:06 PM, Haru Mamburu  
> >> > wrote:
> >> > > Hi, All!
> >> > >
> >> > > Does anyone know, is it possible to change default DB name xwiki to 
> >> > > smth else?
> >> > >
> >> > > I changed in config.cfg,
> >> > >
> >> > > xwiki.db=test
> >> > >
> >> > > in hibernate.cfg.xml
> >> > >
> >> > >  jdbc:mysql://localhost/test
> >> > >
> >> > > After XWiki reload it tries to access xwiki db still. :-(
> >> > >
> >> > > What is correct way to do it?
> >> >
> >> > Well that's supposed to be the correct way actually. You sure you
> >> > uncommented xwiki.db ?
> >> >
> >> > >
> >> > > Thanks in advance,
> >> > >
> >> > > Dmitry
> >> > > ___
> >> > > users mailing list
> >> > > users@xwiki.org
> >> > > http://lists.xwiki.org/mailman/listinfo/users
> >> >
> >> > --
> >> > Thomas Mortagne
> >> >
> > ___
> > users mailing list
> > users@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> 
> --
> Thomas Mortagne
> 
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] dafault DB name change

[Haru Mamburu]

Yes, I did.  :-(
 
XEM 3.4
 
 javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error number 3 
in 0: Could not initialize main XWiki context
 Wrapped Exception: Error number 3202 in 3: Exception while reading document 
[name = [XWikiPreferences], type = [DOCUMENT], parent = [name = [XWiki], type = 
[SPACE], parent = [name = [xwiki], type = [WIKI], parent = [null
 Wrapped Exception: Error number 3301 in 3: Exception while switching to 
database xwiki
 Wrapped Exception: Access denied for user 'test'@'localhost' to database 
'xwiki'
 
 And actually there is no DB xwiki in Mysql. Xwiki is completely right.
 The rest settings in xwiki.cfg are intact.
 
 Kind regards
 
 Dmitry

PS. Sorry for the private mailing
> 
> 30 января 2012, 20:46 от Thomas Mortagne :
> > On Mon, Jan 30, 2012 at 5:06 PM, Haru Mamburu  wrote:
> > > Hi, All!
> > >
> > > Does anyone know, is it possible to change default DB name xwiki to smth 
> > > else?
> > >
> > > I changed in config.cfg,
> > >
> > > xwiki.db=test
> > >
> > > in hibernate.cfg.xml
> > >
> > >  jdbc:mysql://localhost/test
> > >
> > > After XWiki reload it tries to access xwiki db still. :-(
> > >
> > > What is correct way to do it?
> >
> > Well that's supposed to be the correct way actually. You sure you
> > uncommented xwiki.db ?
> >
> > >
> > > Thanks in advance,
> > >
> > > Dmitry
> > > ___
> > > users mailing list
> > > users@xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/users
> >
> > --
> > Thomas Mortagne
> > 
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] dafault DB name change

[Haru Mamburu]

Hi, All!

Does anyone know, is it possible to change default DB name xwiki to smth else?

I changed in config.cfg,

xwiki.db=test

in hibernate.cfg.xml

  jdbc:mysql://localhost/test

After XWiki reload it tries to access xwiki db still. :-(

What is correct way to do it?

Thanks in advance,

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

Re: [xwiki-users] Workspace manager free default pages set + "new idea"

[Haru Mamburu]

Hi Eduard,

Thanks for explnation. I'm very happy to issue a "new idea", but idea itself is 
a bit wider and deeper, then described below. I would like to point out some 
reasons and effects to be more clear before "jiraing" it :-)

"Security leak" XE/XEM Usecase

XE/XEM + Workspace Manager. One main Wiki and let's say, hundreds of 
workspaces. To be more real we'd add Wiki Manager and tens of virtual wikis 
running on the same engine (something like XWiki.com running)

As my humble experience shows, nearly never in natural way XWiki would have 
only one User with Admin Rights on the Wiki level.
It's human to be all the time in a hurry and meanwhile XWiki becomes messy 
inside. It's not the big problem yet. :-)

As an Admin User on wiki level, I can easily gain programming rights. For now, 
it's completely uncontrolled and will run unnoticed.

So, let's imagine that all stars in solar system lined up in a bad way and one 
Admin became an AngryAdmin with a revenge as a primary goal of life. Let's make 
it even worth: AngryAdmin knows XWiki quite good and scripting for him is an 
open book. To make it more real: AngryAdmin doesn't have root access to the 
server. :-)

At this stage he has all necessary knowledge and access rights to ruin ALL 
WIKIs onboard. I didn't dig much in it, but if Workspace Manager has 
appropriate tools, then it's possible: one short script and it's over :-)

I didn't met such occasions before, but heard a lot of similar usecases (not 
with XWiki :-)

Thus, I NEVER run production on MAIN wiki!

It looks dangerous for me. I'd better be paranoic admin rather embarrased 
admin. If somebody will become an "angry-beaver-admin", he would be able to 
ruin only one space (now he has a front-end tool for this :-)) or more, but 
only inside one project and all running wikis will stay alive. Such workflow 
keeps my paranoia quiet :-)

SO, at last "new idea":  escape MAIN WIKI from production completely. 

As only global users has programming rights, it looks very logic to leave Main 
Wiki to "Core and instances" management and keep it safe from local admins. 
When U have a lot of users it sounds reasonable for me.

Let's return to our Case 1-3 described below. The most flexible solution looks 
as following:

             |  virtual wiki 1 -> workspaces
             |  virtual wiki 2 -> workspaces -> workspaces 
(probably)
Main Wiki      |   ..
             |  virtual wiki N - "Solo" - No Workspace Manager 
onboard
(administration)         (production)

Such a way we can run everything simultaneously on the same server. No need to 
run a lot of instances. 
If someone want's programming rights, he could be isolated locally and won't 
affect other wikis. Looks safe for me.

Bad news:
- Nobody, besides MySQL users would be happy, XEM is MySQL dependent still :-( 

So, before I'd "jira" an idea, I'd like to know community opinion to keep it 
comprehensive. 

Hope, it would be nice idea for 4.0 roadmap to think over :-)

Best Regards,

Dmitry


28 января 2012, 00:53 от Eduard Moraru :
  
  
Hello again,

Please see below...

On Fri, Jan 27, 2012 at 3:17 PM, Haru Mamburu  wrote:
Thanks a lot for clarification.

It makes sence now from explained point of view, but I still can't get WHY as 
global user on NON-workspace wiki I should see Workspace Manager menus?

As I tried to explain in my previous mail, the idea is that you are a global 
user, coming from a global context (the main wiki). In that global context, you 
have the Workspace application installed and available for you to use. This 
means that, the Workspace
 application offers you the possibility to create a new workspace, jump to the 
main wiki or view existing workspaces trough the top-menu.

From the Workspace application's point of view, it is only natural to allow you 
to perform these actions, regardless of your current location (that means even 
if you are viewing a non-workspace subwiki). As long as the Workspace 
application is installed, it will perform as designed :)
  
Anyhow I can't use Workspace Manager INSIDE virtual Wiki. It makes sence if you 
would extend Workspace manager and make it completely independent on each and 
every virtual wiki.
 
So, the main reason why: it's just useles inside virtual wiki (for now)

Again, the extra menus are not about what you can do on the current wiki, but 
they are about what you can do on the whole XWiki, since this is a feature that 
spans cross wikis and is not restricted to an individual wiki (even if it is 
installed on the main wiki).
 

For me, e.g., ideal workflow looks like:

Case 1. XEM -> virtual wiki isolated, no Workspace Manager on board

This is perfectly doable r

Re: [xwiki-users] Workspace manager free default pages set

[Haru Mamburu]

Thanks a lot for clarification.

It makes sence now from explained point of view, but I still can't get WHY as 
global user on NON-workspace wiki I should see Workspace Manager menus? Anyhow 
I can't use Workspace Manager INSIDE virtual Wiki. It makes sence if you would 
extend Workspace manager and make it completely independent on each and every 
virtual wiki. 

So, the main reason why: it's just useles inside virtual wiki (for now)

For me, e.g., ideal workflow looks like:

Case 1. XEM -> virtual wiki isolated, no Workspace Manager on board

Case 2. XEM -> virtual wiki isolated, WITH Workspace Manager on board. Each 
virtual wiki in this case will be able to produce it's own workspaces isolated 
from each other (like independent projects on the same server). Only Local 
Users can take part in workspace management.

Case 3. XEM -> virtual wiki isolated + Workspace manager on board. Same as Case 
2, but Local Users can log once in any virtual/workspace wiki they allowed AND 
via this login have access to each and every wiki they registered/invited.

For current purposes I would prefer Case 1 behaviour. Soon I'd like to use Case 
2  then 3 scenario, but for now - no way :-(

Hope it would be useful for futher development.

Kind Regards,

Dmitry




27 января 2012, 16:48 от Eduard Moraru :
  
  
Oh, I see now.

The way it works now when visiting a normal subwiki (not a workspace) is that:

1) If you are a global user (user of the main wiki), the menus will be 
displayed to you (and you will be thus exposed to the global context of which 
you are part of).

2) If you are a local user (user of a subwiki that is part of a wiki *farm*), 
you don`t see the menus any more and are isolated inside the wiki (and not 
exposed to the global context).

So, as a conclusion, the menus appear to you based on your user type and not on 
the type of wiki you are currently viewing.

Does that make sense now? Does this fit your usecase? If not, can you please 
elaborate on the reason why you would like global users not to be able to see 
the global context when viewing a regular subwiki?

Thanks,
 Eduard

On Fri, Jan 27, 2012 at 1:32 PM, Haru Mamburu  wrote:
 Thank you Eduard,

Sorry, probably I wasn't clear in my questions...

- I want to use WORKSPACE Manager on MAIN Wiki and manage them as designed.
- BUT, the same time I want to use WIKI Manager to have completely independent 
from main wiki and other workspaces virtual wikis.

So, I set up XEM, installed Workspace manager to play around AND with Wiki 
Manager created virtual Wiki.
Now I completely stuck how to get rid of all Workspace Manager links in wiki 
farm (!) (not workspaces). I would prefer to keep running Workspace Manager on 
main Wiki AND Wiki farm simultaneously, if possible.

Is there any simple solution?

The only thing I suppose should work is to take *.vm files from XE and attach 
them to the skin file. Looks wierd and unpredictable for me :-(

Kind Regards,

Dmitry


27 января 2012, 14:26 от Eduard Moraru :


Hi Dmitry,

Starting with 3.3, XEM has moved the main usecase for subwikis from farm to 
workspaces. This means that, additionally to the WikiManager application [1], 
now XEM also contains the Workspace Application [2].

The encouraged way of for creating a wiki farm right now (if that is really 
what you need) is to get XE, install WikiManager [1] and create your farm.

If you *insist* on using XEM for creating a wiki farm, all you have to do is 
delete the WorkspaceManager space, thus removing the Workspaces application and 
disabling the extra menus that were getting in your way. Additionally, you 
should also remove the xwiki-platform-workspace-api-.jar file from the 
/webapps/xwiki/WEB-INF/lib/ folder, since you don`t want to use it anymore and 
you have removed the UI.

However, if your plan is to have global users that work on different subwikis 
(like an intranet with departments mapped to subwikis or a place where you work 
on projects mapped to subwikis, etc.), you might reconsider using Workspaces.

In any case, I hope this solves your problem.

Thanks,
Eduard

-
References:
[1] 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Application
 [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application

On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu  wrote:
Ooops, wrong solution. The problem is still active: is there a right way to get 
rid of Workspace Manager's links in virtual wikis in 3.4?


27 января 2012, 13:46 от Haru Mamburu :
> Hi All,
>
> By accident I found a soluion. For me it looks a bit wierd.
>
> If you set in xwiki.cfg  xwiki.virtual.usepath to 0, then all menus become 
> Workspace Manager links free.
>
> For now, if I want to use usepath and don't want to use Workspace Manager, 
> there is no an "one click solution" :-(
>
> Is it a bug or it's a feature? Should I report it?

Re: [xwiki-users] Workspace manager free default pages set

[Haru Mamburu]

Thank you Eduard,

Sorry, probably I wasn't clear in my questions...

- I want to use WORKSPACE Manager on MAIN Wiki and manage them as designed. 
- BUT, the same time I want to use WIKI Manager to have completely independent 
from main wiki and other workspaces virtual wikis.

So, I set up XEM, installed Workspace manager to play around AND with Wiki 
Manager created virtual Wiki. 
Now I completely stuck how to get rid of all Workspace Manager links in wiki 
farm (!) (not workspaces). I would prefer to keep running Workspace Manager on 
main Wiki AND Wiki farm simultaneously, if possible.

Is there any simple solution? 

The only thing I suppose should work is to take *.vm files from XE and attach 
them to the skin file. Looks wierd and unpredictable for me :-(

Kind Regards,

Dmitry


27 января 2012, 14:26 от Eduard Moraru :
  
  
Hi Dmitry,

Starting with 3.3, XEM has moved the main usecase for subwikis from farm to 
workspaces. This means that, additionally to the WikiManager application [1], 
now XEM also contains the Workspace Application [2].

The encouraged way of for creating a wiki farm right now (if that is really 
what you need) is to get XE, install WikiManager [1] and create your farm.

If you *insist* on using XEM for creating a wiki farm, all you have to do is 
delete the WorkspaceManager space, thus removing the Workspaces application and 
disabling the extra menus that were getting in your way. Additionally, you 
should also remove the xwiki-platform-workspace-api-.jar file from the 
/webapps/xwiki/WEB-INF/lib/ folder, since you don`t want to use it anymore and 
you have removed the UI.

However, if your plan is to have global users that work on different subwikis 
(like an intranet with departments mapped to subwikis or a place where you work 
on projects mapped to subwikis, etc.), you might reconsider using Workspaces.

In any case, I hope this solves your problem.

Thanks,
Eduard

-
References:
[1] 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Application
 [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application

On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu  wrote:
Ooops, wrong solution. The problem is still active: is there a right way to get 
rid of Workspace Manager's links in virtual wikis in 3.4?


27 января 2012, 13:46 от Haru Mamburu :
> Hi All,
>
> By accident I found a soluion. For me it looks a bit wierd.
>
> If you set in xwiki.cfg  xwiki.virtual.usepath to 0, then all menus become 
> Workspace Manager links free.
>
> For now, if I want to use usepath and don't want to use Workspace Manager, 
> there is no an "one click solution" :-(
>
> Is it a bug or it's a feature? Should I report it?
>
> Kind regards,
>
> Dmitry
>
> 27 января 2012, 01:34 от Haru Mamburu :
> > Hi. all!
> >
> > XEM 3.4. Main Wiki works fine.
> >
> > I want to set up virtual wiki without Workspace Manager application inside 
> > and it's links in menu, because as far as I inderstood it is useless in 
> > virtual wikis.
> >
> > What is right way to get rid of Workspace Manager and it's links in top 
> > menu in virtual wiki?
> >
> > Kind regards,
> >
> > Dmitry
___
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] Workspace manager free default pages set

[Haru Mamburu]

Ooops, wrong solution. The problem is still active: is there a right way to get 
rid of Workspace Manager's links in virtual wikis in 3.4?


27 января 2012, 13:46 от Haru Mamburu :
> Hi All,
> 
> By accident I found a soluion. For me it looks a bit wierd.
> 
> If you set in xwiki.cfg  xwiki.virtual.usepath to 0, then all menus become 
> Workspace Manager links free.
> 
> For now, if I want to use usepath and don't want to use Workspace Manager, 
> there is no an "one click solution" :-(
> 
> Is it a bug or it's a feature? Should I report it?
> 
> Kind regards,
> 
> Dmitry
> 
> 27 января 2012, 01:34 от Haru Mamburu :
> > Hi. all!
> >
> > XEM 3.4. Main Wiki works fine.
> >
> > I want to set up virtual wiki without Workspace Manager application inside 
> > and it's links in menu, because as far as I inderstood it is useless in 
> > virtual wikis.
> >
> > What is right way to get rid of Workspace Manager and it's links in top 
> > menu in virtual wiki?
> >
> > Kind regards,
> >
> > Dmitry
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Workspace manager free default pages set

[Haru Mamburu]

Hi All,

By accident I found a soluion. For me it looks a bit wierd.

If you set in xwiki.cfg  xwiki.virtual.usepath to 0, then all menus become 
Workspace Manager links free.

For now, if I want to use usepath and don't want to use Workspace Manager, 
there is no an "one click solution" :-(

Is it a bug or it's a feature? Should I report it?

Kind regards,

Dmitry



27 января 2012, 01:34 от Haru Mamburu :
> Hi. all!
> 
> XEM 3.4. Main Wiki works fine.
> 
> I want to set up virtual wiki without Workspace Manager application inside 
> and it's links in menu, because as far as I inderstood it is useless in 
> virtual wikis.
> 
> What is right way to get rid of Workspace Manager and it's links in top menu 
> in virtual wiki?
> 
> Kind regards,
> 
> Dmitry
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] Workspace manager free default pages set

[Haru Mamburu]

Hi. all!

XEM 3.4. Main Wiki works fine.

I want to set up virtual wiki without Workspace Manager application inside and 
it's links in menu, because as far as I inderstood it is useless in virtual 
wikis.

What is right way to get rid of Workspace Manager and it's links in top menu in 
virtual wiki? 

Kind regards,

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

Re: [xwiki-users] Status of filesystem attachment storage.

[Haru Mamburu]

Hi, 

I had been playing with FS for quite a long time and must say, that it is 
almost ready for production:
- Looks stable, major and minor bug fixes were made.
- Since 3.4 it deals with non-ascii correctly. I checked it with Cyrillic on 
3.4RC1.
- If you would turn FS on, be aware, that recycle bin with FS works, BUT still 
we have http://jira.xwiki.org/browse/XWIKI-7399
So, I didn't manage to make it running. So, I just switched off recycle bin for 
attachments, because this bug makes deleted attachment unmanaged. :-(

> If so - why in 3.4 versions default storage for attachments will be
> hibernate?

If you don't play with large attachments (like I do), for clusering and 
maintainance it would much easier to keep all attachments in DB. Traditionally 
it was DB :-)

As for me, Attachments size is relatively huge and will make all system very 
slow very soon, so I use FS from the very beginning of the project.

Kind Regards

Dmitry


25 января 2012, 01:37 от Ryszard Łach :
> Hi.
> 
> Could anyone, please, give any info about status of filesystem
> attachment storage?
> 
> Is it stable? Does it deal with non-ascii filenames prolerply?
> 
> If so - why in 3.4 versions default storage for attachments will be
> hibernate?
> 
> Cheers,
> 
> 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

[xwiki-users] Selected pages of PDF to image conversion in XWiki?

[Haru Mamburu]

Hi!

The task is:
- Calculate MD5 of attached PDF document
- Extract e.g first 10 pages from the attached PDF file as images
- store images as attachments into the document

1. What is the best way to calculate MD5 in XWiki? Is it possible to do via 
standard velocity scripting in XWiki?

2. Is there any built in/hidden ways of PDF->image conversion of several pages 
of attached PDF file? 
If not, what is the solution possible? I found some opensource JAVA libraries, 
but I realize a big gap in my understanding between libraries and their 
integration in XWiki with followng velocity scripting usage.

Does anyone has a clue where to dig to make all this staff runnung?

Thanks in advance,

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

Re: [xwiki-users] Version Error

[Haru Mamburu]

Looks like 
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationMySQL#HHTTP500Error

Try this. Hope it will help.

Kind Regards,

Dmitry


23 января 2012, 20:10 от eparent_pk :
> Hi,
> 
> I'm having the  http://pastebin.com/k5V6mBha same error .
> 
> My xwiki installation is Enterprise 3.3, on Ubuntu 11.10 (x64) with
> tomcat6.
> 
> I installed following the instructions on this
> http://blog.dontneedcoffee.com/2010/02/install-xwiki-22-on-ubuntu-910-mysql.html
> site .
> 
> Here is an example of my  http://pastebin.com/HEPmAAeQ hibernate.cfg.xml
> .
> 
> I created MySQL user 'xwiki' who was granted with create, insert, alter,
> delete entries for the xwiki database.
> 
> All the setup tutorials I've seen are quite straight forward but, for
> some reason, I just can't get it to work. Any hint / advice will be
> appreciated.
> 
> Cheers,
> 
> - Eric
> 
> --
> View this message in context: 
> http://xwiki.475771.n2.nabble.com/Version-Error-tp6480013p7216532.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
> ___
> 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] XWiki Enterprise and XWiki Enterprise Manager 3.4 Milestone 1 Released

[Haru Mamburu]

Hi!

Thanks a lot for the new XWiki version.

As for: "New default color theme" - http://jira.xwiki.org/browse/XWIKI-6982  
It's the old one, but looks actual still.

Great thanks for: "* Special characters in attachment name". I checked cyrillic 
names - works fine.

Also I checked an issue we couldn't reproduce earlier. It failed to work again. 
http://jira.xwiki.org/browse/XWIKI-7399
Kindly ask somebody to reproduce steps in this JIRA issue and prove the bug or 
clarify how to avoid it. Till now I failed to get it working :-(

Thanks in advance,

Dmitry


13 января 2012, 22:00 от Marius Dumitru Florea :
> The XWiki development team is proud to announce the availability of
> XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and
> XWiki Enterprise Manager 3.4 Milestone 1.
> 
> This is the first and only milestone of the 3.4 version. We're getting
> closer to the end of the 3.x cycle and the goal of this release (and
> the following one, which will be the last of the cycle) is to improve
> the current features. The highlights of this release are:
> 
> * New default color theme
> * XWiki 2.1 is the default page syntax
> * Delete space menu
> * Simple space templates
> * Special characters in attachment name
> * Minimized action menu
> * Display macro
> * Improved Extension Manager UI
> 
> See the full release notes at
> http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise34M1
> for more details.
> 
> Thanks
> -The XWiki dev team
> ___
> 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] [Help] Help us improve the XWiki documentation by telling us what's missing

[Haru Mamburu]

Hi, Vincent,

I put an issue "XWiki setup and configuration issues" at 
http://jira.xwiki.org/browse/XWIKIORG-25 
Probably, the list of setup problems is not full and somebody would extend it. 
:-)

Kind regards,

Dmitry


05 января 2012, 14:07 от Vincent Massol :
> Guys, we didn't get any new JIRA issue on improving the xwiki.org 
> documentation.
> 
> So I guess it means our documentation is perfect and there's nothing to 
> improve, right? :)
> 
> Come on, help us identify precise stuff that need improvement. I'm sure you 
> have had problems finding information about something in the past!
> 
> Thanks
> -Vincent
> 
> On Dec 20, 2011, at 2:16 PM, Vincent Massol wrote:
> 
> > Hi XWiki users,
> >
> > The XWiki projects needs your help. We'd like to improve the documentation 
> > on xwiki.org but we need your help to tell us what should be improved in 
> > your opinion.
> >
> > To do so we've created a JIRA project for listing stuff to do:
> > http://jira.xwiki.org/browse/XWIKIORG
> >
> > It would be a great help if you could register there and create JIRA issues 
> > for anything you think should be improved on xwiki.org.
> >
> > Please try to create very specific and focused issues so that they are 
> > actionable easily (for example an issue saying "Improve xwiki.org 
> > documentation" would not help much ;) but one that would say for example: 
> > "Provide documentation on how to use the DBListClass" is useful).
> >
> > Thanks a lot for your help!
> > -Vincent on behalf of the XWiki Dev Team
> 
> ___
> 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] Tomcat and /xwiki path

[Haru Mamburu]

Thanks a lot, Sergiu!

Understanding logic behind something makes it much easier to find right 
solution. :-)
Also I updated documentation 
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationTomcat#HNginxproxyingforTomcatapplications
to save nginx newbies time for setting it up.

Kind regards,

Dmitry Bakbardin



26 декабря 2011, 10:25 от Sergiu Dumitriu :
> On 12/25/2011 03:04 PM, Haru Mamburu wrote:
> > Hi, All
> >
> > Recently I had to deploy XWiki under Centos. As a brand new task for me it 
> > required tonns of documentation to dig in.
> >
> > Finally I managed to set up: Centos + MySQL + Tomcat 7 + nginx.
> > Everything is fine besides some Tomcat's behaviour.
> >
> > - localhost:8080 or localhost:8080/ shows ROOT application
> > - localhost:8080/xwiki shows XWiki application as desired. Fine.
> > - if nginx redirects required requests from 80 port to localhost:8080/xwiki 
> > we obtain wrong links, because /xwiki automatically is added to requested 
> > string. Works fine only first request to e.g. "mydomain.com".
> >
> > So, next step is to set XWiki application as DAFAULT application in Tomcat, 
> > so localhost:8080 will call XWiki by default.
> >
> > Googling gave me several complicated solutions with redirect and two almost 
> > clear solutions with Tomcat configuration:
> > - Deploy XWiki in $CATALINA_HOME/webapps/ROOT
> > After this nginx can easily proxy all requests like "mydomain.com" on 80 
> > port to localhost:8080
> >
> > - Deploy XWiki in $CATALINA_HOME/webapps/xwiki
> > Then add Following string in Host section in $CATALINA_HOME/conf/server.xml 
> > :
> >
> >
> >
> > I tried second way, it works fine, nginx redirects all "mydomain.com" 
> > requests to localhost:8080 correctly, BUT all URLs from required, e.g,
> >
> > localhost:8080/xwiki/bin/view/Main
> >
> > become
> >
> > localhost:8080/bin/view/Main
> >
> > So, we miss /xwiki in URL.
> > As for me, "xwikiless" URLs solution looks fine, BUT as far as I remember, 
> > somebody from developers' team pointed out in mailing lists some time ago, 
> > that /xwiki in URL could be necessary in some cases. (??)
> >
> > The questions are:
> > 1. Is it crucial for XWiki and/or some XWiki applications to eat shorten 
> > URL on Tomcat's level?
> > Will it affect, for example, on virtual wiki mapping for URLs based 
> > addresses like http://myfarm.net/xwiki/wiki/wikiname/?
> 
> XWiki should work just fine with the shorter URLs. The "xwikiless"
> information might be very outdated, when it used to be true that some
> parts of XWiki would fail.
> 
> > 2. Should we change anything in XWiki configuration files to force it 
> > working with such URLs?
> 
> No.
> 
> > OR, the best way to put ${catalina.home}/webapps/ROOT/Web-inf/web.xml with 
> > redirect information as it is done e.g. in standalone XWiki for Windows?
> >  From other side, I also found an opinions on forums, that redirect method 
> > is not the best solution for search engines robots. So, I got lost a bit :-)
> >
> > Kindly ask you to clarify this tricky subject in order to avoid unnecessary 
> > errors in the future.
> > On finding right, community approved solution(s), I will amend 
> > documentation accordingly.
> 
> It should also be possible to configure nginx to work properly with
> XWiki deployed as /xwiki/, so if you want, you can dig some more to find
> out why it doesn't work right now and what to do to make it work.
> 
> My guess is that you're trying to map :80/* to :8080/xwiki/* which means
> that /xwiki/ will be added to each URL that nginx requests from Tomcat,
> including those that already have /xwiki in them. Thus, all the URLs
> generated by XWiki, such as /xwiki/bin/view/Some/Doc, will end up as
> :8080/xwiki/xwiki/bin/view/Some/Doc, which is wrong. You should have two
> different rules if you want to keep /xwiki/ in the URL:
> 
> 1. Redirect from hostname.com/ to hostname.com/xwiki, as a client
> response redirect, not as an internal forwarding.
> 2. Forward requests to /xwiki/* to :8080/xwiki/*
> 
> > Thanks in advance,
> >
> > Dmitry Bakbardin
> 
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
> ___
> 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

[xwiki-users] Tomcat and /xwiki path

[Haru Mamburu]

Hi, All

Recently I had to deploy XWiki under Centos. As a brand new task for me it 
required tonns of documentation to dig in.

Finally I managed to set up: Centos + MySQL + Tomcat 7 + nginx. 
Everything is fine besides some Tomcat's behaviour.

- localhost:8080 or localhost:8080/ shows ROOT application
- localhost:8080/xwiki shows XWiki application as desired. Fine.
- if nginx redirects required requests from 80 port to localhost:8080/xwiki we 
obtain wrong links, because /xwiki automatically is added to requested string. 
Works fine only first request to e.g. "mydomain.com".

So, next step is to set XWiki application as DAFAULT application in Tomcat, so 
localhost:8080 will call XWiki by default.

Googling gave me several complicated solutions with redirect and two almost 
clear solutions with Tomcat configuration:
- Deploy XWiki in $CATALINA_HOME/webapps/ROOT 
After this nginx can easily proxy all requests like "mydomain.com" on 80 port 
to localhost:8080

- Deploy XWiki in $CATALINA_HOME/webapps/xwiki
Then add Following string in Host section in $CATALINA_HOME/conf/server.xml :

  
  
I tried second way, it works fine, nginx redirects all "mydomain.com" requests 
to localhost:8080 correctly, BUT all URLs from required, e.g,

localhost:8080/xwiki/bin/view/Main

become

localhost:8080/bin/view/Main

So, we miss /xwiki in URL. 
As for me, "xwikiless" URLs solution looks fine, BUT as far as I remember, 
somebody from developers' team pointed out in mailing lists some time ago, that 
/xwiki in URL could be necessary in some cases. (??)

The questions are:
1. Is it crucial for XWiki and/or some XWiki applications to eat shorten URL on 
Tomcat's level?
Will it affect, for example, on virtual wiki mapping for URLs based addresses 
like http://myfarm.net/xwiki/wiki/wikiname/?
2. Should we change anything in XWiki configuration files to force it working 
with such URLs?

OR, the best way to put ${catalina.home}/webapps/ROOT/Web-inf/web.xml with 
redirect information as it is done e.g. in standalone XWiki for Windows?
From other side, I also found an opinions on forums, that redirect method is 
not the best solution for search engines robots. So, I got lost a bit :-)

Kindly ask you to clarify this tricky subject in order to avoid unnecessary 
errors in the future.
On finding right, community approved solution(s), I will amend documentation 
accordingly.

Thanks in advance,

Dmitry Bakbardin


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

Re: [xwiki-users] [Announcement] XWiki Enterprise 3.3 and XWiki Enterprise Manager 3.3 Released

[Haru Mamburu]

One more vote on board :-)


18 декабря 2011, 01:49 от Ludovic Dubost :
> 2011/12/17 Eugen Colesnicov 
> 
> > Thanks for great job!
> > Especially for the Oracle support! Also AppWithinMinutes looks very
> > interesting - I will start "to feel" it!
> >
> > Also, regarding to your discussion about 3.4 roadmap and 3.x cycle, I want
> > one more time to focus you at an older problem - supporting of russian
> > symbols (or other non-latin characters, spaces and special symbols) in
> > attachment names.
> >
> > Interesting moment. If you using office importer and your office-file named
> > in russian, and your file contains some pictures, when wiki-page creates -
> > ALL PICTURE ATTACHMENT FILENAMES WRITTEN ON RUSSIAN WITHOUT ANY PROBLEM! I
> > can download them, get link, etc.
> >
> > According to this I can make a conclusion, that supporting of non-latin
> > attachment filenames is ALREADY DONE ON A PLATFORM LEVEL. And, right now,
> > for my opinion, NEED ONLY SMALL STEP - DELETE FUNCTION OF CUTTING NON-LATIN
> > SYMBOLS FROM ATTACHMENT FILENAMES DURING NORMAL ATTACH PROCESS.
> >
> >
> Good point, maybe a patch could be provided that deactivates this stripping
> using a configuration setting.
> I would vote +1 to include it asap in the platform.
> 
> Ludovic
> 
> > Please, include this issue in your roadmap of 3.x cycle! This is really
> > important thing - because without this XWiki cannot named as "multilanguage
> > web platform". ALL OTHER MODERN WEB-PLATFORMS ALREADY HAVE THIS FUTURE...
> > Only XWiki lagging ...
> >
> >
> > --
> > Best regards
> > Eugen Colesnicov
> >
> > --
> > View this message in context:
> > http://xwiki.475771.n2.nabble.com/Announcement-XWiki-Enterprise-3-3-and-XWiki-Enterprise-Manager-3-3-Released-tp7103443p7103549.html
> > Sent from the XWiki- Users mailing list archive at Nabble.com.
> > ___
> > users mailing list
> > users@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> >
> 
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> ___
> 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] Each sub-wiki has own storage location... is it possible?

[Haru Mamburu]

"Thanks, now all you need is to attach the patch or issue a git pull request :)"

Welcome, but still kindly ask you to clarify what exactly to do :)
I got lost a bit :(

Thanks a lot,

Dmitry


09 декабря 2011, 13:09 от Vincent Massol :
> Hi Haru,
> 
> On Dec 9, 2011, at 6:34 AM, Haru Mamburu wrote:
> 
> > Thanks a lot, Vincent,
> 
> Nice, I get credit even when I don't speak :)
> 
> > I issued a feature request,
> > http://jira.xwiki.org/browse/XE-1061
> 
> Thanks, now all you need is to attach the patch or issue a git pull request :)
> 
> Cheers,
> -Vincent
> 
> > Kind Regards
> >
> > Dmitry
> >
> >
> > 09 декабря 2011, 09:16 от Ludovic Dubost :
> >> I don't think it has been done but it shouldnt be a difficult patch
> >>
> >> Ludovic
> >>
> >> Envoyé de mon iPhone
> >>
> >> Le 8 déc. 2011 à 23:01, Haru Mamburu  a écrit :
> >>
> >>>
> >>> Does anyone has a clue?
> >>>
> >>>
> >>> 04 декабря 2011, 06:50 от Haru Mamburu :
> >>>
> >>>
> >>>
> >>> Hi, all!
> >>>
> >>> For now we have a possibility to move wiki's filestorage easily by 
> >>> changing path in config file. Cool!
> >>>
> >>> In multi-sub-wiki environment it looks very useful (sometimes) to split 
> >>> common storage and move sub-wiki's storage to other place.
> >>>
> >>> Is there any simple way to set location of each sub-wiki's storage? If 
> >>> not, is it easy to implement?
> >>>
> >>> Kind Regards
> >>>
> >>> Dmitry Bakbardin
> >>>
> >>> ___
> >>> 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
> 
> 
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Each sub-wiki has own storage location... is it possible?

[Haru Mamburu]

Thanks a lot, Vincent,

I issued a feature request,
http://jira.xwiki.org/browse/XE-1061

Kind Regards

Dmitry


09 декабря 2011, 09:16 от Ludovic Dubost :
> I don't think it has been done but it shouldnt be a difficult patch
> 
> Ludovic
> 
> Envoyé de mon iPhone
> 
> Le 8 déc. 2011 à 23:01, Haru Mamburu  a écrit :
> 
> >
> > Does anyone has a clue?
> >
> >
> > 04 декабря 2011, 06:50 от Haru Mamburu :
> >
> >
> >
> > Hi, all!
> >
> > For now we have a possibility to move wiki's filestorage easily by changing 
> > path in config file. Cool!
> >
> > In multi-sub-wiki environment it looks very useful (sometimes) to split 
> > common storage and move sub-wiki's storage to other place.
> >
> > Is there any simple way to set location of each sub-wiki's storage? If not, 
> > is it easy to implement?
> >
> > Kind Regards
> >
> > Dmitry Bakbardin
> >
> > ___
> > 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] Each sub-wiki has own storage location... is it possible?

[Haru Mamburu]

Does anyone has a clue?


04 декабря 2011, 06:50 от Haru Mamburu :
 
  
  
Hi, all!

For now we have a possibility to move wiki's filestorage easily by changing 
path in config file. Cool!

In multi-sub-wiki environment it looks very useful (sometimes) to split common 
storage and move sub-wiki's storage to other place.

Is there any simple way to set location of each sub-wiki's storage? If not, is 
it easy to implement?

Kind Regards

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

Re: [xwiki-users] Push on translations

[Haru Mamburu]

Hi!

I fixed Russian translation both for XE and Wiki Manager. 
Some links look broken in the right panel "Supported Languages for XE", what 
may lead to misunderstanding especially for new users.
Also "Best XE Contributors" left panel is still in TODO list. :-)

Kind Regards,

Dmitry Bakbardin



08 декабря 2011, 12:49 от Ludovic Dubost :
> Hi XWiki devs and users,
> 
> I think we need to make a push on translations. We have about 150
> translations that are not yet available in
> 
> French
> German
> Latvian
> Russian
> Swedish
> 
> Otherwise we have the following language that would need a small push to
> get complete:
> 
> Spanish (es) 459 translations
> Czech (cs) 258 translations
> Traditional Chinese (zh_TW) 641
> Catalan 863
> 
> It would be great to get some contributors for
> 
> Italian
> Portugese
> Dutch
> 
> Any help is welcome to get this down. If you want to help you can go to
> http://l10n.xwiki.org
> If we get the translations numbers under 250 we'll make sure we get the
> translations in the distribution.
> 
> Ludovic
> 
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> ___
> 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

[xwiki-users] Each sub-wiki has own storage location... is it possible?

[Haru Mamburu]

Hi, all!

For now we have a possibility to move wiki's filestorage easily by changing 
path in config file. Cool!

In multi-sub-wiki environment it looks very useful (sometimes) to split common 
storage and move sub-wiki's storage to other place.

Is there any simple way to set location of each sub-wiki's storage? If not, is 
it easy to implement?

Kind Regards

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

Re: [xwiki-users] XOffice not downloading pages, missing attachments

[Haru Mamburu]

Hi, Paul,

IMHO, from one side Xoffice - great tool, from other - it's almost useless:
- MS Word is not the only editor in the PC world
- MS Word is relatively "heavy" application. 
- Installation process is far from seamless - huge headache for people  "who 
have almost no free time and are not interested in
 learning yet another program". They will have to spend 10 times more time on 
installing it, than on mastering WYSIWYG editor. Just try it on 10 users, you 
will see the difference :-)
- Localization (here I mean cyrillic names)

Much more versatile tool - web browser.

" Everyone we talked to about editing a wiki document via the web interface
 was simply not interested."

When human has choice to learn or skip learning with the same final result, 
usually choice is obvious. Nobody ever will find browser more useful, then MS 
Word, until you will close MS Word option forever.  That's human. Meanwhile 
each and every user wil find it more useful for them, then "old-styled-word" 
editing. So, in this case - CHOICE is bad thing to move forward. Try it on 
regular users and you will feel it yourself.

Last century people mastered MS Word, this century people found it 
extrafeatured, simplified as much as possible editing process and made 
wiki-cloud based systems default  for document workflow.
So, for more or less big projects: Windows and Word purchase looks insane 
versus open source OS + web browser. As I understand, it's the only reason, why 
other project do not such tools (like XOffice).  I do have MS Word on my 
Windows 7 machine, but I don't remember when I used it last time to EDIT 
documents.  ;)

 As for me, XWiki has one of the best in class web-based WISIWYG editor and all 
known for me users found it easy to use: NO NEED to dig into XWiki Syntax AT 
ALL. Just try other solutions to compare.

"The killer feature is that normal users can create a document and copy-paste 
screenshots into a wiki document."

This really has sence to implement into WISYWIG editor, but don't think it's a 
primary necessity. For me, for example, more critical - less complicated 
mechanism of anchor management.

Probably, these reasons are slowly pushing Xoffice aside of mainstream.

Kind regards.

Dmitry Bakbardin



24 октября 2011, 18:36 от Paul Harris :
> The killer feature is that normal users can create a document and copy-paste
> screenshots into a wiki document.
> That cannot be done with (almost) any web wiki editor I can find at present.
> 
> Every person we showed it to loved it, and was willing to try editing a
> document on the wiki.
> Everyone we talked to about editing a wiki document via the web interface
> was simply not interested.
> We work with people who have almost no free time and are not interested in
> learning yet another program (ie web-wiki)... They know MS Word well, they
> are already read to write content.
> 
> I don't understand why you aren't pushing this simple but powerful component
> more.  I don't see it mentioned on wikipedia, or wikimatrix.
> I think if you made sure xoffice worked, and let people know it existed,
> then more people would use xwiki.  Its a killer feature and I don't
> understand why its not on billboards on the sides of freeways.
> 
> Regards,
> Paul
> 
> On 24 October 2011 20:35, Florin Ciubotaru wrote:
> 
> > Hi,
> >
> > If you didn't start your documentation yet and you don't have any legacy
> > documents, I'd recommend using a pure web solution like XWiki. If you use
> > MS
> > Office for advanced content, you will have issues pushing that content to
> > the wiki anyway.
> > I created XOffice a few years ago, when MS Office was a lot more dominant
> > and web editors were still weak(including the one used by XWiki), but the
> > situation is quite different now.
> >
> > Indeed there was no development on it for the past year.
> > If you have critical issues with XOffice, it may be one of the following:
> > - you are using a localized version of Office or Windows (there are older
> > known issues with those)
> > - there is a conflict with newer XWiki versions.
> >
> > The MS Office and Windows behavior and security settings are different for
> > versions released on other languages. It doesn't make a lot of sense, but
> > that's the way it is.
> > I've been receiving quite a few requests for a new release. However I could
> > only do some bug fixing only for the En/En environment, since it's a pain
> > to
> > test and fix other versions.
> >
> > Thanks,
> > Florin Ciubotau
> >
> >
> > On Mon, Oct 24, 2011 at 9:46 AM, Vincent Massol 
> > wrote:
> >
> > > Hi Paul,
> > >
> > > Indeed nobody is actively working on it at the moment and I was about to
> > > send a mail this week to propose to retire it and move it to the contrib
> > > repository since nobody in the xwiki committers are active on it and we
> > want
> > > to keep a good quality on the software that we make available.
> > >
> > > The only alternative would be someone stepping up and willing to work

Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap

[Haru Mamburu]

Yes I do have JIRA account, just try to vote for your own issues, I don't think 
you will succeed. Have a look at file attached. :-)

Dmitry


20 октября 2011, 16:47 от Thomas Mortagne :
> On Thu, Oct 20, 2011 at 2:13 PM, Haru Mamburu  wrote:
> > Thank you, Caleb,
> >
> > But JIRA says, that I can't vote on the topics I issued, so 0 means +1 :-)
> 
> That's weird, do you have an account on jira ?
> 
> >
> > Kind regards,
> >
> > Dmitry
> >
> > 20 октября 2011, 12:49 от Caleb James DeLisle :
> >> I have just assigned myself XWIKI-6918 and XWIKI-6917, the bugs.
> >> You can go ahead and vote on the feature requests (resume download and 
> >> webdav access) and we can see where things go from there.
> >>
> >> Caleb
> >>
> >> On 10/20/2011 04:02 AM, Haru Mamburu wrote:
> >> > Hi,  All
> >> >
> >> > Also, I'd add  all bug fixes with file storage system, because for now, 
> >> > I have had to switch off (in 3.2):
> >> >
> >> > - versioning of attachment
> >> > - recycle bin for attachment
> >> >
> >> > to use it more or less seamless. Otherwise, there is a big mess with 
> >> > deleted attachment occure. Everything I found, "JIRAded" already: 
> >> > XWIKI-6989, XWIKI-6921,      XWIKI-6918,     XWIKI-6917.
> >> > Would be nice also to have resume download for big files: XWIKI-6921
> >> >
> >> > So, we have a new feature, but with a very limited functionality, that 
> >> > really works. Moreover, not each and every core functions really support 
> >> > attachments, stored in FS. For projects with big and huge attachments 
> >> > these topics are essential, IMO.
> >> >
> >> > Some additional support for cyrillic XWIKI-6955 is also welcome to put 
> >> > in plan. :-)
> >> >
> >> > Best regards,
> >> >
> >> > Dmitry Bakbardin
> >> >
> >> >
> >> > 20 октября 2011, 11:25 от Eugen Colesnicov :
> >> >> Hello developers!
> >> >>
> >> >> I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In 
> >> >> this
> >> >> post also described jira-requests, which you planned to resolve in a 
> >> >> near
> >> >> future.
> >> >>
> >> >> All is great, the general strategy and each step are right, but also 
> >> >> exists
> >> >> some other important issues (I think that its are important) and I want 
> >> >> to
> >> >> put your attention on its. If is it possible, can you analyze 
> >> >> possibility to
> >> >> include these issues in your nearly plans?
> >> >>
> >> >> 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade & fresh
> >> >> install failed). I think, it is important issue, because supporting of
> >> >> Oracle are declared - but in realty XE 3.2 is not supporting Oracle.
> >> >>
> >> >> To the future, maybe is good proposal, same as you wrote in a 3.2 
> >> >> release
> >> >> notes - which browsers are tested & supporting - also will write witch 
> >> >> DB
> >> >> are tested & supporting. I can test new releases on Oracle.
> >> >>
> >> >> 2. XE-324 - allow special (russian and asian) characters in attachment 
> >> >> names
> >> >> - very old issue, but I think is important, because without it - you 
> >> >> cannot
> >> >> declare that XWiki have normal multi-language support. All modern
> >> >> web-platforms & applications now have this possibility (wikis, 
> >> >> web-mails,
> >> >> social applications, etc.) only XWiki is lagging...
> >> >>
> >> >> 3. XWIKI-2870 - Ability to select query language in Database List 
> >> >> property.
> >> >> This is more for developers, and also very old issue. I think it is
> >> >> important, because if you did something modern (in this case - XWQL) - 
> >> >> need
> >> >> to support this in all "parts" of platform... If you didn't do this - 
> >> >> your
> >> >> great work for modern features - looks like as "garbage" - I cannot use 
> >> >> XWQL
> >> >> in Data

Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap

[Haru Mamburu]

Thank you, Caleb,

But JIRA says, that I can't vote on the topics I issued, so 0 means +1 :-)

Kind regards,

Dmitry

20 октября 2011, 12:49 от Caleb James DeLisle :
> I have just assigned myself XWIKI-6918 and XWIKI-6917, the bugs.
> You can go ahead and vote on the feature requests (resume download and webdav 
> access) and we can see where things go from there.
> 
> Caleb
> 
> On 10/20/2011 04:02 AM, Haru Mamburu wrote:
> > Hi,  All
> >
> > Also, I'd add  all bug fixes with file storage system, because for now, I 
> > have had to switch off (in 3.2):
> >
> > - versioning of attachment
> > - recycle bin for attachment
> >
> > to use it more or less seamless. Otherwise, there is a big mess with 
> > deleted attachment occure. Everything I found, "JIRAded" already: 
> > XWIKI-6989, XWIKI-6921,  XWIKI-6918, XWIKI-6917.
> > Would be nice also to have resume download for big files: XWIKI-6921
> >
> > So, we have a new feature, but with a very limited functionality, that 
> > really works. Moreover, not each and every core functions really support 
> > attachments, stored in FS. For projects with big and huge attachments these 
> > topics are essential, IMO.
> >
> > Some additional support for cyrillic XWIKI-6955 is also welcome to put in 
> > plan. :-)
> >
> > Best regards,
> >
> > Dmitry Bakbardin
> >
> >
> > 20 октября 2011, 11:25 от Eugen Colesnicov :
> >> Hello developers!
> >>
> >> I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this
> >> post also described jira-requests, which you planned to resolve in a near
> >> future.
> >>
> >> All is great, the general strategy and each step are right, but also exists
> >> some other important issues (I think that its are important) and I want to
> >> put your attention on its. If is it possible, can you analyze possibility 
> >> to
> >> include these issues in your nearly plans?
> >>
> >> 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade & fresh
> >> install failed). I think, it is important issue, because supporting of
> >> Oracle are declared - but in realty XE 3.2 is not supporting Oracle.
> >>
> >> To the future, maybe is good proposal, same as you wrote in a 3.2 release
> >> notes - which browsers are tested & supporting - also will write witch DB
> >> are tested & supporting. I can test new releases on Oracle.
> >>
> >> 2. XE-324 - allow special (russian and asian) characters in attachment 
> >> names
> >> - very old issue, but I think is important, because without it - you cannot
> >> declare that XWiki have normal multi-language support. All modern
> >> web-platforms & applications now have this possibility (wikis, web-mails,
> >> social applications, etc.) only XWiki is lagging...
> >>
> >> 3. XWIKI-2870 - Ability to select query language in Database List property.
> >> This is more for developers, and also very old issue. I think it is
> >> important, because if you did something modern (in this case - XWQL) - need
> >> to support this in all "parts" of platform... If you didn't do this - your
> >> great work for modern features - looks like as "garbage" - I cannot use 
> >> XWQL
> >> in Database List property - as a result - I am not using XWQL at all,
> >> because I don't want to write queries 2 times.
> >>
> >> If is it possible, can you analyze possibility to include these issues in
> >> your nearly plans?
> >>
> >> PS. Maybe another users know some more important unresolved issues? I 
> >> think,
> >> user opinions will be interesting for developers!
> >>
> >> Thanks beforehand!
> >> Eugen Colesnicov
> >>
> >> --
> >> View this message in context: 
> >> http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6911884.html
> >> Sent from the XWiki- Users mailing list archive at Nabble.com.
> >> ___
> >> 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
> 
> ___
> 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] 4Developers: more important issues regarding to XE 3.3 Roadmap

[Haru Mamburu]

Hi,  All

Also, I'd add  all bug fixes with file storage system, because for now, I have 
had to switch off (in 3.2):

- versioning of attachment
- recycle bin for attachment

to use it more or less seamless. Otherwise, there is a big mess with deleted 
attachment occure. Everything I found, "JIRAded" already: XWIKI-6989, 
XWIKI-6921,  XWIKI-6918, XWIKI-6917.
Would be nice also to have resume download for big files: XWIKI-6921

So, we have a new feature, but with a very limited functionality, that really 
works. Moreover, not each and every core functions really support attachments, 
stored in FS. For projects with big and huge attachments these topics are 
essential, IMO.  

Some additional support for cyrillic XWIKI-6955 is also welcome to put in plan. 
:-)

Best regards,

Dmitry Bakbardin


20 октября 2011, 11:25 от Eugen Colesnicov :
> Hello developers!
> 
> I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this
> post also described jira-requests, which you planned to resolve in a near
> future.
> 
> All is great, the general strategy and each step are right, but also exists
> some other important issues (I think that its are important) and I want to
> put your attention on its. If is it possible, can you analyze possibility to
> include these issues in your nearly plans?
> 
> 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade & fresh
> install failed). I think, it is important issue, because supporting of
> Oracle are declared - but in realty XE 3.2 is not supporting Oracle.
> 
> To the future, maybe is good proposal, same as you wrote in a 3.2 release
> notes - which browsers are tested & supporting - also will write witch DB
> are tested & supporting. I can test new releases on Oracle.
> 
> 2. XE-324 - allow special (russian and asian) characters in attachment names
> - very old issue, but I think is important, because without it - you cannot
> declare that XWiki have normal multi-language support. All modern
> web-platforms & applications now have this possibility (wikis, web-mails,
> social applications, etc.) only XWiki is lagging...
> 
> 3. XWIKI-2870 - Ability to select query language in Database List property.
> This is more for developers, and also very old issue. I think it is
> important, because if you did something modern (in this case - XWQL) - need
> to support this in all "parts" of platform... If you didn't do this - your
> great work for modern features - looks like as "garbage" - I cannot use XWQL
> in Database List property - as a result - I am not using XWQL at all,
> because I don't want to write queries 2 times.
> 
> If is it possible, can you analyze possibility to include these issues in
> your nearly plans?
> 
> PS. Maybe another users know some more important unresolved issues? I think,
> user opinions will be interesting for developers!
> 
> Thanks beforehand!
> Eugen Colesnicov
> 
> --
> View this message in context: 
> http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6911884.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
> ___
> 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] [Announcement] XWiki Enterprise 3.2 Release Candidate 1 Released

[Haru Mamburu]

Hi! 

"Workspace manager alternative way of using virtual wikis".
Does it mean, that If I need both XEM and Workspace Manager I can use both of 
them almost independently? And Wiki Farms are invisible for Workspace manager?
Is it safe to use both of  them simultaneously?
As far as I understood, it's not possible to use Workspace Manager on a Wiki 
farm? Is it true?

Best regards,

Dmitry Bakbardin


06 октября 2011, 03:12 от Sergiu Dumitriu :
> The XWiki development team is proud to announce the availability of
> XWiki Enterprise 3.2 Release Candidate 1. This is the first (and
> hopefully last) release candidate for the 3.2 series.
> 
> Apart from a few minor bugfixes, this version brings the Workspace
> Manager as a standard feature of the platform, as an alternative way of
> using virtual wikis, compared to XEM.
> 
> See
> http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32RC1
> for more details.
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
> ___
> 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] Access rights management bug?

[Haru Mamburu]

Thanks a lot for explanation, 

So, as far as I understood, scenario is:

- Space of the document has only view right for Group1. Our user is a member of 
Group1.
- This user tries to edit the document in edit/inline mode by pressing the 
link/button generated somwhere else, not in required page.
- Required page checks if our user belongs to Group1 and if true - opens 
document as a user with real edit rights
- User in Group1 edits properties in inline mode. On pressing submit button 
script saves page as our edit-mode-user.
- Finally Group1 user again has no edit rights and no edit menu options.

In this case some behaviour is still unclear:
- Logic says to me that access rights are checked before script will run. If 
yes, no way to run edit mode in our case.
- If user presses button Save & view instead of form Submit button, what 
happens? Again, there is no way to script to save page with  
$doc.saveAsAuthor()  function.

Am I missing something? 

The second scenario loks more clear for me if scripts do ALL the job:
- Required page Checks rights
- Asks user via form if he wants to edit page
- Sends user to ANOTHER page
- This "another" page obtains all necessary data from the object properties of 
required page.
-  builds form and gives pseudo-inline mode to our user.
- saves document on submit on behalf of user with edit rights.
- redirects back to saved required page (by the way, redirect doesn't eat 
cyrillic names, and for now I don't know how to get it round)

And in this case ALL pages for User from Group1 would be accessible only in 
XWiki's native view mode. 
This scenario gives a "guarantee" and deep feeling of "safe wiki" for admin , 
but also gives a lot of additional programming. 

And as far as I got - this is the only way to build  ''smart -user-resistant' 
application. :-) 
But still, I'd prefer to manage all these rights via default XWiki application.

Kind regards,

Dmitry Bakbardin



23 сентября 2011, 11:30 от Caleb James DeLisle :
> Another way that you can get the results you are looking for is to write a 
> script which does the editing
> on the user's behalf. If the script document is saved by someone who has 
> permission to edit the
> document which the user wants to edit and the user needs to be able to, for 
> example: edit only the content
> of an object but not add or remove objects or change the document's main 
> content.
> The script can check that the user is permitted and provide the appropriate 
> form then do the operation
> on the user's behalf. The script can use the $doc.saveAsAuthor() function to 
> do that.
> 
> Caleb
> 
> On 09/21/2011 07:31 PM, Sergiu Dumitriu wrote:
> > On 09/21/2011 10:09 AM, Haru Mamburu wrote:
> >> Hi!
> >>
> >> So, this "feature" makes absolutely useless delete rights, for example, if 
> >> each and every user with edit rights can easily skip Delete and Admin 
> >> Prohibition. Actually edit right behaves like admin in the allowed space. 
> >> As for me it looks a little bit wierd.
> >
> > Well, delete rights are not that relevant actually. By default only the
> > document's creator can delete a document. So, unless you explicitly give
> > delete rights to somebody, they'll only be able to delete their own
> > documents.
> >
> >> All users by default are simple, but as you mentioned, nothing stops the 
> >> intruder with edit rights if he knows magic of URLs.
> >>
> >> For me it looks logical, that if I PROHIBITED right to delete or Admin 
> >> rights - it means prohibited, but not "don't pay attention'.
> >
> > The delete and admin rights don't normally work on page level anyway,
> > it's pretty hard to get hold of them if they're not explicitly granted.
> >
> > If you want finer grained security, you can implement them in Java, not
> > as normal access rights, but as guard checks blocking actions according
> > to your own custom rules.
> >
> >> For security it means VERY big black whole. And actually we don't have any 
> >> instrument to track or stop it (besides watching pages). For semi-open 
> >> projects, or even open, like Wikipedia it creates paradise for vandals, 
> >> even if you open edit rights only for registered users. Once you can find 
> >> couple of hundreds pages in Recycle bin even if nobody but Admin has 
> >> ability to delete pages. :-)
> >> And actually rights management contradicts wit 6 user types concept 
> >> http://dev.xwiki.org/xwiki/bin/view/Design/6TypesOfXWikiUsers
> >>
> >> So, my proposal is: discuss and implement more precise rights management 
&

Re: [xwiki-users] Access rights management bug?

[Haru Mamburu]

Thanks a lot for explanation, 

So, as far as I understood, scenario is:

- Space of the document has only view right for Group1. Our user is a member of 
Group1.
- This user tries to edit the document in edit/inline mode by pressing the 
link/button generated somwhere else, not in required page.
- Required page checks if our user belongs to Group1 and if true - opens 
document as a user with real edit rights
- User in Group1 edits properties in inline mode. On pressing submit button 
script saves page as our edit-mode-user.
- Finally Group1 user again has no edit rights and no edit menu options.

In this case some behaviour is still unclear:
- Logic says to me that access rights are checked before script will run. If 
yes, no way to run edit mode in our case.
- If user presses button Save & view instead of form Submit button, what 
happens? Again, there is no way to script to save page with  
$doc.saveAsAuthor()  function.

Am I missing something? 

The second scenario loks more clear for me if scripts do ALL the job:
- Required page Checks rights
- Asks user via form if he wants to edit page
- Sends user to ANOTHER page
- This "another" page obtains all necessary data from the object properties of 
required page.
-  builds form and gives pseudo-inline mode to our user.
- saves document on submit on behalf of user with edit rights.
- redirects back to saved required page (by the way, redirect doesn't eat 
cyrillic names, and for now I don't know how to get it round)

And in this case ALL pages for User from Group1 would be accessible only in 
XWiki's native view mode. 
This scenario gives a "guarantee" and deep feeling of "safe wiki" for admin , 
but also gives a lot of additional programming. 

And as far as I got - this is the only way to build  ''smart -user-resistant' 
application. :-) 
But still, I'd prefer to manage all these rights via default XWiki application.

Kind regards,

Dmitry Bakbardin



23 сентября 2011, 11:30 от Caleb James DeLisle :
> Another way that you can get the results you are looking for is to write a 
> script which does the editing
> on the user's behalf. If the script document is saved by someone who has 
> permission to edit the
> document which the user wants to edit and the user needs to be able to, for 
> example: edit only the content
> of an object but not add or remove objects or change the document's main 
> content.
> The script can check that the user is permitted and provide the appropriate 
> form then do the operation
> on the user's behalf. The script can use the $doc.saveAsAuthor() function to 
> do that.
> 
> Caleb
> 
> On 09/21/2011 07:31 PM, Sergiu Dumitriu wrote:
> > On 09/21/2011 10:09 AM, Haru Mamburu wrote:
> >> Hi!
> >>
> >> So, this "feature" makes absolutely useless delete rights, for example, if 
> >> each and every user with edit rights can easily skip Delete and Admin 
> >> Prohibition. Actually edit right behaves like admin in the allowed space. 
> >> As for me it looks a little bit wierd.
> >
> > Well, delete rights are not that relevant actually. By default only the
> > document's creator can delete a document. So, unless you explicitly give
> > delete rights to somebody, they'll only be able to delete their own
> > documents.
> >
> >> All users by default are simple, but as you mentioned, nothing stops the 
> >> intruder with edit rights if he knows magic of URLs.
> >>
> >> For me it looks logical, that if I PROHIBITED right to delete or Admin 
> >> rights - it means prohibited, but not "don't pay attention'.
> >
> > The delete and admin rights don't normally work on page level anyway,
> > it's pretty hard to get hold of them if they're not explicitly granted.
> >
> > If you want finer grained security, you can implement them in Java, not
> > as normal access rights, but as guard checks blocking actions according
> > to your own custom rules.
> >
> >> For security it means VERY big black whole. And actually we don't have any 
> >> instrument to track or stop it (besides watching pages). For semi-open 
> >> projects, or even open, like Wikipedia it creates paradise for vandals, 
> >> even if you open edit rights only for registered users. Once you can find 
> >> couple of hundreds pages in Recycle bin even if nobody but Admin has 
> >> ability to delete pages. :-)
> >> And actually rights management contradicts wit 6 user types concept 
> >> http://dev.xwiki.org/xwiki/bin/view/Design/6TypesOfXWikiUsers
> >>
> >> So, my proposal is: discuss and implement more precise rights management 
&

Re: [xwiki-users] Access rights management bug?

[Haru Mamburu]

Hi!

So, this "feature" makes absolutely useless delete rights, for example, if each 
and every user with edit rights can easily skip Delete and Admin Prohibition. 
Actually edit right behaves like admin in the allowed space. As for me it looks 
a little bit wierd.

All users by default are simple, but as you mentioned, nothing stops the 
intruder with edit rights if he knows magic of URLs.

For me it looks logical, that if I PROHIBITED right to delete or Admin rights - 
it means prohibited, but not "don't pay attention'. 
For security it means VERY big black whole. And actually we don't have any 
instrument to track or stop it (besides watching pages). For semi-open 
projects, or even open, like Wikipedia it creates paradise for vandals, even if 
you open edit rights only for registered users. Once you can find couple of 
hundreds pages in Recycle bin even if nobody but Admin has ability to delete 
pages. :-)
And actually rights management contradicts wit 6 user types concept 
http://dev.xwiki.org/xwiki/bin/view/Design/6TypesOfXWikiUsers

So, my proposal is: discuss and implement more precise rights management system 
in the neares future. Let's make XWiki more safe :-)

Thnks a lot for help,

Dmitry


21 сентября 2011, 17:39 от Guillaume Lerouge :
> Hi Dmitry,
> 
> unfortunately for your use case this is a feature of XWiki. When a user is
> granted edit right on a page, he is allowed to edit any object attached to
> that page (this is used through the "edit inline" mode as well, when editing
> in inline mode the user is actually updating the values of object properties
> in the page.
> 
> One way to work around this is by making all users "simple users" by default
> so that the menus do not display the advanced edit options. However, users
> that know the right URLs will still be able to access the object edition
> mode.
> 
> In short: sorry but no, not "safe" the way you mean it :-(
> 
> Guillaume
> 
> On Sat, Sep 17, 2011 at 6:57 AM, Haru Mamburu  wrote:
> 
> >
> > Dear Users,
> >
> > XE 3.1. Playing with rights I found very unpleasant and IMO dangerous
> > behaviour.
> >
> > Two Default groups: XWikiAllGroup and XWikiAdminGroup
> >
> > Admin gives rigths to XWikiAllGroup to view pages - no problem.
> > Admin gives rigths to XWikiAllGroup to EDIT pages. From my point of view -
> > EDIT means only page EDIT in edit/inline mode,
> > but not:
> > - managing page access rights
> > - editing in editor object mode.
> >
> > I even tried to prohibit to XWikiAllGroup users Administration rights,
> > nothing changed. As for my project - it is a disaster.
> > I must separate four categories of users:
> > 1. All users - have View access to definite spaces.
> > 2. SOME registered users - have edit rights for spaces/pages (edit/inline),
> > create rights. BUT NO Access rights management, NO object mode editing)
> > 3. Admin Users with Admin rights on several spaces to delete/undelete pages
> > AND access rights management.
> > 4. XWiki Admin
> >
> > As I discovered, I can't get split second and third group. :-(
> >
> > It would be wise to avoid rights management and object editing mode
> > availability to "smart" users, that can bring a mess into the system in
> > couple of seconds. For example, "smart user" with edit rights will easily
> > prohibit access to pages to whole XWikiAllGroup OR he even can grant  VIEW
> > rights ONLY  to  XWikiAdminGroup with the same results - page becomes
> > inaccessible to non-admin users. I checked everything with a Test user in
> > XWikiAllGroup.
> >
> > I don't know if it is a bug or a feature, but for me it's a disaster :-(
> >
> > Is there any way to make XWiki project safe?
> >
> > Best Regards
> >
> > Dmitry Bakbardin
> > ___
> > 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
> 
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] How to delete Deleted Attachments while FS is on?

[Haru Mamburu]

Hi!

XEM 3.1. I turned on filesystem storage, attached file, then deleted it.

Due to http://jira.xwiki.org/browse/XWIKI-6918 and no acces via WebDAV yet 
(http://jira.xwiki.org/browse/XWIKI-6989) - there is no way to review deleted 
attachments in recycle bin and delete it. As far as I understand - manual 
delition via filesystem operations is wrong way to do this because of lost 
metadata.

Is there any way to delete deleted attachments correctly until XWIKI-6918 would 
be fixed and XE would upgraded to fixed one? 

Kind regards

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

Re: [xwiki-users] WebDav

[Haru Mamburu]

Hi!

I used to play with WebDav and Total Commander's plugin 
http://ghisler.fileburst.com/fsplugins/webdav.zip 
Enter URL like this:
url/xwiki 
or
url:port/xwiki
Then it connects fine. Also, try to play with UTF-8 options to read pages 
correctly (if you have problems)

The only problem I found: there is no Deleted attachments in WebDav access. Am 
I missing something?

Dmitry Bakbardin


20 сентября 2011, 16:19 от Gerritjan Koekkoek :
> I do understand it is a feature always on?
> 
> I did a little test with mac os x lion, finder, go to server
> I entered http://[url] without www.
> 
> But how do I Identify myself and what rights are exposed, I assume the same 
> rights the user has on the Wiki?
> Or should I use another webDAv client?
> 
> Op 20 sep. 2011, om 13:02 heeft Vincent Massol het volgende geschreven:
> 
> >
> > On Sep 20, 2011, at 12:51 PM, Gerritjan Koekkoek wrote:
> >
> >> On the xwiki.org there is a feature on XWiki presented;
> >> The WebDAV feature exposes wiki content (attachments, page content) 
> >> through the well-known WebDAV protocol.
> >> This allows using WebDAV clients like DAVExplorer, file browsers like the 
> >> Windows Explorer (XP), the Finder (MAC) or
> >> Nautilus (Linux) to directly browse and edit wiki content just as you 
> >> would do for files in your local file system.
> >>
> >> Does this feature require configuration of the server.
> >
> > No
> >
> >> Do I understand that by dropping photo's in a folder I could add photo's 
> >> the the XWiki photoalbum
> >
> > Yes
> >
> >> although the XWiki stores all the attachments in a mySql database?
> >
> > XWiki stores attachment where you've defined it. By default it's in the 
> > database (any DB supported by Hibernate, doesn't have to be MySQL).
> > See http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Attachments
> >
> > Thanks
> > -Vincent
> >
> >>
> >> We have a server on version 2.7.1
> >>
> >> Gerritjan
> >
> > ___
> > 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
> 
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] XWiki vs. cyrillics

[Haru Mamburu]

Dear developers,

Recently I had been checking each and every step in XWiki cyrillic management. 

Brief results from last to least:

1. Office integration: no way to work with cyrillic page names 
http://jira.xwiki.org/browse/XOFFICE-252
2. Eclipse:: no way to work with cyrillic space names 
http://jira.xwiki.org/browse/XECLIPSE-154
3. $response.sendRedirect() gives ??? instead of cyrillic letters, so some 
scripts become useless, Parent Page search suggest in edit mode gives ??? 
instead of cyrillic  http://jira.xwiki.org/browse/XWIKI-6955

The rest works fine, or I didn't discover it yet :-

As far as I understand XWiki, all these bug should live somewhere in the core, 
maybe somewhere else also and it's not so trivial to fix it.

The question is: what are priorities in XWiki development and is it planned to 
make cyrillic users happy to use all XWiki features available in nearest future?

Thanks a lot for understanding. 

Kind regards.

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

[xwiki-users] Access rights management bug?

[Haru Mamburu]

Dear Users,

XE 3.1. Playing with rights I found very unpleasant and IMO dangerous behaviour.

Two Default groups: XWikiAllGroup and XWikiAdminGroup

Admin gives rigths to XWikiAllGroup to view pages - no problem.
Admin gives rigths to XWikiAllGroup to EDIT pages. From my point of view - 
EDIT means only page EDIT in edit/inline mode, 
but not:
- managing page access rights
- editing in editor object mode.

I even tried to prohibit to XWikiAllGroup users Administration rights, nothing 
changed. As for my project - it is a disaster. 
I must separate four categories of users:
1. All users - have View access to definite spaces.
2. SOME registered users - have edit rights for spaces/pages (edit/inline), 
create rights. BUT NO Access rights management, NO object mode editing)
3. Admin Users with Admin rights on several spaces to delete/undelete pages AND 
access rights management.
4. XWiki Admin 

As I discovered, I can't get split second and third group. :-(

It would be wise to avoid rights management and object editing mode 
availability to "smart" users, that can bring a mess into the system in couple 
of seconds. For example, "smart user" with edit rights will easily prohibit 
access to pages to whole XWikiAllGroup OR he even can grant  VIEW rights ONLY  
to  XWikiAdminGroup with the same results - page becomes inaccessible to 
non-admin users. I checked everything with a Test user in XWikiAllGroup.

I don't know if it is a bug or a feature, but for me it's a disaster :-(

Is there any way to make XWiki project safe?

Best Regards

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

Re: [xwiki-users] "Cyryllic bug" in scripting

[Haru Mamburu]

Thanks a lot for help.

I'm not using xwiki.org for tests (but now I do understand why cyrillic letters 
disappear on xwiki.org :-)

All test were done on standalone XWiki 3.1 on Windows. A don't have a clue how 
to check encodings in there: Admin.Tools configuration check failed to run, but 
cyrillic space names and page names works fine, despite of the facts described 
below.

All test were done once more on Glassfish+MySQL+XWiki 3.1 with exactly the same 
results. Cyrillic space names and page names works fine, despite of the facts 
described below also.

XWiki: Admin.Tools configuration check says following:
General db settings
MYSQL encoding setting character_set_client: utf8mb4
MYSQL encoding setting character_set_connection: utf8mb4
MYSQL encoding setting character_set_database: utf8
MYSQL encoding setting character_set_filesystem: binary
MYSQL encoding setting character_set_results:
MYSQL encoding setting character_set_server: utf8
MYSQL encoding setting character_set_system: utf8

General db collation settings
MYSQL collation setting collation_connection: utf8mb4_general_ci
MYSQL collation setting collation_database: utf8_general_ci
MYSQL collation setting collation_server: utf8_general_ci

MySQL connector is set "inside" XWiki (not present in Glassfish)

Glassfish URI Encoding is set to UTF-8

That's everything I understand, what you advised me to check.

Best Regards,

Dmitry Bakbardin



12 сентября 2011, 10:32 от Vincent Massol :
> 
> On Sep 12, 2011, at 5:05 AM, Haru Mamburu wrote:
> 
> > Dear Users,
> >
> > I found bug with cyrillic letters in velocity Scripting. Does it happen 
> > only with cyrillic?
> > http://jira.xwiki.org/browse/XWIKI-6955
> >
> > Something similar was found in this extention 
> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Extract+Wikipedia+Article+Introduction
> > I wrote a comment to the page. Should I report it as a bug, or its not 
> > supported by XWiki development team?
> 
> It's simply that xwiki.org's DB is currently configured in iso 8859-1 instead 
> of UTF8 AFAIK.
> 
> Are you sure **all** your subsystems are correctly configured in UTF8:
> - your servlet container
> - your database
> - your xwiki instance
> ?
> 
> > Cyrillic users would be unhappy if scripting has such "other languages" 
> > limitations. :-(
> > Is it possible to fix this somehow?
> 
> Yes see above.
> 
> Thanks
> -Vincent
> 
> >
> > As to: http://jira.xwiki.org/browse/XWIKI-6955 
> > Same Script again. The question is:
> >
> > If you enter "Smith John" in the input field,  script creates page 
> > "SmithJohn". Is it possible somehow to keep the space mark between Last 
> > name and first name in the page name after script?
> >
> > Thanks in advance
> >
> > Dmitry Bakbardin
> 
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] "Cyryllic bug" in scripting

[Haru Mamburu]

Dear Users, 

I found bug with cyrillic letters in velocity Scripting. Does it happen only 
with cyrillic? 
http://jira.xwiki.org/browse/XWIKI-6955

Something similar was found in this extention 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Extract+Wikipedia+Article+Introduction
I wrote a comment to the page. Should I report it as a bug, or its not 
supported by XWiki development team?

Cyrillic users would be unhappy if scripting has such "other languages" 
limitations. :-( 
Is it possible to fix this somehow? 

As to: http://jira.xwiki.org/browse/XWIKI-6955 
Same Script again. The question is: 

If you enter "Smith John" in the input field,  script creates page "SmithJohn". 
Is it possible somehow to keep the space mark between Last name and first name 
in the page name after script?

Thanks in advance

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

Re: [xwiki-users] Filesystem Storage backup, clustering, mirroring

[Haru Mamburu]

Thanks a lot for for assistance, Ludovic. 
Looks complicated, but at first glance at least manageable. 
Will you recommend any Java-based sync tools to build completely platform 
independent system?

Ideal solution for me looks smth like: 
- Master Wiki accepts file and stores it in FS storage
- Master Wiki initiates an event and sends it to Sync Tool / Mirror Wiki
- Sync Tool / Mirror Wiki requests file, gets it, stores it and writes success 
sync event in log.

Do we need to tie XWiki events with sync events, or it is safe for XWiki, when 
mirror database has a  "new-file" record and file is not in the storage yet?

"1/ A redundant RAID5 network storage shared over Fiber Channel and NFS. This 
is for clustering"

Is it possible to configure XWiki to use ANY folder as a storage, OR default 
one is an only option?  If Yes, HOW?

Some bugs are found in 3.1 with FS on. It causes attachment  management 
problems.
http://jira.xwiki.org/browse/XWIKI-6918
http://jira.xwiki.org/browse/XWIKI-6917

Is there any fast solution? Or there is no simple solution and we should wait 
at least 3.2 release to manage attachments? Because for now, we don't have 
"legal" XWiki access to deleted attachments.

Best Regards,

Dmitry Bakbardin


09 сентября 2011, 12:51 от Ludovic Dubost :
 
  
  

Hi Haru,

2011/9/9 Haru Mamburu 

Hi!

I was going to  build on the XEM base a library with files 1Kb-1Gb inside . But 
on digging deeper I'm a bit desperate now: XE is an excellent platform to run 
the project from one side, from other - completely unclear how to make it safe 
:-(

Great that you working on a big database with XEM.. Sounds like a nice project

File System storage does have it's drawback, which is why we initially chose to 
be "all-database", but we faced the limitation of database storage for very 
large attachments..
Backup and Clustering are indeed more complex, but it's possible..


On filesystem storage implementation, there are several sufficient question are 
still beyond of understanding:

1. Clustering and/or mirroring XWiki.

When data was stored completely in the Database Engine - it was more or less 
clear how to build following system:

Customers -> Master Server --> Mirror Server

If  Master Server is down - we easily switch customers to Mirror Server. 
Afterwards we restore full configuration and get back necessary redundancy.

With filesystem storage mirroring mission becomes impossible?


I suggest either

1/ A redundant RAID5 network storage shared over Fiber Channel and NFS. This is 
for clustering
2/ A "rdist" process that will replicate regularly the FS for mirroring only

  2. Backup process.

Database data backup is also more or less clear. When filesystem storage turned 
on, there is painful moment of synchronizing backup moment both for data in 
Database AND data in Filesystem. The only Idea I have for now: stop everything, 
backup everything, run everything. IMO it's not the best solution due to quite 
annoying downtime.
  Are you going to implement such a functionality inside? What is the best 
pactice to implement backup in a right way?

I would suggest:

1/ rdist replication + mysql replication
2/ when backuping, blocking both replication and performing the backup

At XWiki SAS we always use a MySQL replication which is the DB being backed-up. 
This is important to have the minimal impact on the production system. If you 
backup the production database directly you can have locking issues that block 
XWiki from operating properly.

Ludovic
 

  If you already have a solution, kindly ask you to share the information. :-)

Best regards,

Dmitry Bakbardin


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



-- 
Ludovic Dubost 
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost 
   
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] Filesystem Storage backup, clustering, mirroring

[Haru Mamburu]

Hi!

I was going to  build on the XEM base a library with files 1Kb-1Gb inside . But 
on digging deeper I'm a bit desperate now: XE is an excellent platform to run 
the project from one side, from other - completely unclear how to make it safe 
:-(

On filesystem storage implementation, there are several sufficient question are 
still beyond of understanding:

1. Clustering and/or mirroring XWiki.

When data was stored completely in the Database Engine - it was more or less 
clear how to build following system:

Customers -> Master Server --> Mirror Server 

If  Master Server is down - we easily switch customers to Mirror Server. 
Afterwards we restore full configuration and get back necessary redundancy.

With filesystem storage mirroring mission becomes impossible?

2. Backup process. 

Database data backup is also more or less clear. When filesystem storage turned 
on, there is painful moment of synchronizing backup moment both for data in 
Database AND data in Filesystem. The only Idea I have for now: stop everything, 
backup everything, run everything. IMO it's not the best solution due to quite 
annoying downtime.
 Are you going to implement such a functionality inside? What is the best 
pactice to implement backup in a right way?

If you already have a solution, kindly ask you to share the information. :-)

Best regards,

Dmitry Bakbardin


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

Re: [xwiki-users] file operations in file system storage is too slow

[Haru Mamburu]

Thanks a lot for help,

No way to disable recycle bin. If some vandals would ruin content and delete 
attachments - it would be lost without possibility to get it back.
Move operations usually take milliseconds despite of file size. By accident I 
found a reason of such slow down: XE makes TWO copies of the file in recycle 
bin (in the file storage). 

Should I report it as a bug of file storage?

Kind regards,

Dmitry Bakbardin


05 сентября 2011, 22:35 от Sergiu Dumitriu :
 
  
  
On 09/05/2011 12:10 AM, Haru Mamburu wrote:
>
> HI!
>
> Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, 
> Works fine with relatively small files.
> I uploaded 700M file - no problem, a bit to wait, but works fine.
> I tried then to delete this file. The result was also successful, but took 
> nearly 1.5 minutes to finish. Is there any way to run file operations faster?
>

Deleting an attachment will save the file in the attachment trash, which 
means copying the file in another place. You could try to disable the 
attachment trash to get a faster result, if you don't care about rolling 
back deleted attachments.

The time spent seems reasonable given that it involves disk I/O and a 
fairly large file. What could be done to improve responsiveness is to do 
all the work in the background, i.e. just start the file copy process 
and instantly resume the work. This means more work to ensure that 
future requests affecting that file won't interfere in a bad way.

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
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] Download resume for large files - no way?

[Haru Mamburu]

Thanks a lot,

I put the "resume feature" request into Jira. :-)
File system storage is implemented and now I'm precisely looking for the right 
way to use XE in a kind of  non-profit library project, where attachments could 
be from 1KB to approx 1Gb in one piece. That is why I'm doing field test to 
avoid surprises in the nearest future. 
My first preliminary conclusion: it's worth to use XE in such a way, but for 
now there are too many things go unusual way to use XE as is. I'm going to run 
project anyway, so would be glad for futher cooperation to make file storage 
and big files operation more seamless both for administrators and end-users.

Kind regards

Dmitry


05 сентября 2011, 22:30 от Sergiu Dumitriu :
 
 
  
  
On 09/04/2011 10:02 PM, Haru Mamburu wrote:
>
> Hi!
>
> By default, XWiki doesn't have "resume" ability for downloads. Is there any 
> way to turn it on? From the moment file system storage was implemented into 
> XE it makes sence.

It's not implemented yet, but it could easily be implemented yet if 
there's demand for this feature.

> And another question-idea:
> On uploading big (all) files, XWiki creates hash for torrent, stores it 
> together with file.
> On Download request - user gets torrent file and starts download.
> Server side strats seeding and after download is complete - kills seeding 
> process from torrent-client.
> Upload can be done almost the same way.
>
> The question is:
> Does existing XWiki functionality allow to implement such a upload-download 
> technology?

Well, since it's Java, anything should be possible given the right 
amount of time. Being Open Source, any feature can get implemented if 
there's enough need for it, but for the moment there haven't been any 
requests for such thing, so the best way to see this committed is to 
come up with patches.

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

[xwiki-users] Deleted Attachments in filesystem Storage

[Haru Mamburu]

Hi!

Xwiki 3.1. Attachment versioning turned off 
(xwiki.store.attachment.versioning.hint = void)
Storage is set to file system, Recicle Bin is ON.

1. xwiki/bin/view/Main/AllDocs?view=attachments  - gives empty table. How one 
can see all attachments in a Live table?

2. To verify attachment versioning: attach several times the same file - one 
copy is stored as a file in a storage, version upgrades correctly - no problem.

3. I deleted an attachment. It shoild be in recycle bin:
~GLOBAL_DELETED_ATTACHMENT_ID_MAPPINGS.xml appeared in  /store folder.
XML inside shows were to find files. Files are on their places as descriebed.

BUT

Recycle bin gives terrible surprise: it stores TWO COPIES of deleted file:
first is: .
second is: ~v1.1.

Please note, that attachment VERSIONING is turned OFF. For big attachments (1GB 
and more) such a behaviour is a disaster for two reasons:
- unreasonable disk space consumption
- (probably) huge delay while user deleting attachment.

What is correct way to disallow XWiki such file duplication?

4. XWiki.DeletedAttachments gives empty table. How one can see all deleted 
attachments in a Live table?

Thanks a lot

Dmitry Bakbardin



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

[xwiki-users] file operations in file system storage is too slow

[Haru Mamburu]

HI!

Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, 
Works fine with relatively small files.
I uploaded 700M file - no problem, a bit to wait, but works fine.
I tried then to delete this file. The result was also successful, but took 
nearly 1.5 minutes to finish. Is there any way to run file operations faster?

Thanks a lot.

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

[xwiki-users] Download resume for large files - no way?

[Haru Mamburu]

Hi!

By default, XWiki doesn't have "resume" ability for downloads. Is there any way 
to turn it on? From the moment  file system storage was implemented into XE it 
makes sence. 
And another question-idea:
On uploading big (all) files, XWiki creates hash for torrent, stores it 
together with file.
On Download request - user gets torrent file and starts download.
Server side strats seeding and after download is complete - kills seeding 
process from torrent-client.
Upload can be done almost the same way. 

The question is: 
Does existing XWiki functionality allow to implement such a upload-download 
technology?

Thanks in advance,

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

Re: [xwiki-users] applications in wiki-farm fail to run

[Haru Mamburu]

Thanks a lot  for help,

I just updated documentation on this issue. You're welcome to improve it.

http://manager.xwiki.org/xwiki/bin/view/AdminGuide/Application+installation+into+wiki-farm

If somebody would give me a clue to define this subject as bug, I'd  "jira" it 
also :-)

Best regards,

Dmitry Bakbardin

02 сентября 2011, 12:15 от AngeloG :
 
  
  

Haru Mamburu wrote:
> 
> By accident I found the solution, but as for me it looks a bit wierd for
> everyday usage.
> 
> 1. Import in main wiki Admin Tools
> http://extensions.xwiki.org/xwiki/bin/view/Extension/AdminTools with the
> User with programming rights.
> 2. Run the page Admin.CheckProgrammingRights
> 3. Confirm programming rights by pressing the link "Confirm give
> programming rights"
> 4. If everything successful, we can see following (note, that wiki is only
> with standard pack of pages):
> * fixing Main.Spaces
> * fixing Main.Activity
> * fixing AnnotationCode.Style
> * fixing AnnotationCode.Script
> * fixing AnnotationCode.Settings5. Checking Annotation application on wiki
> farms gives positive result - it works.
> 
> I don't know is it a bug of XEM or a feature, but probably it worth to do
> smth with such a complicated process and/or update documentation if it
> should work this way. Is there any less wierd way to make applications
> running?
> Hope, somebody will give a solution :-)
> 
> Thanks a lot
> 
> Dmitry Bakbardin
> 
> 
> 01 сентября 2011, 20:00 от Haru Mamburu <haru_mamb...@mail.ru>:
> 
> 
> 
>  Thanks a lot for help.
>  
>  Now step by step.
>  1. XE installation - Annotations works fine
>  2. XEM installation - Annotations works fine
>  3. templatexe deployment (xwiki/bin/view/XemManager/Install) -
> Annotations disappears in templatexe farm. 
>  4. "test" wiki-farm deployment from templatexe template, installation of
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application
> according to instuctions. 
>  
>   Result the same - no annotations found in wiki-farm. :-(
>  
>   Is there any way to install smth. in main wiki and just "allow"
> application in a specific farm?
>  
>   Thanks in advance.
>  
>   Dmitry Bakbardin
> 
> 
> 01 сентября 2011, 12:15 от Vincent Massol <vinc...@massol.net>:
> 
> 
> 
> Hi Dmitry,
> 
> On Aug 31, 2011, at 6:19 PM, Haru Mamburu wrote:
> 
>> Hi!
>> 
>> Xwiki 3.1. Latest XEM works fine, deploys wiki farms - no problem.
>> All attempts to make applications running on wiki-farm failed (e.g.
>> Annotations).
>> Documentation keeping silence, or I'm missing something. :-(
>> 
>> Is there any way to make applications running on non-main wikis?
>> Is there a way to install application in main wiki and "grant permission"
>> to be used in specific wiki-farm?
> 
> All applications can be installed in all wikis. That should work fine.
> 
> Annotations are installed by default so I'm not sure what you are
> installing…
> 
> We need more details of the steps you're following and the issues you're
> seeing.
> 
> Thanks
> -Vincent
> 
>> Thanks a lot in advance
>> 
>> Dmitry Bakbardin
> 
> 
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
> 

Hi,
for what I know when you create a subwiki, may be using the default
template, it is empty. So unless you have already your own template ready,
the best thing is to log in in the subwiki and import the default xar
containing the default pages (you need to import XE pages in the subwikis
and not the XEM pages).
After doing this it is possible that annotation still don't work in the
subwiki.
***
This is because the javascript and style (CSS) that enable the
annotations need to be saved with programming rights
(AnnotationCode.Style, AnnotationCode.Script, AnnotationCode.Settings).
In order to do that, just login with a user with programming rights, go
to those documents, edit and save with no changes. 
(thanks to Anca Luca for this solution).
***
This worked for me, I hope it can help you

Angelo

--
View this message in context: 
http://xwiki.475771.n2.nabble.com/applications-in-wiki-farm-fail-to-run-tp6747170p6753116.html
Sent from the XWiki- Users mailing list archive at Nabble.com.
___
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] applications in wiki-farm fail to run

[Haru Mamburu]

By accident I found the solution, but as for me it looks a bit wierd for 
everyday usage.

1. Import in main wiki Admin Tools 
http://extensions.xwiki.org/xwiki/bin/view/Extension/AdminTools with the User 
with programming rights.
2. Run the page Admin.CheckProgrammingRights
3. Confirm programming rights by pressing the link "Confirm give programming 
rights"
4. If everything successful, we can see following (note, that wiki is only with 
standard pack of pages):
* fixing Main.Spaces
* fixing Main.Activity
* fixing AnnotationCode.Style
* fixing AnnotationCode.Script
* fixing AnnotationCode.Settings5. Checking Annotation application on wiki 
farms gives positive result - it works.

I don't know is it a bug of XEM or a feature, but probably it worth to do smth 
with such a complicated process and/or update documentation if it should work 
this way. Is there any less wierd way to make applications running?
Hope, somebody will give a solution :-)

Thanks a lot

Dmitry Bakbardin


01 сентября 2011, 20:00 от Haru Mamburu :
 
  
  
 Thanks a lot for help.
 
 Now step by step.
 1. XE installation - Annotations works fine
 2. XEM installation - Annotations works fine
 3. templatexe deployment (xwiki/bin/view/XemManager/Install) - Annotations 
disappears in templatexe farm. 
 4. "test" wiki-farm deployment from templatexe template, installation of 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application 
according to instuctions. 
 
  Result the same - no annotations found in wiki-farm. :-(
 
  Is there any way to install smth. in main wiki and just "allow" application 
in a specific farm?
 
  Thanks in advance.
 
  Dmitry Bakbardin


01 сентября 2011, 12:15 от Vincent Massol :
 
  
  
Hi Dmitry,

On Aug 31, 2011, at 6:19 PM, Haru Mamburu wrote:

> Hi!
> 
> Xwiki 3.1. Latest XEM works fine, deploys wiki farms - no problem.
> All attempts to make applications running on wiki-farm failed (e.g. 
> Annotations).
> Documentation keeping silence, or I'm missing something. :-(
> 
> Is there any way to make applications running on non-main wikis?
> Is there a way to install application in main wiki and "grant permission" to 
> be used in specific wiki-farm?

All applications can be installed in all wikis. That should work fine.

Annotations are installed by default so I'm not sure what you are installing…

We need more details of the steps you're following and the issues you're seeing.

Thanks
-Vincent

> Thanks a lot in advance
> 
> Dmitry Bakbardin
   
   
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] applications in wiki-farm fail to run

[Haru Mamburu]

 Thanks a lot for help.
 
 Now step by step.
 1. XE installation - Annotations works fine
 2. XEM installation - Annotations works fine
 3. templatexe deployment (xwiki/bin/view/XemManager/Install) - Annotations 
disappears in templatexe farm. 
 4. "test" wiki-farm deployment from templatexe template, installation of 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application 
according to instuctions. 
 
  Result the same - no annotations found in wiki-farm. :-(
 
  Is there any way to install smth. in main wiki and just "allow" application 
in a specific farm?
 
  Thanks in advance.
 
  Dmitry Bakbardin


01 сентября 2011, 12:15 от Vincent Massol :
 
  
  
Hi Dmitry,

On Aug 31, 2011, at 6:19 PM, Haru Mamburu wrote:

> Hi!
> 
> Xwiki 3.1. Latest XEM works fine, deploys wiki farms - no problem.
> All attempts to make applications running on wiki-farm failed (e.g. 
> Annotations).
> Documentation keeping silence, or I'm missing something. :-(
> 
> Is there any way to make applications running on non-main wikis?
> Is there a way to install application in main wiki and "grant permission" to 
> be used in specific wiki-farm?

All applications can be installed in all wikis. That should work fine.

Annotations are installed by default so I'm not sure what you are installing…

We need more details of the steps you're following and the issues you're seeing.

Thanks
-Vincent

> Thanks a lot in advance
> 
> Dmitry Bakbardin
   
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] applications in wiki-farm fail to run

[Haru Mamburu]

Hi!

Xwiki 3.1. Latest XEM works fine, deploys wiki farms - no problem.
All attempts to make applications running on wiki-farm failed (e.g. 
Annotations).
Documentation keeping silence, or I'm missing something. :-(

Is there any way to make applications running on non-main wikis?
Is there a way to install application in main wiki and "grant permission" to be 
used in specific wiki-farm?

Thanks a lot in advance

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

Re: [xwiki-users] Attachments-RAM dependencies, anchors, TOC

[Haru Mamburu]

Thank you, Marius, I will try now and leave feature request also  :-)


Tue, 07 Dec 2010 12:07:36 +0200 письмо от Marius Dumitru Florea 
:

> On 12/07/2010 01:55 AM, Haru Mamburu wrote:
> > Hi!
> >
> > Kindly ask you to solve some unclear topics:
> >
> > I. How can I find information about such dependencies:
> > - How many server RAM memory is required for each 1GB of attachments?
> > - The same for CPU.
> > How to estimate this and calculate hardware? What are main principles?
> >
> 
> > II. Is it possible to customise WYSIWYG editor separetly for each space
> in one sub-XWiki ?
> 
> You can edit the wysiwyg_storeConfig velocity macro found in 
> templates/macros.vm so that it takes the value of the WYSIWYG editor 
> configuration parameters from space preferences. For instance:
> 
> #set($ok = $parameters.put('menu', 
> $xwiki.getSpacePreference('wysiwyg.menu', 'link image table macro
> import')))
> 
> See 
> http://nexus.xwiki.org/nexus/service/local/repositories/releases/archive/com/xpn/xwiki/platform/xwiki-core/2.6/xwiki-core-2.6-javadoc.jar/!/com/xpn/xwiki/api/XWiki.html#getSpacePreference%28java.lang.String,%20java.lang.String%29
> 
> Then you have to add the corresponding properties (i.e.
> 'wysiwyg.menu') 
> to SpaceName.WebPreferences page (where 'SpaceName' is the space where
> you want the WYSIWYG editor to be customised).
> 
> You can do this for any WYSIWYG editor configuration parameter. For the 
> full list, see 
> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/WysiwygEditor#HConfigurationParameters
> .
> 
> >
> > III. Is there any way to manage anchors from Links plugin in WYSIWYG
> editor?
> >The logic is:
> > - select space
> > - select page
> > - select anchor on this page
> > - put the link
> 
> This is not possible right now through the WYSIWYG editor UI. You can 
> open a feature request on jira.xwiki.org
> 
> Hope this helps,
> Marius
> 
> >
> > For now, even if I write down XWiki.WebHome#anchor in the link field
> manually, I get #anchor cut out.
> > And the only way to do it via source code editor manually. Then it works
> fine. Personally me found more or less suitable solution with FF plugin
> https://addons.mozilla.org/ru/firefox/addon/416/
> > It's very easy to get anchor, but not so easy to put it. For
> unqualified users it makes XWiki "one-handed".
> >
> > IV. Is there any way to make TOC macro to build table of contents of
> several pages and put it on one page?
> > For Example:
> > toc Page1, Page2, Page3 
> >
> > It's very useful, when one can group all project highligts together
> in one TOC.
> > I used to use Track Wiki, it works excellent in there. I suffer from
> it's absence now :-)
> >
> > Thank you
> >
> > Dmitry Bakbardin
> >
> > ___
> > 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

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

Re: [xwiki-users] Attachments-RAM dependencies, anchors, TOC

[Haru Mamburu]

Thank you very much, in general - it's more than clear. 
Now I'm almost ready to master both science and art of XWiki setup :-)


Mon, 06 Dec 2010 19:11:45 -0500 письмо от Caleb James DeLisle 
:

> 
> 
> On 12/06/2010 06:55 PM, Haru Mamburu wrote:
> > Hi!
> > 
> > Kindly ask you to solve some unclear topics:
> > 
> > I. How can I find information about such dependencies:
> > - How many server RAM memory is required for each 1GB of attachments?
> 
> It depends on how large the attachments are. Currently (as of version 2.6)
> attachments are stored on
> the disk and in the database rather than in RAM so the only limit on the total
> of all attachments is
> the amount of space which your database can hold. Remember that the default
> database HSQL holds all
> tables in RAM.
> 
> If you're asking about a single very large attachment. There is some
> inefficient code in the
> attachment version storage which means that you can only store attachments up
> to about 60MB with
> 512MB of heap space (RAM). This can be bypassed by setting the attachment
> version store type to
> "void" and the limit will rise over 100MB where the problem will
> become the transfer to and from the
> database.
> 
> > - The same for CPU.
> 
> The CPU usage for attachments is not really a factor as compared to the number
> of users, page loads
> per second, number of pages, complexity of queries etc.
> 
> > How to estimate this and calculate hardware? What are main principles?
> 
> It is an art as much as it is a science ;)
> 
> Others know much more than me about the rest of your questions so I will leave
> this to them.
> 
> Caleb
> 
> > 
> > II. Is it possible to customise WYSIWYG editor separetly for each space
> in one sub-XWiki ?
> > 
> > III. Is there any way to manage anchors from Links plugin in WYSIWYG
> editor?
> >   The logic is:
> >- select space
> >- select page
> >- select anchor on this page
> >- put the link
> > 
> > For now, even if I write down XWiki.WebHome#anchor in the link field
> manually, I get #anchor cut out. 
> > And the only way to do it via source code editor manually. Then it works
> fine. Personally me found more or less suitable solution with FF plugin
> https://addons.mozilla.org/ru/firefox/addon/416/ 
> > It's very easy to get anchor, but not so easy to put it. For
> unqualified users it makes XWiki "one-handed".
> > 
> > IV. Is there any way to make TOC macro to build table of contents of
> several pages and put it on one page?
> > For Example:
> > toc Page1, Page2, Page3 
> > 
> > It's very useful, when one can group all project highligts together
> in one TOC.
> > I used to use Track Wiki, it works excellent in there. I suffer from
> it's absence now :-)
> > 
> > Thank you 
> > 
> > Dmitry Bakbardin
> > 
> > ___
> > 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

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

[xwiki-users] Attachments-RAM dependencies, anchors, TOC

[Haru Mamburu]

Hi!

Kindly ask you to solve some unclear topics:

I. How can I find information about such dependencies:
- How many server RAM memory is required for each 1GB of attachments?
- The same for CPU.
How to estimate this and calculate hardware? What are main principles?

II. Is it possible to customise WYSIWYG editor separetly for each space in one 
sub-XWiki ?

III. Is there any way to manage anchors from Links plugin in WYSIWYG editor?
  The logic is:
   - select space
   - select page
   - select anchor on this page
   - put the link

For now, even if I write down XWiki.WebHome#anchor in the link field manually, 
I get #anchor cut out. 
And the only way to do it via source code editor manually. Then it works fine. 
Personally me found more or less suitable solution with FF plugin 
https://addons.mozilla.org/ru/firefox/addon/416/ 
It's very easy to get anchor, but not so easy to put it. For unqualified users 
it makes XWiki "one-handed".

IV. Is there any way to make TOC macro to build table of contents of several 
pages and put it on one page?
For Example:
toc Page1, Page2, Page3 

It's very useful, when one can group all project highligts together in one TOC.
I used to use Track Wiki, it works excellent in there. I suffer from it's 
absence now :-)

Thank you 

Dmitry Bakbardin

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