IRC Archive for channel #xwiki on 15 December 2014
Last modified by Vincent Massol on 2014/12/15 23:58
<xwikibot> has joined #xwiki
06:02 <Denis> has joined #xwiki
06:03 <Denis1> has quit
08:10 <_cjd> has quit
08:11 <msmeria> has joined #xwiki
08:35 <vmassol> has joined #xwiki
09:03 <tmortagne> has joined #xwiki
09:11 <cjd> has joined #xwiki
09:11 <cjd> is now known as <Guest52496>
09:12 <Guest52496> is now known as <_cjd>
09:18 <woshilapin> has joined #xwiki
09:18 <KermitTheFragger> has joined #xwiki
09:31 <Lyes> has joined #xwiki
09:33 <Enygma`> has joined #xwiki
09:35 <gdelhumeau> has joined #xwiki
09:45 <evalica> has joined #xwiki
09:50 <vmassol> Good morning
09:52 <vmassol> on my side I still need about 1/2 day for XWIKI-11541 and XWIKI-10789 but Lyes probably requires more so I'd say we should postpone the release to wednesday, wdyt?
09:52 <vmassol> we also have lots of test failures ATM
09:52 <vmassol> Enygma`: wdyt?
09:52 <gdelhumeau> Hello
09:53 <gdelhumeau> I would love to finish jira.xwiki.org/browse/XWIKI-10708 for M2
09:54 <Enygma`> vmassol: wednesday is not possible, since most of the XWiki committers will not be available
09:54 <vmassol> ah yes good point
09:54 <vmassol> Thursday, hoping we don't delay more?
09:54 <Enygma`> either tomorrow or thursday, instead of BFD (which nobody seems to participate lately anyway)
09:55 <tmortagne> nothing specifically blocker planned for 6.4M2 on my side
09:55 <Enygma`> I also need to finish the subwiki descriptor editing stuff too
09:55 <Enygma`> since the extension index will surely not make it
09:55 <Enygma`> so +1 for Thursday
09:56 <tmortagne> ok for Thursday
09:58 <evalica> gdelhumeau: when do you think you can commit? since I need to include XWIKI-11408 and I will need to do it on top of your work
09:59 <gdelhumeau> Actually it is comitted in the feature-less-ssx branch
09:59 <mflorea> has joined #xwiki
09:59 <gdelhumeau> but the problem is that there is a CLIRR bug that prevents us to compile my work
10:05 <lucaa> has joined #xwiki
10:21 <Slashman> has joined #xwiki
11:06 <Enygma`> Denis: could you please describe a little more the reason you are -1ing an issue that is on the current Roadmap?
11:06 <Enygma`> can you please elaborate a bit more on the reasons why you think it`s a bad idea to allow the subwiki's owner/admins to edit the subwiki`s descriptor?
11:07 <Enygma`> are you aware that this feature was also implemented in the workspaces feature (in its previous version) and that it was like that for a good while?
11:07 <Enygma`> nobody complained
11:07 <Enygma`> you also need to consider the 'workspace' scenario, where a wiki is a workspace, created by a global user; not a farm
11:07 <Denis> you seems to know by yourself, it cause security issue problem
11:07 <Enygma`> you`re confusing the issue with its implemention details
11:08 <Denis> not only
11:08 <Denis> I do not see why an owner needs or should be able to change the values you expect to allow them to edit
11:08 <Denis> you have not described your UC
11:08 <Denis> and I do not see any
11:09 <Enygma`> I assumed people were aware of the previous workspaces implemenation and discussions and that I would not have to reiterate all the usecases we have for subwikis
11:10 <Denis> sorry, but I do not get the UC you try to solve
11:10 <Enygma`> so if you have a global user creating a subwiki, the values he filled in the first place will become read-only
11:10 <Enygma`> ...
11:10 <Denis> yes for the owner, but not for the global admin
11:11 <Enygma`> 1. changing the wiki name
11:11 <Enygma`> 2. changing the wiki description
11:11 <Enygma`> 3. changing the wiki owner
11:11 <Enygma`> Denis: so you think it`s ok for the owner to be read only on those values?
11:12 <Enygma`> on an entity he created?
11:12 <Enygma`> where is the consistency with page owner then?
11:12 <Enygma`> I fail to see the logic
11:13 <Denis> it seems I miss a point
11:13 <Denis> do you means that a workspace could be created by somebody who is not a global admin ?
11:14 <Denis> I do not get how someone could fill that information and cannot edit it later actually ?
11:15 <Enygma`> the whole point of Workspaces (old feature) was to allow regular global users to create subwikis to structure their content
11:15 <Enygma`> you probably missed that
11:15 <Enygma`> the new wikis feature introduces the createWiki rights that can be given to regular users (non admins)
11:16 <Enygma`> once they create a wiki, they use the script service, and a descriptor document is also created in the mainWiki:XWiki space
11:16 <Enygma`> this does not mean that users have edit rights on that document
11:16 <Enygma`> however, users might want to come back on their choices to change them
11:16 <Denis> ok, so that means you need to add right on the descriptor to the creator of the descriptor in first place
11:16 <Enygma`> since they do not have rights, they can not
11:17 <Enygma`> was thinking about that too
11:17 <Enygma`> however, that is not really the issue here
11:17 <Enygma`> you seemed to -1 the idea itself
11:18 <Denis> I am not against such a solution, it is clean and consistant with the security methods we have
11:19 <Denis> and I admit that have forgotten that createwiki right
11:19 <Denis> what I am -1 one actually, is to give the owner of the wiki those right
11:19 <Denis> owner and creator are not exactly the same
11:20 <Enygma`> a wiki is more than a document, so the owner can be changed at some point in the wiki's lifecycle
11:20 <Enygma`> it makes sense to base rights on the wiki owner instead of wiki creator
11:20 <Enygma`> only the previous owner should be able to change the owner
11:20 <Denis> I am -1 one on that, it does not fit all our UC
11:20 <Enygma`> all other fields can be changed by the subwiki`s admins
11:21 <Enygma`> why?
11:21 <Enygma`> what is the problem with a user transferring ownership over his created wikis?
11:21 <Denis> owner does not have to have the createwiki right, and match the creator
11:21 <Enygma`> I think you`re confusing things
11:22 <Enygma`> what does a subwiki`s owner have to do with the createWiki right?
11:22 <Denis> you could have a manager who create wikis for separate owner, without allowing them to create wiki by themselves
11:22 <Enygma`> createWiki is given to user X
11:22 <Enygma`> user X creates a new wiki
11:22 <Enygma`> user X changes the owner of wiki W1 to user Y
11:22 <Enygma`> user Y is the new owner of W1
11:23 <Denis> this manager will not like to see a wiki he create for a given owner being given to another owner and being change of name or meaning
11:23 <Enygma`> that does not mean that if user Y did not have createWiki before, he will now inherit it, nothing to do with that
11:23 <Enygma`> wait, what?
11:23 <Enygma`> hmm
11:24 <Enygma`> if you would really want to establish such a use case, what is stopping you from keeping the owner status for yourself?
11:25 <Enygma`> so GodOfWikis creates subwiki W1 and adds some users and makes them admins. Period. GodOfWikis will be the owner of all the wikis he creates.
11:25 <Enygma`> nobody except GodOfWikis can change that.
11:25 <Denis> it is a matter of keeping the control of subwiki in the hand of a manager independently from the owners, and the myxwiki.org farm could be an example of that
11:25 <Enygma`> does the above satisfy your usecase?
11:25 <Denis> no
11:25 <Enygma`> why?
11:26 <Enygma`> what is the problem with transferring ownership?
11:26 <Enygma`> you trust user X, you allow him to create wikis OR you give him owner over a wiki
11:26 <Enygma`> he breaks your trust by transferring ownership, you take action
11:27 <Denis> GOW given ownership of the wiki to individual owners so they manage the wikis, but those owner cannot change their wiki name, wiki purpose, themselve as a owner, they only manage the wiki
11:27 <Enygma`> why do you want to impose such a restrictive model just to fit one narrow use case?
11:27 <Enygma`> then you are confusing the 'owner' status with the 'admin' right.
11:27 <Enygma`> as I said, do not make them owners, make them subwiki admins
11:28 <Enygma`> they will not be able to transfer ownership
11:30 <Denis> We will not agree, I am afraid, and we need more discussion of this. IMO it is breaking the initial farm UC
11:32 <Enygma`> Denis: this feature was available in Workspaces by design: http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application
11:32 <Enygma`> http://extensions.xwiki.org/xwiki/bin/download/Extension/Workspace+Application/workspace%2Dadministration%2Dworkspaceconfiguration%2Dsection.png
11:32 <Enygma`> are you really serious?
11:34 <Denis> "The internal organisation of the workspace is left to its owner and its assigned admins." it does not include managing the name, access path, and attribution of ownership
11:35 <Enygma`> did you check the picture?
11:35 <Denis> And once again, we have several UC for subwiki, the workspace one is not the only one
11:35 <Enygma`> we`ve already had these discussions when we included workspaces by default in XEM
11:35 <Enygma`> on the list
11:38 <Denis> once again, I am not against giving the wiki creator write access to the descriptor he have created, but I do not agree the owner get such right, that's it. It will stop covering the use case where there is a manager who creates subwiki of independant owner, which is a farm UC
11:38 <Enygma`> the feature we are discussing was just lost in translation, gdelhumeau just confirmed it
11:38 <lucaa> has quit
11:42 <Lyes> has quit
11:47 <gdelhumeau> The "ownership" concept is precisly about modifying the wiki's parameters
11:48 <gdelhumeau> Denis: you can create a wiki, give the Admin right to someone without giving him the ownsership
11:49 <gdelhumeau> maybe it is not clear in the wiki creation wizard
11:49 <gdelhumeau> but you can administer a wiki without being the owner
11:56 <Lyes> has joined #xwiki
11:58 <Denis> gdelhumeau: there is a major difference between an admin and an owner. A owner keep its right what ever happen, while an admin could be throwed away by another admin.
11:59 <Denis> until today, the significance of the owner was not your definition, at least in the implementation and in my mind
12:00 <Denis> I strongly believe that diverting the security access to allow owner accessing wiki descriptor is a bad plan
12:17 <lucaa> has joined #xwiki
12:27 <Lyes> has quit
12:41 <lucaa> has quit
13:33 <Lyes> has joined #xwiki
13:39 <gsmeria> has joined #xwiki
13:51 <Lyes> has quit
13:51 <Lyes> has joined #xwiki
14:03 <lucaa> has joined #xwiki
14:04 <Slashman> has quit
14:05 <Slashman> has joined #xwiki
14:06 <_cjd> has quit
14:10 <_cjd> has joined #xwiki
15:08 <_cjd> has quit
15:13 <_cjd> has joined #xwiki
15:45 <_cjd> has quit
15:50 <_cjd> has joined #xwiki
16:16 <msmeria> has quit
16:26 <momomomomo> has joined #xwiki
16:27 <Denis1> has joined #xwiki
16:28 <Denis> has quit
16:46 <Enygma`> vmassol: what happens if there are more than 1 icons for the same category defined in a ConfigurableClass?
16:51 <momomomomo> has quit
16:55 <tmortagne> Enygma`: sounds like the unit test you added to useravatar macro is not enough to please jacoco
16:55 <tmortagne> [WARNING] Rule violated for bundle XWiki Platform - Rendering - Macro - User Avatar: instructions covered ratio is 0.93, but expected minimum is 0.98
16:56 <Enygma`> I made the jacoco gods angry :)
16:57 <tmortagne> vmassol: seems your refactoring of ConfigurableClass system broke org.xwiki.administration.test.ui.AdministrationTest.verifyGlobalAndSpaceSections
16:58 <Enygma`> tmortagne: will have a look, but not sure if there is more I can do there.
16:59 <tmortagne> I did not check what is not covered after your commit but at this level it's easy to have code that is hard to unit test yes
17:12 <_cjd> has quit
17:14 <Enygma`> gdelhumeau: I don`t remember, when exactly does the main wiki`s descriptor get created?
17:14 <gdelhumeau> tmortagne have refactored it
17:17 <Enygma`> ok, seems that the main wiki is treated specially and a virtual descriptor is returned if the document does not exist
17:17 <Enygma`> probably on the first save (modification) of that descriptor, the actual document gets created
17:18 <tmortagne> I don't remember the detail but yet you always get a descriptor for the main wiki event if none exist
17:42 <vmassol> Enygma`: "what happens if there are more than 1 icons for the same category defined in a ConfigurableClass?" the last one is used
17:42 <vmassol> tmortagne:
17:42 <vmassol> thanks, I'll check
17:56 <Enygma`> vmassol: just testing a recent snapshot and I don`t seem to notice the new "email" category from the issue`s screenshot
17:56 <Enygma`> in administration
17:57 <Enygma`> I can create new categories and plug into existing ones, but I no longer see the email section in configuration and imagine that it should be in that new "email" category from the issue`s screenshot, but I don`t see it anywhere
17:57 <vmassol> Enygma`: you won't see it :)
17:57 <vmassol> I didn't commit it
17:57 <Enygma`> ah :)
17:57 <Enygma`> ok then
17:57 <vmassol> I committed XWIKI-11562
17:58 <vmassol> and now I'm finishing XWIKI-11541
17:58 <vmassol> (writing some func test for it)
17:58 <Enygma`> ok, the picture threw me off balance :)
17:58 <vmassol> and then I'll commit XWIKI-10789
17:58 <vmassol> yes the picture is just an example
18:04 <gdelhumeau> has quit
18:05 <woshilapin> has quit
18:13 <Lyes> has quit
18:16 <Enygma`> any reason why a JSX gets triggered twice when viewing its document and both demanding it?
18:17 <Enygma`> it seems that the new label for on demand / on this document is now merged
18:17 <Enygma`> and the behavior I now observe is that the code in the JSX gets executed twice
18:18 <Enygma`> so both on-demand and on-this-document execute my JSX when I am viewing the containing document
18:19 <tmortagne> has quit
18:25 <gsmeria> has quit
18:42 <KermitTheFragger> has quit
18:44 <vmassol> wow I'm failing to build with maven some code
18:44 <vmassol> I get a JVM crash...
18:46 <vmassol> ok was a one off… I still can't build but no longer a JVM crash…
18:46 <vmassol> Caused by: java.io.FileNotFoundException: JAR entry META-INF/components.txt not found in /Users/vmassol/.m2/repository/org/xwiki/platform/xwiki-platform-container-servlet/6.4-SNAPSHOT/xwiki-platform-container-servlet-6.4-SNAPSHOT.jar
18:46 <vmassol> weird because the file is there
18:47 <vmassol> hmm I've removed this artfiact locally
18:47 <vmassol> and now I get: Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.xwiki.platform:xwiki-platform-container-servlet:jar:6.4-SNAPSHOT
18:48 <vmassol> trying a -U but I don't understand
18:50 <vmassol> yes worked with -U, strange
18:52 <vmassol> wow there are lots of wait times in the admin tests…. need to be fixed
18:55 <evalica> has quit
18:56 <Enygma`> has quit
19:00 <mflorea> has quit
19:07 <tmortagne> has joined #xwiki
19:10 <sdumitriu> has joined #xwiki
19:13 <lucaa> has quit
19:19 <momomomomo> has joined #xwiki
19:22 <cjd> has joined #xwiki
19:22 <cjd> is now known as <_cjd>
19:37 <Slashman> has quit
19:37 <momomomomo> has quit
19:46 <tmortagne> has quit
20:06 <lucaa> has joined #xwiki
20:07 <lucaa1> has joined #xwiki
20:10 <lucaa> has quit
20:14 <lucaa> has joined #xwiki
20:16 <lucaa1> has quit
20:18 <Lyes> has joined #xwiki
20:20 <lucaa> has quit
21:27 <momomomomo> has joined #xwiki
21:39 <lucaa> has joined #xwiki
21:51 <lucaa> has quit
22:03 <lucaa> has joined #xwiki
22:10 <lucaa> has quit
22:12 <Lyes> has quit
22:35 <lucaa> has joined #xwiki
23:12 <sdumitriu> has quit
23:14 <lucaa> has quit
23:15 <sdumitriu> has joined #xwiki
23:15 <lucaa> has joined #xwiki
23:31 <lucaa> has quit
23:34 <lucaa> has joined #xwiki
23:56 <momomomomo> has quit
23:58 <vmassol> has quit
06:02 <Denis> has joined #xwiki
06:03 <Denis1> has quit
08:10 <_cjd> has quit
08:11 <msmeria> has joined #xwiki
08:35 <vmassol> has joined #xwiki
09:03 <tmortagne> has joined #xwiki
09:11 <cjd> has joined #xwiki
09:11 <cjd> is now known as <Guest52496>
09:12 <Guest52496> is now known as <_cjd>
09:18 <woshilapin> has joined #xwiki
09:18 <KermitTheFragger> has joined #xwiki
09:31 <Lyes> has joined #xwiki
09:33 <Enygma`> has joined #xwiki
09:35 <gdelhumeau> has joined #xwiki
09:45 <evalica> has joined #xwiki
09:50 <vmassol> Good morning
09:52 <vmassol> on my side I still need about 1/2 day for XWIKI-11541 and XWIKI-10789 but Lyes probably requires more so I'd say we should postpone the release to wednesday, wdyt?
09:52 <vmassol> we also have lots of test failures ATM
09:52 <vmassol> Enygma`: wdyt?
09:52 <gdelhumeau> Hello
09:53 <gdelhumeau> I would love to finish jira.xwiki.org/browse/XWIKI-10708 for M2
09:54 <Enygma`> vmassol: wednesday is not possible, since most of the XWiki committers will not be available
09:54 <vmassol> ah yes good point
09:54 <vmassol> Thursday, hoping we don't delay more?
09:54 <Enygma`> either tomorrow or thursday, instead of BFD (which nobody seems to participate lately anyway)
09:55 <tmortagne> nothing specifically blocker planned for 6.4M2 on my side
09:55 <Enygma`> I also need to finish the subwiki descriptor editing stuff too
09:55 <Enygma`> since the extension index will surely not make it
09:55 <Enygma`> so +1 for Thursday
09:56 <tmortagne> ok for Thursday
09:58 <evalica> gdelhumeau: when do you think you can commit? since I need to include XWIKI-11408 and I will need to do it on top of your work
09:59 <gdelhumeau> Actually it is comitted in the feature-less-ssx branch
09:59 <mflorea> has joined #xwiki
09:59 <gdelhumeau> but the problem is that there is a CLIRR bug that prevents us to compile my work
10:05 <lucaa> has joined #xwiki
10:21 <Slashman> has joined #xwiki
11:06 <Enygma`> Denis: could you please describe a little more the reason you are -1ing an issue that is on the current Roadmap?
11:06 <Enygma`> can you please elaborate a bit more on the reasons why you think it`s a bad idea to allow the subwiki's owner/admins to edit the subwiki`s descriptor?
11:07 <Enygma`> are you aware that this feature was also implemented in the workspaces feature (in its previous version) and that it was like that for a good while?
11:07 <Enygma`> nobody complained
11:07 <Enygma`> you also need to consider the 'workspace' scenario, where a wiki is a workspace, created by a global user; not a farm
11:07 <Denis> you seems to know by yourself, it cause security issue problem
11:07 <Enygma`> you`re confusing the issue with its implemention details
11:08 <Denis> not only
11:08 <Denis> I do not see why an owner needs or should be able to change the values you expect to allow them to edit
11:08 <Denis> you have not described your UC
11:08 <Denis> and I do not see any
11:09 <Enygma`> I assumed people were aware of the previous workspaces implemenation and discussions and that I would not have to reiterate all the usecases we have for subwikis
11:10 <Denis> sorry, but I do not get the UC you try to solve
11:10 <Enygma`> so if you have a global user creating a subwiki, the values he filled in the first place will become read-only
11:10 <Enygma`> ...
11:10 <Denis> yes for the owner, but not for the global admin
11:11 <Enygma`> 1. changing the wiki name
11:11 <Enygma`> 2. changing the wiki description
11:11 <Enygma`> 3. changing the wiki owner
11:11 <Enygma`> Denis: so you think it`s ok for the owner to be read only on those values?
11:12 <Enygma`> on an entity he created?
11:12 <Enygma`> where is the consistency with page owner then?
11:12 <Enygma`> I fail to see the logic
11:13 <Denis> it seems I miss a point
11:13 <Denis> do you means that a workspace could be created by somebody who is not a global admin ?
11:14 <Denis> I do not get how someone could fill that information and cannot edit it later actually ?
11:15 <Enygma`> the whole point of Workspaces (old feature) was to allow regular global users to create subwikis to structure their content
11:15 <Enygma`> you probably missed that
11:15 <Enygma`> the new wikis feature introduces the createWiki rights that can be given to regular users (non admins)
11:16 <Enygma`> once they create a wiki, they use the script service, and a descriptor document is also created in the mainWiki:XWiki space
11:16 <Enygma`> this does not mean that users have edit rights on that document
11:16 <Enygma`> however, users might want to come back on their choices to change them
11:16 <Denis> ok, so that means you need to add right on the descriptor to the creator of the descriptor in first place
11:16 <Enygma`> since they do not have rights, they can not
11:17 <Enygma`> was thinking about that too
11:17 <Enygma`> however, that is not really the issue here
11:17 <Enygma`> you seemed to -1 the idea itself
11:18 <Denis> I am not against such a solution, it is clean and consistant with the security methods we have
11:19 <Denis> and I admit that have forgotten that createwiki right
11:19 <Denis> what I am -1 one actually, is to give the owner of the wiki those right
11:19 <Denis> owner and creator are not exactly the same
11:20 <Enygma`> a wiki is more than a document, so the owner can be changed at some point in the wiki's lifecycle
11:20 <Enygma`> it makes sense to base rights on the wiki owner instead of wiki creator
11:20 <Enygma`> only the previous owner should be able to change the owner
11:20 <Denis> I am -1 one on that, it does not fit all our UC
11:20 <Enygma`> all other fields can be changed by the subwiki`s admins
11:21 <Enygma`> why?
11:21 <Enygma`> what is the problem with a user transferring ownership over his created wikis?
11:21 <Denis> owner does not have to have the createwiki right, and match the creator
11:21 <Enygma`> I think you`re confusing things
11:22 <Enygma`> what does a subwiki`s owner have to do with the createWiki right?
11:22 <Denis> you could have a manager who create wikis for separate owner, without allowing them to create wiki by themselves
11:22 <Enygma`> createWiki is given to user X
11:22 <Enygma`> user X creates a new wiki
11:22 <Enygma`> user X changes the owner of wiki W1 to user Y
11:22 <Enygma`> user Y is the new owner of W1
11:23 <Denis> this manager will not like to see a wiki he create for a given owner being given to another owner and being change of name or meaning
11:23 <Enygma`> that does not mean that if user Y did not have createWiki before, he will now inherit it, nothing to do with that
11:23 <Enygma`> wait, what?
11:23 <Enygma`> hmm
11:24 <Enygma`> if you would really want to establish such a use case, what is stopping you from keeping the owner status for yourself?
11:25 <Enygma`> so GodOfWikis creates subwiki W1 and adds some users and makes them admins. Period. GodOfWikis will be the owner of all the wikis he creates.
11:25 <Enygma`> nobody except GodOfWikis can change that.
11:25 <Denis> it is a matter of keeping the control of subwiki in the hand of a manager independently from the owners, and the myxwiki.org farm could be an example of that
11:25 <Enygma`> does the above satisfy your usecase?
11:25 <Denis> no
11:25 <Enygma`> why?
11:26 <Enygma`> what is the problem with transferring ownership?
11:26 <Enygma`> you trust user X, you allow him to create wikis OR you give him owner over a wiki
11:26 <Enygma`> he breaks your trust by transferring ownership, you take action
11:27 <Denis> GOW given ownership of the wiki to individual owners so they manage the wikis, but those owner cannot change their wiki name, wiki purpose, themselve as a owner, they only manage the wiki
11:27 <Enygma`> why do you want to impose such a restrictive model just to fit one narrow use case?
11:27 <Enygma`> then you are confusing the 'owner' status with the 'admin' right.
11:27 <Enygma`> as I said, do not make them owners, make them subwiki admins
11:28 <Enygma`> they will not be able to transfer ownership
11:30 <Denis> We will not agree, I am afraid, and we need more discussion of this. IMO it is breaking the initial farm UC
11:32 <Enygma`> Denis: this feature was available in Workspaces by design: http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application
11:32 <Enygma`> http://extensions.xwiki.org/xwiki/bin/download/Extension/Workspace+Application/workspace%2Dadministration%2Dworkspaceconfiguration%2Dsection.png
11:32 <Enygma`> are you really serious?
11:34 <Denis> "The internal organisation of the workspace is left to its owner and its assigned admins." it does not include managing the name, access path, and attribution of ownership
11:35 <Enygma`> did you check the picture?
11:35 <Denis> And once again, we have several UC for subwiki, the workspace one is not the only one
11:35 <Enygma`> we`ve already had these discussions when we included workspaces by default in XEM
11:35 <Enygma`> on the list
11:38 <Denis> once again, I am not against giving the wiki creator write access to the descriptor he have created, but I do not agree the owner get such right, that's it. It will stop covering the use case where there is a manager who creates subwiki of independant owner, which is a farm UC
11:38 <Enygma`> the feature we are discussing was just lost in translation, gdelhumeau just confirmed it
11:38 <lucaa> has quit
11:42 <Lyes> has quit
11:47 <gdelhumeau> The "ownership" concept is precisly about modifying the wiki's parameters
11:48 <gdelhumeau> Denis: you can create a wiki, give the Admin right to someone without giving him the ownsership
11:49 <gdelhumeau> maybe it is not clear in the wiki creation wizard
11:49 <gdelhumeau> but you can administer a wiki without being the owner
11:56 <Lyes> has joined #xwiki
11:58 <Denis> gdelhumeau: there is a major difference between an admin and an owner. A owner keep its right what ever happen, while an admin could be throwed away by another admin.
11:59 <Denis> until today, the significance of the owner was not your definition, at least in the implementation and in my mind
12:00 <Denis> I strongly believe that diverting the security access to allow owner accessing wiki descriptor is a bad plan
12:17 <lucaa> has joined #xwiki
12:27 <Lyes> has quit
12:41 <lucaa> has quit
13:33 <Lyes> has joined #xwiki
13:39 <gsmeria> has joined #xwiki
13:51 <Lyes> has quit
13:51 <Lyes> has joined #xwiki
14:03 <lucaa> has joined #xwiki
14:04 <Slashman> has quit
14:05 <Slashman> has joined #xwiki
14:06 <_cjd> has quit
14:10 <_cjd> has joined #xwiki
15:08 <_cjd> has quit
15:13 <_cjd> has joined #xwiki
15:45 <_cjd> has quit
15:50 <_cjd> has joined #xwiki
16:16 <msmeria> has quit
16:26 <momomomomo> has joined #xwiki
16:27 <Denis1> has joined #xwiki
16:28 <Denis> has quit
16:46 <Enygma`> vmassol: what happens if there are more than 1 icons for the same category defined in a ConfigurableClass?
16:51 <momomomomo> has quit
16:55 <tmortagne> Enygma`: sounds like the unit test you added to useravatar macro is not enough to please jacoco
16:55 <tmortagne> [WARNING] Rule violated for bundle XWiki Platform - Rendering - Macro - User Avatar: instructions covered ratio is 0.93, but expected minimum is 0.98
16:56 <Enygma`> I made the jacoco gods angry :)
16:57 <tmortagne> vmassol: seems your refactoring of ConfigurableClass system broke org.xwiki.administration.test.ui.AdministrationTest.verifyGlobalAndSpaceSections
16:58 <Enygma`> tmortagne: will have a look, but not sure if there is more I can do there.
16:59 <tmortagne> I did not check what is not covered after your commit but at this level it's easy to have code that is hard to unit test yes
17:12 <_cjd> has quit
17:14 <Enygma`> gdelhumeau: I don`t remember, when exactly does the main wiki`s descriptor get created?
17:14 <gdelhumeau> tmortagne have refactored it
17:17 <Enygma`> ok, seems that the main wiki is treated specially and a virtual descriptor is returned if the document does not exist
17:17 <Enygma`> probably on the first save (modification) of that descriptor, the actual document gets created
17:18 <tmortagne> I don't remember the detail but yet you always get a descriptor for the main wiki event if none exist
17:42 <vmassol> Enygma`: "what happens if there are more than 1 icons for the same category defined in a ConfigurableClass?" the last one is used
17:42 <vmassol> tmortagne:
17:42 <vmassol> thanks, I'll check
17:56 <Enygma`> vmassol: just testing a recent snapshot and I don`t seem to notice the new "email" category from the issue`s screenshot
17:56 <Enygma`> in administration
17:57 <Enygma`> I can create new categories and plug into existing ones, but I no longer see the email section in configuration and imagine that it should be in that new "email" category from the issue`s screenshot, but I don`t see it anywhere
17:57 <vmassol> Enygma`: you won't see it :)
17:57 <vmassol> I didn't commit it
17:57 <Enygma`> ah :)
17:57 <Enygma`> ok then
17:57 <vmassol> I committed XWIKI-11562
17:58 <vmassol> and now I'm finishing XWIKI-11541
17:58 <vmassol> (writing some func test for it)
17:58 <Enygma`> ok, the picture threw me off balance :)
17:58 <vmassol> and then I'll commit XWIKI-10789
17:58 <vmassol> yes the picture is just an example
18:04 <gdelhumeau> has quit
18:05 <woshilapin> has quit
18:13 <Lyes> has quit
18:16 <Enygma`> any reason why a JSX gets triggered twice when viewing its document and both demanding it?
18:17 <Enygma`> it seems that the new label for on demand / on this document is now merged
18:17 <Enygma`> and the behavior I now observe is that the code in the JSX gets executed twice
18:18 <Enygma`> so both on-demand and on-this-document execute my JSX when I am viewing the containing document
18:19 <tmortagne> has quit
18:25 <gsmeria> has quit
18:42 <KermitTheFragger> has quit
18:44 <vmassol> wow I'm failing to build with maven some code
18:44 <vmassol> I get a JVM crash...
18:46 <vmassol> ok was a one off… I still can't build but no longer a JVM crash…
18:46 <vmassol> Caused by: java.io.FileNotFoundException: JAR entry META-INF/components.txt not found in /Users/vmassol/.m2/repository/org/xwiki/platform/xwiki-platform-container-servlet/6.4-SNAPSHOT/xwiki-platform-container-servlet-6.4-SNAPSHOT.jar
18:46 <vmassol> weird because the file is there
18:47 <vmassol> hmm I've removed this artfiact locally
18:47 <vmassol> and now I get: Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.xwiki.platform:xwiki-platform-container-servlet:jar:6.4-SNAPSHOT
18:48 <vmassol> trying a -U but I don't understand
18:50 <vmassol> yes worked with -U, strange
18:52 <vmassol> wow there are lots of wait times in the admin tests…. need to be fixed
18:55 <evalica> has quit
18:56 <Enygma`> has quit
19:00 <mflorea> has quit
19:07 <tmortagne> has joined #xwiki
19:10 <sdumitriu> has joined #xwiki
19:13 <lucaa> has quit
19:19 <momomomomo> has joined #xwiki
19:22 <cjd> has joined #xwiki
19:22 <cjd> is now known as <_cjd>
19:37 <Slashman> has quit
19:37 <momomomomo> has quit
19:46 <tmortagne> has quit
20:06 <lucaa> has joined #xwiki
20:07 <lucaa1> has joined #xwiki
20:10 <lucaa> has quit
20:14 <lucaa> has joined #xwiki
20:16 <lucaa1> has quit
20:18 <Lyes> has joined #xwiki
20:20 <lucaa> has quit
21:27 <momomomomo> has joined #xwiki
21:39 <lucaa> has joined #xwiki
21:51 <lucaa> has quit
22:03 <lucaa> has joined #xwiki
22:10 <lucaa> has quit
22:12 <Lyes> has quit
22:35 <lucaa> has joined #xwiki
23:12 <sdumitriu> has quit
23:14 <lucaa> has quit
23:15 <sdumitriu> has joined #xwiki
23:15 <lucaa> has joined #xwiki
23:31 <lucaa> has quit
23:34 <lucaa> has joined #xwiki
23:56 <momomomomo> has quit
23:58 <vmassol> has quit
