IRC Archive for channel #xwiki on 24 March 2016
Last modified by Vincent Massol on 2016/03/24 23:35
<vmassol> has quit
04:49 <asam> has joined #xwiki
04:56 <asam> has quit
05:07 <asam> has joined #xwiki
05:20 <asam> has quit
06:16 <mflorea> has joined #xwiki
07:28 <msmeria> has joined #xwiki
07:42 <mflorea> has quit
07:45 <sorinello> has quit
07:46 <sorinello> has joined #xwiki
08:01 <lkrejci> has quit
08:14 <vmassol> has joined #xwiki
08:30 <cjd> has quit
08:38 <KermitTheFragger> has joined #xwiki
08:44 <tmortagne> has joined #xwiki
08:50 <woshilapin> has quit
09:01 <vmassol> tmortagne: good morning
09:02 <vmassol> regarding the sonar platform build failure, sonarqube has answered my question
09:02 <vmassol> and it seems we have a huge test result that is too large for being parsed:
09:02 <vmassol> http://ci.xwiki.org/view/Failed%20Builds/job/xwiki-platform_Sonar/ws/xwiki-platform-core/xwiki-platform-filter/xwiki-platform-filter-streams/xwiki-platform-filter-stream-confluencexml/target/surefire-reports/TEST-org.xwiki.filter.xar.IntegrationTests.xml
09:02 <vmassol> do you think you could look at why it's so large and maybe have some smaller result for the test?
09:02 <vmassol> it's really huge :)
09:03 <vmassol> (6MB)
09:03 <tmortagne> what is a "test result" for sonarqube ?
09:04 <vmassol> I've pasted the link
09:04 <vmassol> this is the surefire test result
09:04 <vmassol> that soner is failing to parse
09:04 <tmortagne> sure but it does not really tell me what it's supposed to be in theory
09:04 <tmortagne> the log ? what the target folder contain ?
09:04 <tmortagne> I see XARS in it...
09:05 <vmassol> AFAIU sonar parses the TEST-org.xwiki.filter.xar.IntegrationTests.xml file
09:05 <tmortagne> also this result contain a lot of failures
09:05 <vmassol> it's the resiult from the confulencexml integration test
09:05 <tmortagne> so I think the main issue if that some test are failing in the sonar build
09:06 <vmassol> yes
09:06 <vmassol> this is what Fabrice is saying too I think: "Uhhh, the failure message is far too big. Not good IMO."
09:06 <tmortagne> the issue is not that it's too big...
09:06 <tmortagne> the issue is that it exist
09:07 <tmortagne> those test should not fail in the first place
09:07 <vmassol> errr?
09:07 <ujjwal> has joined #xwiki
09:07 <vmassol> then why have tests?
09:07 <vmassol> if they always pass they're not needed
09:07 <vmassol> they're needed becuase they can fail
09:07 <vmassol> or
09:07 <vmassol> doyou mean
09:07 <vmassol> that it's ok to have errors instead of failures?
09:07 <tmortagne> if they fail they should be fixed, the point of sonar is not to tall us we have filing tests
09:08 <tmortagne> s/tall/tell/
09:08 <vmassol> (error = build error, failure = the build worked but a test failed)
09:08 <tmortagne> if they don't fail sonar won't have a "too big result to parse"
09:08 <vmassol> I don't think that the best way to indicate a failed tests
09:08 <vmassol> what is the issue is making the test smaller?
09:08 <vmassol> for ex
09:09 <vmassol> what is the issue in making the image001.png much smaller?
09:09 <vmassol> why would it make the test less good?
09:10 <tmortagne> why is sonar parsing the test result in the first place ? we don't it to since we already have other tools to tell us about tests failures
09:10 <tmortagne> s/don't it/don't need it/
09:11 <vmassol> you can ask them or read the sonar source code but it's much simpler to fix our test
09:11 <vmassol> also I don't see any harm in making our tests faster
09:12 <tmortagne> I don't really see what speed have to do here
09:12 <vmassol> anyway I'm leaving it in your hands
09:12 <vmassol> large file = slower
09:12 <vmassol> smaller file : faster
09:13 <vmassol> @thomas: I don't want to discuss, I want you to fix it, that's all
09:13 <tmortagne> I have things to finish first, then I will see what made this test fail since there was no change in confluence or filter module in a while
09:13 <vmassol> could be java8
09:15 <vmassol> this our last error on ci (not talking about failures), I spent 2 days fixing the rest
09:19 <vmassol> fyi this is failing test on the normal platform build: http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-filter-stream-confluencexml/2674/testReport/org.xwiki.filter.test.integration/FilterTest/confluencexml_4_3_2_test__confluence_xml__filter_xml_/
09:19 <Slashman> has joined #xwiki
09:21 <lkrejci> has joined #xwiki
09:23 <tmortagne> vmassol: it does not look like ordering issue, probably some map somewhere
09:23 <tmortagne> s/not//
09:23 <vmassol> ok so indeed java8
09:23 <vmassol> I fixed all unit tests but didn't look at integration tests
09:23 <vmassol> (for maps)
09:26 <tmortagne> in this case it's good it failed since as far as I can see we don't import the pages in the same order that they are declared in the confluence package, even if I doubt there is any concept of order in the confluence export it's still nicer to follow the package order
09:27 <vmassol> k
09:31 <cjd> has joined #xwiki
09:36 <tmortagne> merged on 8.0 and 7.4 too so that we see if the fix make it stable on any version of Java
09:37 <vmassol> ok thx
09:38 <ujjwal> has quit
09:41 <mflorea> has joined #xwiki
09:41 <gdelhumeau> has joined #xwiki
09:42 <woshilapin> has joined #xwiki
10:04 <vmassol> tmortagne: when writing a job, it's the job writer's role to set the current user in the context or should that be done automatically by the job manager?
10:04 <vmassol> (right now in WikiCreationJob the context user is null)
10:05 <tmortagne> vmassol: if by job manager you mean JobExecutor the answer is JobExecutor is a commons API :)
10:05 <vmassol> yes sure but we could have some platform abstact
10:05 <tmortagne> so yes no standard, you need to pass the user in your request and set it yourself in your job
10:06 <vmassol> ok so I guess gdelhumeau forgot to set it, I'll add it
10:06 <vmassol> gdelhumeau: any issue in setting the wiki owner as the context user in WikiCreationJob?
10:06 <gdelhumeau> I don't think so
10:07 <tmortagne> yes we need to make sure to have a XWikiContext as standard as possible in all the jobs generating documents event (i.e. all the job modifying documents)
10:07 <gdelhumeau> Just take care that in the provisioning step, the flavor is installed with superuser
10:07 <vmassol> gdelhumeau: I guess that the provisoning step will override it
10:07 <vmassol> and put it back after
10:07 <gdelhumeau> let me check
10:09 <gdelhumeau> that should be ok: https://github.com/xwiki/xwiki-platform/blob/5a111a65a57ce8029449c188f26fc8f214cdfe8e/xwiki-platform-core/xwiki-platform-wiki/xwiki-platform-wiki-creationjob/src/main/java/org/xwiki/platform/wiki/creationjob/internal/ExtensionInstaller.java#L70-L70
10:09 <vmassol> gdelhumeau: in WikiCreationRequest what is ownerId? is it the reference to the owner user?
10:10 <vmassol> ok so you start another job in the provisoning job step
10:15 <ujjwal> has joined #xwiki
10:15 <vmassol> gdelhumeau: ping
10:15 <gdelhumeau> it's serialized
10:16 <vmassol> it's a serialized reference?
10:16 <gdelhumeau> yes
10:16 <vmassol> why is it called id?
10:16 <gdelhumeau> as ownerId is
10:16 <vmassol> does it mean it can contain something other than a ref?
10:16 <gdelhumeau> in the future it could be a facebook user, or something else
10:17 <vmassol> ok so in a future we'll need to go through a user api
10:17 <vmassol> got it
10:17 <vmassol> (and change the code I'm adding)
10:18 <vmassol> gdelhumeau: it's an absolute ref?
10:19 <gdelhumeau> yes
10:20 <vmassol> hmm since it's a global user, I'll use a default resolver
10:28 <vmassol> gdelhumeau, tmortagne: actually, do we want that the wiki descriptor page be authored by the wiki owner? or do we want to always force it to superadmin?
10:28 <gdelhumeau> I don't think it have an impact
10:29 <tmortagne> being the author of the page give it right to modify it whatever the right are set
10:29 <vmassol> btw gdelhumeau, did you know that you save the descriptor twice in the wiki creation job?
10:30 <gdelhumeau> I remember something like that yes
10:30 <vmassol> once in the WikiCreationStep and then another time in the SaveWikiMetaDataStep
10:30 <vmassol> seems a bit strange
10:31 <vmassol> and there's no "if" in the save of the desqcriptor so the work is done twice
10:31 <gdelhumeau> the first time is the descriptor itself
10:31 <gdelhumeau> and the second time, it's a WikiPropertyGroup
10:31 <vmassol> tmortagne: yes the question is whether we want the owner to have the rights to edit the descirptor
10:31 <gdelhumeau> that could be saved anywhere actually
10:32 <vmassol> gdelhumeau: well saveDescriptor() is called 2 times
10:32 <vmassol> (don't know what WikiPropertyGroup is)
10:33 <vmassol> you're setting the deqcirtion, ownerid, etc again in the savemetadatastep
10:34 <vmassol> actually no
10:34 <vmassol> those are not set the first time apparently
10:34 <vmassol> not sure why
10:34 <vmassol> I think I know
10:34 <vmassol> my guess is that you implemented a step fro it
10:34 <vmassol> and then later realized that we actually need to have the descriptor
10:34 <vmassol> before the DB update
10:35 <vmassol> so you created it before too without refactoring
10:35 <gdelhumeau> I simply reuse the WikiManager component
10:35 <gdelhumeau> when you create a wiki it creates a descriptor
10:35 <gdelhumeau> and the save metadata step change them afterwards
10:35 <vmassol> yes
10:35 <vmassol> anyway I'm not fixing this now
10:35 <gdelhumeau> and it have to be done after the provisioning
10:36 <gdelhumeau> don't remember why
10:36 <gdelhumeau> hmm no it's not
10:36 <vmassol> tmortagne: any take? I'm making the change now and I need to decide
10:36 <vmassol> I'll put the owner
10:37 <vmassol> since he's the one who filled the wik metadata he should be able to change them later on I guess
10:37 <tmortagne> right now owner sounds better to me
10:38 <vmassol> btw gdelhumeau lots of duplication in saveDescriptor and XWikiServerClassDocumentInitializer
10:40 <gdelhumeau> you mean save descriptor recreates the class?
10:40 <vmassol> no
10:40 <vmassol> I mean code duplication
10:40 <vmassol> XWikiServerClassDocumentInitializer is not used much since the provisoning creates it
10:40 <vmassol> it's used only if someone deletes the descriptor
10:40 <vmassol> in order to recreate it
10:40 <vmassol> (I guess)
10:41 <vmassol> but I was mentioning that they both do similar stuff with code duplication
10:43 <vmassol> ok done, first BFD of the day for me ;)
10:51 <M-mouhb> Hello
10:55 <M-mouhb> I am working on an extension that is based on this task
10:55 <M-mouhb> https://jira.xwiki.org/browse/XWIKI-12650
10:56 <M-mouhb> I want your opinion to choose an appropriate name to the extension
11:00 <gdelhumeau> XWikiServerClassDocumentInitializer creates "XWiki.XWikiServerClass" on the main wiki
11:01 <gdelhumeau> I don't see any duplication
11:05 <vmassol> gdelhumeau: descriptors are all created on the main wiki
11:05 <vmassol> ah
11:06 <vmassol> hmmm
11:06 <vmassol> indeed my bad we have 3 different things:
11:06 <vmassol> - server class page creation
11:07 <vmassol> - main wik descriptor page creation
11:07 <vmassol> - subwiki descriptor page creation
11:07 <vmassol> I mixed server class page creation with subwiki descriptor page creation
11:17 <vmassol> second BFD!
11:17 <vmassol> (thanks to Edy who left a duplicate for me to close ;))
11:24 <ujjwal> has quit
11:30 <Enygma`> has joined #xwiki
11:32 <evalica> has joined #xwiki
11:49 <Pbas> Hi there :)! Someone tested/use groovy console applications http://extensions.xwiki.org/xwiki/bin/view/Extension/Groovy+Console+Application on recent xwiki (like 7.0.1 version)?
11:49 <Pbas> Is it still working?
11:50 <Pbas> Here, I just updated F10 shorcut in javascript, but impossible to launch console...
11:54 <Pbas> Ha ... log display naughty error like: Error at line 57, column 15: il manque ';' avant une instruction. Caused by: [ , value: "Execute (CTRL + E)" ] or Error at line 47, column 14: l'identifiant de propriété est incorrect. Caused by: [ , class: "xuake-console hidden"]
11:54 <Pbas> on XWiki.Xuake page :-(
12:04 <vmassol> Pbas: not used it recently myself
12:04 <Pbas> ok thxs
12:11 <vmassol> Enygma`: you missed the BFD mail yesterday I think
12:12 <vmassol> still time to catch up but you should do that quickly
12:12 <vmassol> creating contrib project for mahamed
12:28 <Enygma`> vmassol: sending it now
12:45 <ujjwal> has joined #xwiki
13:02 <vmassol> thanks
14:25 <vmassol> btw we still haven't migrated pages to NS on xwiki.org so we're still loosing the hierarchy ATM...
15:27 <msmeria> has quit
15:30 <ujjwal> has quit
16:06 <vmassol> and 3 (BFDs) :)
16:06 <vmassol> but 2 bugs added today so far
16:06 <vmassol> so winning only by 1
16:08 <Bugendol1> has joined #xwiki
16:13 <mflorea> has quit
16:13 <Bugendolf> has quit
16:25 <xwikiorg_guest_9> has joined #xwiki
16:27 <Trefex> has joined #xwiki
16:28 <xwikiorg_guest_9> Hello I've got a problem with my Xwiki Entreprise 7.3: when I create a new page into an existing space, the page is created into a new space named "EXISTINGSPACE.PAGENAME". Thank you for you help /HELP
16:29 <mflorea> has joined #xwiki
16:30 <vmassol> xwikiorg_guest_9: first I'd recommend using 7.4.2 since 7.3 was buggy and we had introduced nested spaces not long ago
16:33 <xwikiorg_guest_9> @vmassol ok so I will do that first. Thanks
16:41 <xwikiorg_guest_9> has quit
17:14 <xwikiorg_guest_6> has joined #xwiki
17:23 <vmassol> gdelhumeau: hmm I see you override the default LT query filters in siblings/children
17:23 <M-mouhb> has quit
17:23 <vmassol> so I guess it means all translations will be displayed
17:23 <vmassol> is that voluntary? because it's not consistent with AllDocs
17:24 <vmassol> actually no, you have unique used
17:24 <vmassol> still it's not consistent
17:24 <vmassol> AllDocs uses currentlanguage,hidden and children/siblings use unique,hidden
17:33 <M-jsimard> has joined #xwiki
17:33 <woshilapin> has quit
17:45 <xwikiorg_guest_6> has quit
17:48 <gdelhumeau> I guess currentlanguage should be added
17:48 <gdelhumeau> the incosistency was not voluntary
17:48 <vmassol> ok, I'll see what I can do
17:49 <vmassol> note that by being inconsistent you've fxied one issue we have for AllDocs
17:49 <vmassol> (but the date may not be correct)
17:50 <vmassol> gdelhumeau:another question for you
17:51 <vmassol> why have you introduced "childrenOf" in getdocuments.vm insted of using the existing "space" and adding extra where
17:51 <vmassol> ?
17:51 <vmassol> I'm fixing http://jira.xwiki.org/browse/XWIKI-13257 and childrenOf is really not generic
17:52 <vmassol> btw "space" should support NS probably
17:53 <vmassol> I see it's used in deletespace.vm
17:54 <gdelhumeau> I didn't want to touch the space viewer
17:54 <vmassol> hmm maybe you kept "space" for backward comapt with old skins
17:54 <vmassol> without NS
17:57 <vmassol> ok got it
18:03 <vmassol> hmm no I can't have a generic extra where clause since that would be a security hole
18:04 <cjd> has quit
18:09 <gdelhumeau> I have to go
18:09 <gdelhumeau> has quit
18:16 <vmassol> and 4!
18:19 <evalica> has quit
18:20 <evalica> has joined #xwiki
18:25 <M-mouhb> has joined #xwiki
18:25 <M-vmassol> has joined #xwiki
18:25 <M-cjd> has joined #xwiki
18:36 <lkrejci> has quit
18:48 <asam> has joined #xwiki
18:59 <mrvis> has joined #xwiki
19:02 <avisser> has quit
19:06 <cjd> has joined #xwiki
19:14 <mflorea> has quit
19:14 <asam_> has joined #xwiki
19:16 <asam> has quit
19:19 <vmassol1> has joined #xwiki
19:22 <evalica> has quit
19:22 <evalica> has joined #xwiki
19:22 <evalica> has quit
19:29 <Enygma`> has quit
19:44 <lkrejci> has joined #xwiki
20:05 <tmortagne> has quit
20:40 <lkrejci> has quit
20:41 <lkrejci> has joined #xwiki
21:06 <mflorea> has joined #xwiki
21:19 <Slashman> has quit
21:55 <mrvis> has quit
22:12 <sorinello> has quit
22:16 <asam_> has quit
22:29 <mflorea> has quit
23:34 <vmassol1> has quit
23:35 <vmassol> has joined #xwiki
04:49 <asam> has joined #xwiki
04:56 <asam> has quit
05:07 <asam> has joined #xwiki
05:20 <asam> has quit
06:16 <mflorea> has joined #xwiki
07:28 <msmeria> has joined #xwiki
07:42 <mflorea> has quit
07:45 <sorinello> has quit
07:46 <sorinello> has joined #xwiki
08:01 <lkrejci> has quit
08:14 <vmassol> has joined #xwiki
08:30 <cjd> has quit
08:38 <KermitTheFragger> has joined #xwiki
08:44 <tmortagne> has joined #xwiki
08:50 <woshilapin> has quit
09:01 <vmassol> tmortagne: good morning
09:02 <vmassol> regarding the sonar platform build failure, sonarqube has answered my question
09:02 <vmassol> and it seems we have a huge test result that is too large for being parsed:
09:02 <vmassol> http://ci.xwiki.org/view/Failed%20Builds/job/xwiki-platform_Sonar/ws/xwiki-platform-core/xwiki-platform-filter/xwiki-platform-filter-streams/xwiki-platform-filter-stream-confluencexml/target/surefire-reports/TEST-org.xwiki.filter.xar.IntegrationTests.xml
09:02 <vmassol> do you think you could look at why it's so large and maybe have some smaller result for the test?
09:02 <vmassol> it's really huge :)
09:03 <vmassol> (6MB)
09:03 <tmortagne> what is a "test result" for sonarqube ?
09:04 <vmassol> I've pasted the link
09:04 <vmassol> this is the surefire test result
09:04 <vmassol> that soner is failing to parse
09:04 <tmortagne> sure but it does not really tell me what it's supposed to be in theory
09:04 <tmortagne> the log ? what the target folder contain ?
09:04 <tmortagne> I see XARS in it...
09:05 <vmassol> AFAIU sonar parses the TEST-org.xwiki.filter.xar.IntegrationTests.xml file
09:05 <tmortagne> also this result contain a lot of failures
09:05 <vmassol> it's the resiult from the confulencexml integration test
09:05 <tmortagne> so I think the main issue if that some test are failing in the sonar build
09:06 <vmassol> yes
09:06 <vmassol> this is what Fabrice is saying too I think: "Uhhh, the failure message is far too big. Not good IMO."
09:06 <tmortagne> the issue is not that it's too big...
09:06 <tmortagne> the issue is that it exist
09:07 <tmortagne> those test should not fail in the first place
09:07 <vmassol> errr?
09:07 <ujjwal> has joined #xwiki
09:07 <vmassol> then why have tests?
09:07 <vmassol> if they always pass they're not needed
09:07 <vmassol> they're needed becuase they can fail
09:07 <vmassol> or
09:07 <vmassol> doyou mean
09:07 <vmassol> that it's ok to have errors instead of failures?
09:07 <tmortagne> if they fail they should be fixed, the point of sonar is not to tall us we have filing tests
09:08 <tmortagne> s/tall/tell/
09:08 <vmassol> (error = build error, failure = the build worked but a test failed)
09:08 <tmortagne> if they don't fail sonar won't have a "too big result to parse"
09:08 <vmassol> I don't think that the best way to indicate a failed tests
09:08 <vmassol> what is the issue is making the test smaller?
09:08 <vmassol> for ex
09:09 <vmassol> what is the issue in making the image001.png much smaller?
09:09 <vmassol> why would it make the test less good?
09:10 <tmortagne> why is sonar parsing the test result in the first place ? we don't it to since we already have other tools to tell us about tests failures
09:10 <tmortagne> s/don't it/don't need it/
09:11 <vmassol> you can ask them or read the sonar source code but it's much simpler to fix our test
09:11 <vmassol> also I don't see any harm in making our tests faster
09:12 <tmortagne> I don't really see what speed have to do here
09:12 <vmassol> anyway I'm leaving it in your hands
09:12 <vmassol> large file = slower
09:12 <vmassol> smaller file : faster
09:13 <vmassol> @thomas: I don't want to discuss, I want you to fix it, that's all
09:13 <tmortagne> I have things to finish first, then I will see what made this test fail since there was no change in confluence or filter module in a while
09:13 <vmassol> could be java8
09:15 <vmassol> this our last error on ci (not talking about failures), I spent 2 days fixing the rest
09:19 <vmassol> fyi this is failing test on the normal platform build: http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-filter-stream-confluencexml/2674/testReport/org.xwiki.filter.test.integration/FilterTest/confluencexml_4_3_2_test__confluence_xml__filter_xml_/
09:19 <Slashman> has joined #xwiki
09:21 <lkrejci> has joined #xwiki
09:23 <tmortagne> vmassol: it does not look like ordering issue, probably some map somewhere
09:23 <tmortagne> s/not//
09:23 <vmassol> ok so indeed java8
09:23 <vmassol> I fixed all unit tests but didn't look at integration tests
09:23 <vmassol> (for maps)
09:26 <tmortagne> in this case it's good it failed since as far as I can see we don't import the pages in the same order that they are declared in the confluence package, even if I doubt there is any concept of order in the confluence export it's still nicer to follow the package order
09:27 <vmassol> k
09:31 <cjd> has joined #xwiki
09:36 <tmortagne> merged on 8.0 and 7.4 too so that we see if the fix make it stable on any version of Java
09:37 <vmassol> ok thx
09:38 <ujjwal> has quit
09:41 <mflorea> has joined #xwiki
09:41 <gdelhumeau> has joined #xwiki
09:42 <woshilapin> has joined #xwiki
10:04 <vmassol> tmortagne: when writing a job, it's the job writer's role to set the current user in the context or should that be done automatically by the job manager?
10:04 <vmassol> (right now in WikiCreationJob the context user is null)
10:05 <tmortagne> vmassol: if by job manager you mean JobExecutor the answer is JobExecutor is a commons API :)
10:05 <vmassol> yes sure but we could have some platform abstact
10:05 <tmortagne> so yes no standard, you need to pass the user in your request and set it yourself in your job
10:06 <vmassol> ok so I guess gdelhumeau forgot to set it, I'll add it
10:06 <vmassol> gdelhumeau: any issue in setting the wiki owner as the context user in WikiCreationJob?
10:06 <gdelhumeau> I don't think so
10:07 <tmortagne> yes we need to make sure to have a XWikiContext as standard as possible in all the jobs generating documents event (i.e. all the job modifying documents)
10:07 <gdelhumeau> Just take care that in the provisioning step, the flavor is installed with superuser
10:07 <vmassol> gdelhumeau: I guess that the provisoning step will override it
10:07 <vmassol> and put it back after
10:07 <gdelhumeau> let me check
10:09 <gdelhumeau> that should be ok: https://github.com/xwiki/xwiki-platform/blob/5a111a65a57ce8029449c188f26fc8f214cdfe8e/xwiki-platform-core/xwiki-platform-wiki/xwiki-platform-wiki-creationjob/src/main/java/org/xwiki/platform/wiki/creationjob/internal/ExtensionInstaller.java#L70-L70
10:09 <vmassol> gdelhumeau: in WikiCreationRequest what is ownerId? is it the reference to the owner user?
10:10 <vmassol> ok so you start another job in the provisoning job step
10:15 <ujjwal> has joined #xwiki
10:15 <vmassol> gdelhumeau: ping
10:15 <gdelhumeau> it's serialized
10:16 <vmassol> it's a serialized reference?
10:16 <gdelhumeau> yes
10:16 <vmassol> why is it called id?
10:16 <gdelhumeau> as ownerId is
10:16 <vmassol> does it mean it can contain something other than a ref?
10:16 <gdelhumeau> in the future it could be a facebook user, or something else
10:17 <vmassol> ok so in a future we'll need to go through a user api
10:17 <vmassol> got it
10:17 <vmassol> (and change the code I'm adding)
10:18 <vmassol> gdelhumeau: it's an absolute ref?
10:19 <gdelhumeau> yes
10:20 <vmassol> hmm since it's a global user, I'll use a default resolver
10:28 <vmassol> gdelhumeau, tmortagne: actually, do we want that the wiki descriptor page be authored by the wiki owner? or do we want to always force it to superadmin?
10:28 <gdelhumeau> I don't think it have an impact
10:29 <tmortagne> being the author of the page give it right to modify it whatever the right are set
10:29 <vmassol> btw gdelhumeau, did you know that you save the descriptor twice in the wiki creation job?
10:30 <gdelhumeau> I remember something like that yes
10:30 <vmassol> once in the WikiCreationStep and then another time in the SaveWikiMetaDataStep
10:30 <vmassol> seems a bit strange
10:31 <vmassol> and there's no "if" in the save of the desqcriptor so the work is done twice
10:31 <gdelhumeau> the first time is the descriptor itself
10:31 <gdelhumeau> and the second time, it's a WikiPropertyGroup
10:31 <vmassol> tmortagne: yes the question is whether we want the owner to have the rights to edit the descirptor
10:31 <gdelhumeau> that could be saved anywhere actually
10:32 <vmassol> gdelhumeau: well saveDescriptor() is called 2 times
10:32 <vmassol> (don't know what WikiPropertyGroup is)
10:33 <vmassol> you're setting the deqcirtion, ownerid, etc again in the savemetadatastep
10:34 <vmassol> actually no
10:34 <vmassol> those are not set the first time apparently
10:34 <vmassol> not sure why
10:34 <vmassol> I think I know
10:34 <vmassol> my guess is that you implemented a step fro it
10:34 <vmassol> and then later realized that we actually need to have the descriptor
10:34 <vmassol> before the DB update
10:35 <vmassol> so you created it before too without refactoring
10:35 <gdelhumeau> I simply reuse the WikiManager component
10:35 <gdelhumeau> when you create a wiki it creates a descriptor
10:35 <gdelhumeau> and the save metadata step change them afterwards
10:35 <vmassol> yes
10:35 <vmassol> anyway I'm not fixing this now
10:35 <gdelhumeau> and it have to be done after the provisioning
10:36 <gdelhumeau> don't remember why
10:36 <gdelhumeau> hmm no it's not
10:36 <vmassol> tmortagne: any take? I'm making the change now and I need to decide
10:36 <vmassol> I'll put the owner
10:37 <vmassol> since he's the one who filled the wik metadata he should be able to change them later on I guess
10:37 <tmortagne> right now owner sounds better to me
10:38 <vmassol> btw gdelhumeau lots of duplication in saveDescriptor and XWikiServerClassDocumentInitializer
10:40 <gdelhumeau> you mean save descriptor recreates the class?
10:40 <vmassol> no
10:40 <vmassol> I mean code duplication
10:40 <vmassol> XWikiServerClassDocumentInitializer is not used much since the provisoning creates it
10:40 <vmassol> it's used only if someone deletes the descriptor
10:40 <vmassol> in order to recreate it
10:40 <vmassol> (I guess)
10:41 <vmassol> but I was mentioning that they both do similar stuff with code duplication
10:43 <vmassol> ok done, first BFD of the day for me ;)
10:51 <M-mouhb> Hello
10:55 <M-mouhb> I am working on an extension that is based on this task
10:55 <M-mouhb> https://jira.xwiki.org/browse/XWIKI-12650
10:56 <M-mouhb> I want your opinion to choose an appropriate name to the extension
11:00 <gdelhumeau> XWikiServerClassDocumentInitializer creates "XWiki.XWikiServerClass" on the main wiki
11:01 <gdelhumeau> I don't see any duplication
11:05 <vmassol> gdelhumeau: descriptors are all created on the main wiki
11:05 <vmassol> ah
11:06 <vmassol> hmmm
11:06 <vmassol> indeed my bad we have 3 different things:
11:06 <vmassol> - server class page creation
11:07 <vmassol> - main wik descriptor page creation
11:07 <vmassol> - subwiki descriptor page creation
11:07 <vmassol> I mixed server class page creation with subwiki descriptor page creation
11:17 <vmassol> second BFD!
11:17 <vmassol> (thanks to Edy who left a duplicate for me to close ;))
11:24 <ujjwal> has quit
11:30 <Enygma`> has joined #xwiki
11:32 <evalica> has joined #xwiki
11:49 <Pbas> Hi there :)! Someone tested/use groovy console applications http://extensions.xwiki.org/xwiki/bin/view/Extension/Groovy+Console+Application on recent xwiki (like 7.0.1 version)?
11:49 <Pbas> Is it still working?
11:50 <Pbas> Here, I just updated F10 shorcut in javascript, but impossible to launch console...
11:54 <Pbas> Ha ... log display naughty error like: Error at line 57, column 15: il manque ';' avant une instruction. Caused by: [ , value: "Execute (CTRL + E)" ] or Error at line 47, column 14: l'identifiant de propriété est incorrect. Caused by: [ , class: "xuake-console hidden"]
11:54 <Pbas> on XWiki.Xuake page :-(
12:04 <vmassol> Pbas: not used it recently myself
12:04 <Pbas> ok thxs
12:11 <vmassol> Enygma`: you missed the BFD mail yesterday I think
12:12 <vmassol> still time to catch up but you should do that quickly
12:12 <vmassol> creating contrib project for mahamed
12:28 <Enygma`> vmassol: sending it now
12:45 <ujjwal> has joined #xwiki
13:02 <vmassol> thanks
14:25 <vmassol> btw we still haven't migrated pages to NS on xwiki.org so we're still loosing the hierarchy ATM...
15:27 <msmeria> has quit
15:30 <ujjwal> has quit
16:06 <vmassol> and 3 (BFDs) :)
16:06 <vmassol> but 2 bugs added today so far
16:06 <vmassol> so winning only by 1
16:08 <Bugendol1> has joined #xwiki
16:13 <mflorea> has quit
16:13 <Bugendolf> has quit
16:25 <xwikiorg_guest_9> has joined #xwiki
16:27 <Trefex> has joined #xwiki
16:28 <xwikiorg_guest_9> Hello I've got a problem with my Xwiki Entreprise 7.3: when I create a new page into an existing space, the page is created into a new space named "EXISTINGSPACE.PAGENAME". Thank you for you help /HELP
16:29 <mflorea> has joined #xwiki
16:30 <vmassol> xwikiorg_guest_9: first I'd recommend using 7.4.2 since 7.3 was buggy and we had introduced nested spaces not long ago
16:33 <xwikiorg_guest_9> @vmassol ok so I will do that first. Thanks
16:41 <xwikiorg_guest_9> has quit
17:14 <xwikiorg_guest_6> has joined #xwiki
17:23 <vmassol> gdelhumeau: hmm I see you override the default LT query filters in siblings/children
17:23 <M-mouhb> has quit
17:23 <vmassol> so I guess it means all translations will be displayed
17:23 <vmassol> is that voluntary? because it's not consistent with AllDocs
17:24 <vmassol> actually no, you have unique used
17:24 <vmassol> still it's not consistent
17:24 <vmassol> AllDocs uses currentlanguage,hidden and children/siblings use unique,hidden
17:33 <M-jsimard> has joined #xwiki
17:33 <woshilapin> has quit
17:45 <xwikiorg_guest_6> has quit
17:48 <gdelhumeau> I guess currentlanguage should be added
17:48 <gdelhumeau> the incosistency was not voluntary
17:48 <vmassol> ok, I'll see what I can do
17:49 <vmassol> note that by being inconsistent you've fxied one issue we have for AllDocs
17:49 <vmassol> (but the date may not be correct)
17:50 <vmassol> gdelhumeau:another question for you
17:51 <vmassol> why have you introduced "childrenOf" in getdocuments.vm insted of using the existing "space" and adding extra where
17:51 <vmassol> ?
17:51 <vmassol> I'm fixing http://jira.xwiki.org/browse/XWIKI-13257 and childrenOf is really not generic
17:52 <vmassol> btw "space" should support NS probably
17:53 <vmassol> I see it's used in deletespace.vm
17:54 <gdelhumeau> I didn't want to touch the space viewer
17:54 <vmassol> hmm maybe you kept "space" for backward comapt with old skins
17:54 <vmassol> without NS
17:57 <vmassol> ok got it
18:03 <vmassol> hmm no I can't have a generic extra where clause since that would be a security hole
18:04 <cjd> has quit
18:09 <gdelhumeau> I have to go
18:09 <gdelhumeau> has quit
18:16 <vmassol> and 4!
18:19 <evalica> has quit
18:20 <evalica> has joined #xwiki
18:25 <M-mouhb> has joined #xwiki
18:25 <M-vmassol> has joined #xwiki
18:25 <M-cjd> has joined #xwiki
18:36 <lkrejci> has quit
18:48 <asam> has joined #xwiki
18:59 <mrvis> has joined #xwiki
19:02 <avisser> has quit
19:06 <cjd> has joined #xwiki
19:14 <mflorea> has quit
19:14 <asam_> has joined #xwiki
19:16 <asam> has quit
19:19 <vmassol1> has joined #xwiki
19:22 <evalica> has quit
19:22 <evalica> has joined #xwiki
19:22 <evalica> has quit
19:29 <Enygma`> has quit
19:44 <lkrejci> has joined #xwiki
20:05 <tmortagne> has quit
20:40 <lkrejci> has quit
20:41 <lkrejci> has joined #xwiki
21:06 <mflorea> has joined #xwiki
21:19 <Slashman> has quit
21:55 <mrvis> has quit
22:12 <sorinello> has quit
22:16 <asam_> has quit
22:29 <mflorea> has quit
23:34 <vmassol1> has quit
23:35 <vmassol> has joined #xwiki
