IRC Archive for channel #xwiki

abusenius left at 00:56 (Quit: Konversation terminated!
jbrBridge - (01:54): [Ricardo Rodríguez] I'm stuck with a doubt here about global users and virtual wikis. Anybody able to help? Thanks!
lucaa left at 02:03 (Ping timeout: 265 seconds
jvelociter - (02:11): jbrBridge: what's your question ?
jbrBridge - (02:12): [Ricardo Rodríguez] thanks, Jerome. Must I be able to add a Global User to a local group in a virtual wiki?
jvelociter - (02:13): yes. though we fixed a bug recently regarding this
jvelociter - (02:14): I think in 2.3.something
jvelociter - (02:14): let me check
jvelociter - (02:15): OK, somebody reported this today : http://jira.xwiki.org/jira/browse/XAADMINISTRATION-167 but that was not waht I had in mind
jbrBridge - (02:15): [Ricardo Rodríguez] working with 2.4.30451 here
jbrBridge - (02:15): [Ricardo Rodríguez] I'll check this issue
jvelociter - (02:16): what I had in mind was this one : XWIKI-4566
jvelociter - (02:16): (which I hit not very long ago, but upgrading to 2.4 fixed the issue)
jbrBridge - (02:17): [Ricardo Rodríguez] I'm having similar problems working with a clean 2.4.30451 installation. I'll check this JIRA issues and come back with more info.
jbrBridge - (02:18): [Ricardo Rodríguez] The first problem I detected was that the groups and users lists generation stuck the first time that an user access them.
jbrBridge - (02:18): [Ricardo Rodríguez] I don't know if this is a related issue, but it happens consistently
jbrBridge - (02:21): [Ricardo Rodríguez] I'll do some Firebug research and use several Internet browsers. Thanks for pointing me toward this JiRA issues.
jvelociter - (02:35): ok, Thanks for the investigation Ricardo
sdumitriu left at 04:41 (Read error: Operation timed out
sdumitriu joined #xwiki at 07:16
vmassol joined #xwiki at 07:40
lucaa joined #xwiki at 07:52
mflorea joined #xwiki at 07:59
vmassol left at 08:00 (Quit: Leaving.
silviar joined #xwiki at 08:46
lucaa left at 08:57 (Quit: Leaving.
sburjan joined #xwiki at 09:13
silviar left at 09:19 (Quit: Leaving.
silviar joined #xwiki at 09:23
lpereira joined #xwiki at 09:24
evalica joined #xwiki at 09:26
arkub joined #xwiki at 09:38
florinciu joined #xwiki at 09:40
lpereira1 joined #xwiki at 09:42
lpereira left at 09:42 (Read error: Connection reset by peer
vmassol joined #xwiki at 09:44
sburjan - (09:53): sdumitriu, cjdelisle  : ping
cjdelisle - (09:53): pong
sburjan - (09:54): I still found a issue regarding lucene
sburjan - (09:54): but unable to reproduce it
sburjan - (09:54): I'll give you the stack trace
cjdelisle - (09:58): http://pastebin.com/TyKCTcur
sburjan - (09:58): yes, that
cjdelisle - (09:59): Probably something else caused by my change. Debugging...
cjdelisle - (10:02): doc.getAttachment(this.filename);
cjdelisle - (10:02): Returning null.
cjdelisle - (10:03): brb need a coffee.
KermitTheFragger joined #xwiki at 10:08
xwikibot joined #xwiki at 15:44
vmassol - (15:44): (restarted the bot)
sburjan - (15:48): cjdelisle, : from what version Invitation App is bundled ?
MartinCleaver joined #xwiki at 15:57
MartinCleaver left at 15:57 (Excess Flood
silviar left at 16:02 (Quit: Leaving.
MartinCleaver joined #xwiki at 16:04
lucaa - (16:07): guys, I need a little advice. I'm trying to implement the dashboard macro as described at http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HOption429Columnmacroforlayouting2Cdashboardextendscolumnmacro
lucaa - (16:07): and I would need to be able to filterout all wiki content in the columns (the column macro) which is not a macro call
lucaa - (16:07): my idea is that I would extend the section macro with a dashboard macro, to mark that the specific columned section is a dashboard
lucaa - (16:08): but how could I make sure that the columns content is correct?
lucaa - (16:09): I see 2 options:
lucaa - (16:09): 1/ create a dashboard column macro which will handle filtering
lucaa - (16:09): 2/ transform all the subtree in the dashboard macro, and filter
lucaa - (16:09): any ideas?
sburjan - (16:10): http://jira.xwiki.org/jira/browse/XE-706
venkatesh left at 16:15 (Ping timeout: 276 seconds
jvelociter - (16:16): lucaa: wdym bu make sure columns content is correct ?
lucaa - (16:16): well, the idea would be that the content is wiki content, but all the stuff which are not macro calls (gadget macro calls) are ignored and not rendered
lucaa - (16:17): and I was thinking to do this "filtering" in the dashboard macro, somehow
lucaa - (16:17): as in, only when the column is in a dashboard macro, it will have this behaviour
jvelociter - (16:18): I think thomas added an API to remove blocks
lucaa - (16:18): ok, that's great, I didn't know that can be a problem
jvelociter - (16:19): (I did that already before the API exist, by calling something like parentBlock.removeChildren)
lucaa - (16:19): but my question would be how to approach the filtering, since the column macro, by default just returns all its content
jvelociter - (16:19): are we sure we want to forbid to have anything else than macros under the dashboard ?
lucaa - (16:19): I should
lucaa - (16:19): 3/ modify the column macro and make it aware of its parent
lucaa - (16:20): well, we wouldn't be able to edit anything, so I would say yes, forbid it
lucaa - (16:20): e.g. I wouldn't know how we could handle, from the dashboard editor, some plain xwiki text
jvelociter - (16:20): I would think the UI should prevent you to do that, but if you really want to do it by hand it should not strip your content
jvelociter - (16:21): anyway, IMO it should be the parent macro that do the filtering
lucaa - (16:21): yes, but how ?
jvelociter - (16:21): not the column that explore upper the tree
lucaa - (16:22): yes, but how would the parent do it?
lucaa - (16:22): the column XDOM is not "expanded" at the execution of the section/dashboard macro
lucaa - (16:22): so I cannot reach the contents
jvelociter - (16:22): right, it's executed before the cu=olumn
lucaa - (16:22): yep
jvelociter - (16:22): column
lucaa - (16:22): so, see my 2 solutions above
lucaa - (16:22): is there any solution that I am missing?
jvelociter - (16:23): you can either force the rendering of the columns
jvelociter - (16:23): yes, 3rd option is to have a dedicated Tx
lucaa - (16:23): explain a bit more
lucaa - (16:23): dedicated Tx?
jvelociter - (16:24): rendering transformation
jvelociter - (16:24): that would execute after the macro transformation
jvelociter - (16:24): and do the cleanup
lucaa - (16:25): you mean independent of the dashboard macro, it would just explore the XDOM of the page and handle this filtering
jvelociter - (16:25): yes
lucaa - (16:26): yes, that's an idea as well
jvelociter - (16:26): not sure it's better, but it would work
jvelociter - (16:26): I don't like he option of the column macro doing the cleanup
jvelociter - (16:26): the other 2 are more elegant IMHO
lucaa - (16:26): me neither, column macro should not be parent aware
sburjan - (16:31): cjdelisle, : should I report a JIRA issue regarding the orphan page ?
cjdelisle - (16:31): I just found and fixed it.
cjdelisle - (16:32): Thanks for continuing to remind me, I can forget easily ;)
sburjan - (16:32): okay :)
sburjan - (16:32): no problem
cjdelisle - (16:32): The problem was with an automatically generated document so checking all of the documents with grep did not yield the problem.
sburjan - (16:32): so you fixed the lucene bug too ?
cjdelisle - (16:34): It hasn't shown up since I fixed another bug :/
cjdelisle - (16:35): It's nature makes it look like a very hard to detect concurrency bug but I think it was just the other bug which I fixed.
asrfel left at 16:36 (Quit: Leaving.
cjdelisle - (16:36): I just built the latest and I'm running the tests, the AttachmentTest seems to cause that stack trace sometimes so I will run it a couple times over.
lucaa - (16:38): cjdelisle: I just looked at the orphaned InvitationConfig page...
lucaa - (16:38): and I don't really understand, why is it generated?
cjdelisle - (16:39): Because if it already exists and the user imports it then their configuration is wiped.
lucaa - (16:39): but this is the problem for all xwiki applications
lucaa - (16:39): and the solution is the application manager, not this, I would say
lucaa - (16:40): I mean, yeah, it fixes it, but it's not _THE_ solution
cjdelisle - (16:40): I agree. If we had something working I definitely would have used it.
lucaa - (16:40): how about applications which don't have java backend to generate the config objs? How would these fix it?
cjdelisle - (16:40): "don't have java backend"? This is done entirely with velocity.
cjdelisle - (16:41): Invitation doesn't have any java code.
lucaa - (16:41): ok
lucaa - (16:41): how with velocity?
lucaa - (16:41): I mean when is the document created?
cjdelisle - (16:41): On first load of the Invitation.WebHome document
lucaa - (16:42): and when would that happen?
lucaa - (16:42): I would assume not when user accesses it, right?
cjdelisle - (16:42): Correct, or when the user views the configuration page.
lucaa - (16:43): because, the configuration class is the Invitation.WebHome?
lucaa - (16:43): or why?
lucaa - (16:43): (because that is another thing which I find at least non-semantic, to use a delicate word)
cjdelisle - (16:44): It's another ugly hack which includes the WebHome when the config page is loaded.
cjdelisle - (16:45): I have been meaning to work on an application for handling import upgradability but If I handled everything correctly for each project then I would be rewriting xwiki-core.
lucaa - (16:47): well anyway, all I don't like about all these (that I said above) is that they're hacky and inconsistent
lucaa - (16:47): I prefer that all applications have the same type of bugs (config wiped out on upgrade) than that they are inconsistent
lucaa - (16:47): that's only my personal opinion
cjdelisle - (16:48): I agree it's a hack. I actually ripped the idea from the search application.
lucaa - (16:48): really?
lucaa - (16:48): so it becomes consistent now...
lucaa - (16:48): :)
cjdelisle - (16:49): Consistently ugly.
cjdelisle - (16:49): But it doesn't burn the user on upgrade. We really should talk about how to fix this right though, I'm glad you reminded me.
lucaa - (16:51): I think it's burning more the user on upgrades in general if it's gonna magically work fine for some applications and for others not
lucaa - (16:51): (which is why consistency rocks, it allows people to learn)
lucaa - (16:52): well I see here: https://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/trunk/search/src/main/resources/XWiki/ that in the case of the search app the config class is stored in a dedicated document (following the general rule of xwiki apps)
lucaa - (16:53): so one less hack
cjdelisle - (16:53): Same with Invitation.InvitationConfig.
cjdelisle - (16:54): On the other hand the user suddenly has to save out more and more documents, they will probably be bitten by the new ones.
cjdelisle - (16:54): The real answer is a mechanism to revert the configuration documents.
cjdelisle - (16:54): revert or prevent import.
lucaa - (16:55): I would say the real answer is a merge + prevent import or asking the user (as ubuntu does with modified config files on upgrade, for example)
cjdelisle - (16:56): "config class" ahh yes. the class is WebHome after all.
cjdelisle - (16:58): Actually, IMO there needs to be the ability to run import scripts. Scripts which run before or after import have always been in redhat rpms. I think they're present in deb package files aswell.
sburjan left at 17:03 (Ping timeout: 240 seconds
lpereira1 left at 17:04 (Quit: Leaving.
flaviusolaru left at 17:09 (Quit: Leaving.
lucaa - (17:15): that is an approach
sdumitriu - (17:26): sburjan`: I'm available now
lucaa - (17:28): sdumitriu: sburjan` just left, I guess he will be back soon from his place...
kwoot joined #xwiki at 17:30
kwoot - (17:30): simple question: where can I find how many pages I have in my wiki? or in separate spaces?
kwoot left #xwiki at 17:31
lucaa left at 17:34 (Ping timeout: 276 seconds
vmassol - (17:47): anyone working on XE-700 ?
sburjan` - (17:51): sdumitriu : I'm at home .. just wanted to tell you I reported 2 JIRA bugs .. one on the XEM and onether regarding some inconsistencies in the UI
jvelociter - (18:02): vmassol: no I don't think so. I discussed it quickly with thomas ydaym he was saying continuing supporting this might not be very easy
jvelociter - (18:02): (was working because of a bug, previously)
vmassol - (18:02): hmm
jvelociter - (18:02): though for luis it appears as a regression, of course
vmassol - (18:03): yep
vmassol - (18:03): (for his users)
jvelociter - (18:03): IMHO we need to decide if we invest in it, and if not we should probably provide the migration script
jvelociter - (18:03): (or include a migrator that does it automatically)
vmassol - (18:04): ok, I'll talk to thomas when he's online about it
vmassol - (18:05): thanks
jvelociter - (18:06): btw sburjan` XEM-175 is probably a XWIKI issue, not a XEM issue
jvelociter - (18:06): (XEM project is mostly packaging)
jvelociter - (18:07): you can ping thomas about it tomorrow, he'll tell you if you have to move it to the XWIKI project
lucaa joined #xwiki at 18:23
SvenDowideit left at 18:26 (Ping timeout: 265 seconds
SvenDowideit_ joined #xwiki at 18:26
SvenDowideit_ is now known as SvenDowideit ([email protected]
vmassol left at 18:30 (Quit: Leaving.
mflorea left at 18:51 (Quit: Leaving.
lucaa left at 19:16 (Ping timeout: 258 seconds
MartinCleaver left at 19:52 (Quit: MartinCleaver
evalica1 joined #xwiki at 20:09
evalica1 left at 20:09 (Client Quit
evalica left at 20:12 (Ping timeout: 272 seconds
MartinCleaver joined #xwiki at 20:15
mflorea joined #xwiki at 20:54
KermitTheFragger left at 21:14 (Ping timeout: 240 seconds
vmassol joined #xwiki at 21:23
KermitTheFragger joined #xwiki at 21:35
KermitTheFragger left at 21:37 (Read error: Connection reset by peer
abusenius joined #xwiki at 22:06
lpereira joined #xwiki at 22:11
lpereira left at 22:36 (Quit: Leaving.
vmassol left at 23:07 (Quit: Leaving.
MartinCleaver_ joined #xwiki at 23:14
MartinCleaver left at 23:17 (Ping timeout: 260 seconds
MartinCleaver_ is now known as MartinCleaver (~martincle@foswiki/developer/MartinCleaver
MartinCleaver left at 23:40 (Quit: MartinCleaver