+1 to remove it since we did not really use it in the end. <thread-highjacking> Side note: Re XClasses in UI modules, I am beginning more and more to think that we need to use a new convention that is additional to -ui and -api packages which should be targeted at an extension's model when it involves XClasses. Mentioning this because XClasses are not really UI and are needed really by the -api modules more than the -ui modules. Also, there are a lot of cases when an extension X depends on extension Y-api, but that extension also has XClasses defined in its Y-ui module which would force extension X to actually depend on Y-ui which is not right IMO. Perhaps this deserves a thread of its own. Side note2: Re mandatory classes defined in Java, I am really more in favor of XClasses defined in XMLs instead of java (since most of the time the java classes are non-conditional, i.e. the properties we add do not depend on certain conditions so they can easily be replaced by a static XML), all we need is to add a new meta-property to a class that defines it as mandatory. Again, perhaps a separate thread. </thread-highjacking> Thanks, Eduard On Fri, Mar 20, 2015 at 12:57 PM, [email protected] <[email protected]> wrote:

Hi devs,

In xwiki-enteprise we have XWiki.RequiredRightClass. We’ve started discussing it in the past in the “Split XE pages” mail thread and I’d like to move forward.

So we need to decide what to do about it. Several options:

* We discussed moving it to xwiki-platform-administration but it shouldn’t go there IMO since we’re trying to make this module almost empty (just providing the extension points mechanism) and have admin features dispatched in the modules providing them. Also it would mean forcing unnecessary dependencies on xwiki-platform-administration from several modules (6-7 right now). * It could go in a new xwiki-platform-security-ui module. * It could be moved to Java but we don’t have a clear policy nor decision if we want to favor xclasses written in java or opposite, decide that we don’t want that and move away from XClasses in Java. So we’d need to decide this first. * We could also simply remove it! Rationale: ** I don’t think we’re using that information much and its need is supposed to go away once signed scripts is there ** There’s no way to force pages requiring PR to add such an XObject and thus it’s not done consistently ** We don’t even have a page listing all pages requiring PR and even if we had one I’m not exactly what it would bring. I guess the idea was to make it simpler to install/upgrade XWiki but we’ve fixed this already in the Wiki Creation Wizard for example so the need is less now.

So overall I’m more in favor of dropping this experiment which IMO wasn’t very successful.

WDYT?

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Fri, Mar 20, 2015 at 11:57 AM, [email protected] <[email protected]> wrote:

Hi devs,

In xwiki-enteprise we have XWiki.RequiredRightClass. We’ve started discussing it in the past in the “Split XE pages” mail thread and I’d like to move forward.

So we need to decide what to do about it. Several options:

* We discussed moving it to xwiki-platform-administration but it shouldn’t go there IMO since we’re trying to make this module almost empty (just providing the extension points mechanism) and have admin features dispatched in the modules providing them. Also it would mean forcing unnecessary dependencies on xwiki-platform-administration from several modules (6-7 right now). * It could go in a new xwiki-platform-security-ui module. * It could be moved to Java but we don’t have a clear policy nor decision if we want to favor xclasses written in java or opposite, decide that we don’t want that and move away from XClasses in Java. So we’d need to decide this first. * We could also simply remove it! Rationale: ** I don’t think we’re using that information much and its need is supposed to go away once signed scripts is there

I agree, once the signed script is there, until that wished moment, it is a useful feature that we have under used.

** There’s no way to force pages requiring PR to add such an XObject and thus it’s not done consistently

There is an easy way, enforce it and do not provide programming right to pages that does not explicitely require it using that object.

** We don’t even have a page listing all pages requiring PR and even if we had one I’m not exactly what it would bring. I guess the idea was to make it simpler to install/upgrade XWiki but we’ve fixed this already in the Wiki Creation Wizard for example so the need is less now.

That is not true, the Admin Tools has a page showing pages having a content author without PR and allow fixing the issue.

So overall I’m more in favor of dropping this experiment which IMO wasn’t very successful.

WDYT?

So either you move it to an extension module, so extension could continue to get it as a deps, but like Marius said, it is somehow an API breakage. Or you move it to the security module, and you enforce its usage. Taking into account that enforcing its usage would dramatically improve the leak of PR, I am in favor of that, despite the migration requirements. A good script could really take care of that migration.

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO