Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Eduard Moraru]

Guys, remember that we now have an Application Index, where you can browse
and discover all the relevant installed extensions. So this part of
responsibility should no longer be handled by the Apps Panel (since it
never was capable to do so anyway).

Applications will still have to provide either an UIX or a descriptor (with
name, icon and homepage), but IMO that should be targeting the Application
Index and not the App Panel. The Application Index will be the one going
through all applications and listing them. However, the App Panel should
only go through a list from the configuration (either set by the admin or
the current wiki, see my previous mention about per-user Apps Panels) and
only display the apps in that list.

I have 2 examples/analogies that I can think of when apps are automatically
added to your "desktop": on an operating system (i.e. windows, etc.; but
even there you have a checkbox in the installer to not do that) and in
Android OS (where the just installed app is added to one of your screens,
but can be removed). However, for an implementation solution, I find it
counterproductive/counterintuitive to have to manage a blacklist of *all*
the installed apps, except 2-3 that you want to be displayed, instead of
managing a whitelist with *only* the apps you want to see.

Going along these lines, I propose that, instead of automatically listing
all app UIXs and then have to blacklist, we try to find a way (listener?)
to just *add* an application to the whitelist automatically, when it is
installed, so that the admin can remove it if he does not want it there
(like removing a link from desktop or from you Android OS screens, but you
can still find the app in the App Index, later on).

P.S.: All this talk takes us back to the Application Descriptor topic that
we keep avoiding and keep trying to find quirky ways to work around it.

Thanks,
Eduard

On Thu, Oct 6, 2016 at 6:56 PM, Sergiu Dumitriu  wrote:

> On 10/06/2016 11:36 AM, Vincent Massol wrote:
> > Hi Sergiu,
> >
> >> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  wrote:
> >>
> >> The way I do this for another similar feature, using UIX objects, is to
> >> add two new parameters, "enabled" and "order". When displaying the
> >> extensions for a particular point, I request them ordered by the "order"
> >> parameter, and then manually skip those for which the "enabled"
> >> parameter is set to "false" -- if the parameter is missing, it's
> >> considered enabled by default.
> >>
> >> We can define that the order should have a value between 0 and 100, and
> >> each extension can choose it's own relative number, as an expected
> >> percentage, with the actual order depending on which other extensions
> >> are installed and enabled, and their requested order.
> >
> > Yes but IMO this wouldn’t work here for this use case because the
> information as to whether a given app is displayed or not should not come
> from the UIX itself (the app doesn’t know that info and shouldn’t set
> this). It should come from the admin or from the flavor for this case at
> hand.
> >
> > Also I don’t think that modifying the UIX of an app by the Application
> Panel admin UI is a good thing. The storage if this info should go in the
> App Panel config page instead IMO.
> >
> > WDYT?
>
> True, I was just presenting another approach, which, by the way, also
> has limitations that are making me look for improvements.
>
> I don't agree that the application shouldn't know whether it's suitable
> for being displayed or not. Who knows that an extension is too technical
> to be displayed? Certainly not the Panels application, and flavors can't
> know beforehand all the extensions that may be installed. I think that
> the application developers are the ones that should decide if their
> application is to be displayed by default or not.
>
> And these are just initial hints, the admins can then choose to change
> the default and manually hide/show/reorder applications.
>
> Now, for the fact that the parameters are stored *only* in the
> extension, that does indeed cause several problems:
>
> - modifying them may cause extension upgrade conflicts
> - only one global setting, no user or space settings
> - flavors can't override these settings
>
> How about this: we define a way of overriding extension parameters using
> custom objects:
>
> XWiki.UIExtensionParameterOverridesClass
> - extensionPointId
> - name
> - parameters
>
> extensionPointId and name must match an UIX, and parameters override the
> extension's parameters.
>
> Depending on where the object it placed, it can be valid for:
> - the whole wiki if placed in XWiki.XWikiPreferences
> - a space if placed in .WebPreferences
> - a certain user if placed in XWiki.
> - any other page, and have a way of telling the uix manager that we want
> to apply the parameter overrides in that page
> - not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
> there a flavor-specific 

Re: [xwiki-devs] [xwiki-users] Fw : Re: Issues when I upgraded my xwiki 7.0.1 to xwiki 8.2.1: search feature

[Sergiu Dumitriu]

Something like this:
https://github.com/phenotips/phenotips/blob/b5fd2933480bcdeaca0194840b1c84585e763452/components/vocabularies/api/src/main/java/org/phenotips/vocabulary/internal/solr/DefaultSolrVocabularyResourceManager.java#L88-L113

On 10/04/2016 05:56 AM, Vincent Massol wrote:
> 
>> On 04 Oct 2016, at 11:54, Pascal BASTIEN  wrote:
>>
>> Thanks, you are right I forgot to removed solr subdirectory before upgrade.
>>
>> stop + rm + start xwiki = xwiki work again like a charm
>> (sorry ;-) )
> 
> cool
> 
> you don’t need to be sorry. We need to improve this. Like forcing 
> automatically the removal when we upgrade solr and there’s been some schema 
> changes.
> 
> -Vincent
> 
>> Thxs
>>
>> --- En date de : Mar 4.10.16, Vincent Massol  a écrit :
>>
>>> De: Vincent Massol 
>>> Objet: Re: [xwiki-users] Issues when I upgraded my xwiki 7.0.1 to xwiki 
>>> 8.2.1: search feature
>>> À: "XWiki Users" 
>>> Date: Mardi 4 octobre 2016, 11h36
>>> Hi,
>>>
>>> Try removing your solr index.
>>>
>>> Thanks
>>> -Vincent
>>>

>>> On 04 Oct 2016, at 11:26, Pascal BASTIEN 
>>> wrote:

 Hello,

 After upgrading my
>>> xwiki 7.0.1 to 8.2.1, i encoutered another issue: xwiki
>>> search feature doesn't work anymore.
 I use Tomcat 8.0.33 + Postrgesqk 9.3 and
>>> attachments in file system and connected with Admin
>>> account.

 On page
>>> ./bin/view/Main/Search?text=test_type=DOCUMENT_locale=fr_locale==1
>>> , I have this ugly error message displayed:
 "Failed to execute the [velocity]
>>> macro. Cause: [The resolver parameter doesn't contain an
>>> Entity Reference of type [SPACE]]. Click on this message for
>>> details."

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


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Sergiu Dumitriu]

On 10/06/2016 11:36 AM, Vincent Massol wrote:
> Hi Sergiu,
> 
>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  wrote:
>>
>> The way I do this for another similar feature, using UIX objects, is to
>> add two new parameters, "enabled" and "order". When displaying the
>> extensions for a particular point, I request them ordered by the "order"
>> parameter, and then manually skip those for which the "enabled"
>> parameter is set to "false" -- if the parameter is missing, it's
>> considered enabled by default.
>>
>> We can define that the order should have a value between 0 and 100, and
>> each extension can choose it's own relative number, as an expected
>> percentage, with the actual order depending on which other extensions
>> are installed and enabled, and their requested order.
> 
> Yes but IMO this wouldn’t work here for this use case because the information 
> as to whether a given app is displayed or not should not come from the UIX 
> itself (the app doesn’t know that info and shouldn’t set this). It should 
> come from the admin or from the flavor for this case at hand.
> 
> Also I don’t think that modifying the UIX of an app by the Application Panel 
> admin UI is a good thing. The storage if this info should go in the App Panel 
> config page instead IMO.
> 
> WDYT?

True, I was just presenting another approach, which, by the way, also
has limitations that are making me look for improvements.

I don't agree that the application shouldn't know whether it's suitable
for being displayed or not. Who knows that an extension is too technical
to be displayed? Certainly not the Panels application, and flavors can't
know beforehand all the extensions that may be installed. I think that
the application developers are the ones that should decide if their
application is to be displayed by default or not.

And these are just initial hints, the admins can then choose to change
the default and manually hide/show/reorder applications.

Now, for the fact that the parameters are stored *only* in the
extension, that does indeed cause several problems:

- modifying them may cause extension upgrade conflicts
- only one global setting, no user or space settings
- flavors can't override these settings

How about this: we define a way of overriding extension parameters using
custom objects:

XWiki.UIExtensionParameterOverridesClass
- extensionPointId
- name
- parameters

extensionPointId and name must match an UIX, and parameters override the
extension's parameters.

Depending on where the object it placed, it can be valid for:
- the whole wiki if placed in XWiki.XWikiPreferences
- a space if placed in .WebPreferences
- a certain user if placed in XWiki.
- any other page, and have a way of telling the uix manager that we want
to apply the parameter overrides in that page
- not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
there a flavor-specific configuration page?

How does that sound?

> Thanks
> -Vincent
> 
>> As a more advanced feature, in PhenoTips we also have a wizard that
>> allows enabling/disabling and manually reordering extensions, by
>> modifying the extension parameters.
>>
>> I didn't have time for this yet, but in the future I'd like to add
>> support for ordering and enable/disable flags in the core UIX module, so
>> that extensions are automatically filtered and ordered.
>>
>> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>>> Hi devs,
>>>
>>> With the recent introduction of the Applications Index (see 
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Application/)
>>>  we need to agree on a few things.
>>>
>>> In the past we had:
>>> * We wanted all new app that you installed to automatically be visible in 
>>> the Applications Panel
>>> * This is why the Applications Panel config had a blacklist (and not a 
>>> white list)
>>>
>>> What we’ve done:
>>> * We add the Applications Index
>>> * We removed some apps from the Applications Panel. Namely: Invitation, 
>>> Panels, Scheduler, User Directory and Tour applications. this was done 
>>> using hardcoded blacklist xobjects in 
>>> PanelsCode.ApplicationsPanelConfiguration.
>>>
>>> The need:
>>> * We need to remove this hack. It’s not normal for the Panels module to 
>>> know all the apps that shouldn’t be listed in it!
>>>
>>> Proposal:
>>> * Replace the blacklist configuration of the Applications Panel by a 
>>> whitelist one
>>> * When a new app is installed, list it in the Applications Index but don’t 
>>> add it to the Applications Panel
>>> * If an admin wants to add this new for his users, he’ll need to add it in 
>>> the Admin UI for the Applications Panel.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>>
>>

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Vincent Massol]

Hi Sergiu,

> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  wrote:
> 
> The way I do this for another similar feature, using UIX objects, is to
> add two new parameters, "enabled" and "order". When displaying the
> extensions for a particular point, I request them ordered by the "order"
> parameter, and then manually skip those for which the "enabled"
> parameter is set to "false" -- if the parameter is missing, it's
> considered enabled by default.
> 
> We can define that the order should have a value between 0 and 100, and
> each extension can choose it's own relative number, as an expected
> percentage, with the actual order depending on which other extensions
> are installed and enabled, and their requested order.

Yes but IMO this wouldn’t work here for this use case because the information 
as to whether a given app is displayed or not should not come from the UIX 
itself (the app doesn’t know that info and shouldn’t set this). It should come 
from the admin or from the flavor for this case at hand.

Also I don’t think that modifying the UIX of an app by the Application Panel 
admin UI is a good thing. The storage if this info should go in the App Panel 
config page instead IMO.

WDYT?

Thanks
-Vincent

> As a more advanced feature, in PhenoTips we also have a wizard that
> allows enabling/disabling and manually reordering extensions, by
> modifying the extension parameters.
> 
> I didn't have time for this yet, but in the future I'd like to add
> support for ordering and enable/disable flags in the core UIX module, so
> that extensions are automatically filtered and ordered.
> 
> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>> Hi devs,
>> 
>> With the recent introduction of the Applications Index (see 
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Application/)
>>  we need to agree on a few things.
>> 
>> In the past we had:
>> * We wanted all new app that you installed to automatically be visible in 
>> the Applications Panel
>> * This is why the Applications Panel config had a blacklist (and not a white 
>> list)
>> 
>> What we’ve done:
>> * We add the Applications Index
>> * We removed some apps from the Applications Panel. Namely: Invitation, 
>> Panels, Scheduler, User Directory and Tour applications. this was done using 
>> hardcoded blacklist xobjects in PanelsCode.ApplicationsPanelConfiguration.
>> 
>> The need:
>> * We need to remove this hack. It’s not normal for the Panels module to know 
>> all the apps that shouldn’t be listed in it!
>> 
>> Proposal:
>> * Replace the blacklist configuration of the Applications Panel by a 
>> whitelist one
>> * When a new app is installed, list it in the Applications Index but don’t 
>> add it to the Applications Panel
>> * If an admin wants to add this new for his users, he’ll need to add it in 
>> the Admin UI for the Applications Panel.
>> 
>> WDYT?
>> 
>> Thanks
>> -Vincent
>> 
> 
> 
> -- 
> Sergiu Dumitriu
> http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [PROPOSAL] Stabilize filesystem templates rights

[Sergiu Dumitriu]

+1 for 1.

On 10/05/2016 05:29 AM, Thomas Mortagne wrote:
> Hi devs,
> 
> Right now (and since forever) the default behavior for templates is to
> be executed with the right of the current document content author
> (it's not really explicit, it's just how PR works when there is no
> sdoc). This means that unless you explicitly indicate an author for
> your template (possible since 7.x) you don't really have any idea
> which right it's going to have at runtime. It also make harder to
> properly execute templates outside of main rendering thread where the
> "current document" often don't really make much sense.
> 
> I think we should make the default more stable.
> 
> I can think of two possibilities:
> 
> 1) with what we got right now the only real possibility is to execute
> the filesystem template with superadmin right (which is only an option
> right now). Makes it consistent with the "code is executed with the
> right of its author" rule we have for wiki pages
> 2) introduce some new virtual user (like "templateauthor" or
> "scripter" or whatever) which only have script right and use that as
> filesystem template author if we absolutely want template to not have
> too many rights by default (even if modifying a filesystem template
> require much more access than superadmin in practice)
> 
> +1 for 1)
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Sergiu Dumitriu]

The way I do this for another similar feature, using UIX objects, is to
add two new parameters, "enabled" and "order". When displaying the
extensions for a particular point, I request them ordered by the "order"
parameter, and then manually skip those for which the "enabled"
parameter is set to "false" -- if the parameter is missing, it's
considered enabled by default.

We can define that the order should have a value between 0 and 100, and
each extension can choose it's own relative number, as an expected
percentage, with the actual order depending on which other extensions
are installed and enabled, and their requested order.

As a more advanced feature, in PhenoTips we also have a wizard that
allows enabling/disabling and manually reordering extensions, by
modifying the extension parameters.

I didn't have time for this yet, but in the future I'd like to add
support for ordering and enable/disable flags in the core UIX module, so
that extensions are automatically filtered and ordered.

On 10/05/2016 05:37 AM, Vincent Massol wrote:
> Hi devs,
> 
> With the recent introduction of the Applications Index (see 
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Application/)
>  we need to agree on a few things.
> 
> In the past we had:
> * We wanted all new app that you installed to automatically be visible in the 
> Applications Panel
> * This is why the Applications Panel config had a blacklist (and not a white 
> list)
> 
> What we’ve done:
> * We add the Applications Index
> * We removed some apps from the Applications Panel. Namely: Invitation, 
> Panels, Scheduler, User Directory and Tour applications. this was done using 
> hardcoded blacklist xobjects in PanelsCode.ApplicationsPanelConfiguration.
> 
> The need:
> * We need to remove this hack. It’s not normal for the Panels module to know 
> all the apps that shouldn’t be listed in it!
> 
> Proposal:
> * Replace the blacklist configuration of the Applications Panel by a 
> whitelist one
> * When a new app is installed, list it in the Applications Index but don’t 
> add it to the Applications Panel
> * If an admin wants to add this new for his users, he’ll need to add it in 
> the Admin UI for the Applications Panel.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [PROPOSAL] Stabilize filesystem templates rights

[Guillaume Delhumeau]

+1 for 1)

2016-10-06 17:19 GMT+02:00 Thomas Mortagne :

> On Thu, Oct 6, 2016 at 5:16 PM, Ecaterina Moraru (Valica)
>  wrote:
> > I don't really understand what this is about, but aren't all the
> templates
> > overriddeble from the Skin?
>
> Forget about wiki templates for now. I'm only talking about the rights
> filesystem templates should have here :)
>
> > Anyway, I wouldn't want to have an additional virtual user.
> >
> > Thanks,
> > Caty
> >
> > On Wed, Oct 5, 2016 at 7:03 PM, Eduard Moraru 
> wrote:
> >
> >> +1 for 1), with the reminder that filesystem templates are considered
> to be
> >> managed/authored by the superadmin, while Skin template overrides will
> be
> >> managed/authored by the Skin document's author, so overriding a template
> >> from a skin will not give you superadmin author rights.
> >>
> >> Thanks,
> >> Eduard
> >>
> >> On Wed, Oct 5, 2016 at 12:29 PM, Thomas Mortagne <
> >> thomas.morta...@xwiki.com>
> >> wrote:
> >>
> >> > Hi devs,
> >> >
> >> > Right now (and since forever) the default behavior for templates is to
> >> > be executed with the right of the current document content author
> >> > (it's not really explicit, it's just how PR works when there is no
> >> > sdoc). This means that unless you explicitly indicate an author for
> >> > your template (possible since 7.x) you don't really have any idea
> >> > which right it's going to have at runtime. It also make harder to
> >> > properly execute templates outside of main rendering thread where the
> >> > "current document" often don't really make much sense.
> >> >
> >> > I think we should make the default more stable.
> >> >
> >> > I can think of two possibilities:
> >> >
> >> > 1) with what we got right now the only real possibility is to execute
> >> > the filesystem template with superadmin right (which is only an option
> >> > right now). Makes it consistent with the "code is executed with the
> >> > right of its author" rule we have for wiki pages
> >> > 2) introduce some new virtual user (like "templateauthor" or
> >> > "scripter" or whatever) which only have script right and use that as
> >> > filesystem template author if we absolutely want template to not have
> >> > too many rights by default (even if modifying a filesystem template
> >> > require much more access than superadmin in practice)
> >> >
> >> > +1 for 1)
> >> >
> >> > --
> >> > Thomas Mortagne
> >> > ___
> >> > devs mailing list
> >> > devs@xwiki.org
> >> > http://lists.xwiki.org/mailman/listinfo/devs
> >> >
> >> ___
> >> devs mailing list
> >> devs@xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [PROPOSAL] Stabilize filesystem templates rights

[Ecaterina Moraru (Valica)]

I don't really understand what this is about, but aren't all the templates
overriddeble from the Skin?
Anyway, I wouldn't want to have an additional virtual user.

Thanks,
Caty

On Wed, Oct 5, 2016 at 7:03 PM, Eduard Moraru  wrote:

> +1 for 1), with the reminder that filesystem templates are considered to be
> managed/authored by the superadmin, while Skin template overrides will be
> managed/authored by the Skin document's author, so overriding a template
> from a skin will not give you superadmin author rights.
>
> Thanks,
> Eduard
>
> On Wed, Oct 5, 2016 at 12:29 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> wrote:
>
> > Hi devs,
> >
> > Right now (and since forever) the default behavior for templates is to
> > be executed with the right of the current document content author
> > (it's not really explicit, it's just how PR works when there is no
> > sdoc). This means that unless you explicitly indicate an author for
> > your template (possible since 7.x) you don't really have any idea
> > which right it's going to have at runtime. It also make harder to
> > properly execute templates outside of main rendering thread where the
> > "current document" often don't really make much sense.
> >
> > I think we should make the default more stable.
> >
> > I can think of two possibilities:
> >
> > 1) with what we got right now the only real possibility is to execute
> > the filesystem template with superadmin right (which is only an option
> > right now). Makes it consistent with the "code is executed with the
> > right of its author" rule we have for wiki pages
> > 2) introduce some new virtual user (like "templateauthor" or
> > "scripter" or whatever) which only have script right and use that as
> > filesystem template author if we absolutely want template to not have
> > too many rights by default (even if modifying a filesystem template
> > require much more access than superadmin in practice)
> >
> > +1 for 1)
> >
> > --
> > Thomas Mortagne
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal][UX] Change the user type for the Admin user to 'simple'

[Vincent Massol]

> On 06 Oct 2016, at 15:32, Ecaterina Moraru (Valica)  wrote:
> 
> Hi,
> 
> A simple change that could improve the experience for newcomers would be
> that the default Admin user to have a simple type.
> 
> One of the problems new users have is that they have too many options in
> the Edit menu and this can be confusing.
> 
> The downside is that it will add an additional step for developers/testers
> to change the user type back (or at least until we provide a Developer
> user/profile).
> 
> Also we would need to make sure the documentation is up to date and fix the
> tests.
> 
> WDTY?

+1 I think this is an important change that is simple to make and that’ll 
remove confusion for newcomers.

Side note/wish: I’d love a shortcut key that you’d press to make the current 
user advanced + show hidden docs. And if you press it again it does the 
opposite.

Thanks
-Vincent

> 
> I've created http://jira.xwiki.org/browse/XE-1580
> 
> Thanks,
> Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Proposal][UX] Change the user type for the Admin user to 'simple'

[Ecaterina Moraru (Valica)]

Hi,

A simple change that could improve the experience for newcomers would be
that the default Admin user to have a simple type.

One of the problems new users have is that they have too many options in
the Edit menu and this can be confusing.

The downside is that it will add an additional step for developers/testers
to change the user type back (or at least until we provide a Developer
user/profile).

Also we would need to make sure the documentation is up to date and fix the
tests.

WDTY?

I've created http://jira.xwiki.org/browse/XE-1580

Thanks,
Caty
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Disable install count on exo for extensions bundled in XE?

[Ecaterina Moraru (Valica)]

I agree to not show the install count for bundled applications since it's
an artificial number.

On a side note: I also think the mentioned apps (Tour, Templates, CKEditor)
since they are bundled, they should not be recommended since they are
bundled. So users (of new versions - which are the ones we support and
optimize for) will have them preinstalled.

So we will have some special rules for bundled extensions. Since by
definition, being bundled, means they are used and recommended.

Thanks,
Caty

On Thu, Oct 6, 2016 at 1:01 PM, Thomas Mortagne 
wrote:

> On Thu, Oct 6, 2016 at 12:01 PM, Thomas Mortagne
>  wrote:
> > On Thu, Oct 6, 2016 at 12:00 PM, Thomas Mortagne
> >  wrote:
> >> On Thu, Oct 6, 2016 at 11:02 AM, Eduard Moraru 
> wrote:
> >>> Hi,
> >>>
> >>> First of all, I`m not sure what "show active installs" checkbox you`re
> >>> mentioning, since I looked and found no such option anywhere on e.x.o.
> nor
> >>> on EM.
> >>
> >> It's not in the UI. Look at object editor.
> >>
> >>>
> >>> Re e.x.o, why not simply adding a boolean "Bundled" column in the
> livetable
> >>> which could be a standard Yes/No/All select  (and maybe which would
> even
> >>> filter to No by default)?
> >>>
> >>> I would find this clearer and more flexible than to no longer display
> the
> >>> install count for some extensions. I would prefer to keep recording it
> >>> because, at some point, bundled extensions can be un-bundled or
> viceversa,
> >>> so the numbers would be relevant.
> >
> > This option have nothing to do with the recode. That's active install
> > job and you can't really disable this.
>
> s/recode/recording/
>
> >
> >>>
> >>> On the same topic: AFAIU, we currently display the *total* install
> count,
> >>> but what about displaying a *relative*/*recent* install count, i.e.
> for the
> >>> last 1 (or 3 or 6) month(s)? This would allow people to sort by
> "popular"
> >>> extensions instead of always seeing "dinosaur" extensions (like the
> ones
> >>> you are trying to hide will eventually become), from a time when they
> were
> >>> popular but which are no longer relevant. Of course, we could take this
> >>> further and display on the extension's page an install graph, similar
> what
> >>> the Jenkins plugins repository does with its "Usage" graphs (ex [1]).
> >>>
> >>> Thanks,
> >>> Eduard
> >>>
> >>> --
> >>> [1] https://wiki.jenkins-ci.org/display/JENKINS/Groovy+
> Postbuild+Plugin
> >>>
> >>> On Thu, Oct 6, 2016 at 10:48 AM, Vincent Massol 
> wrote:
> >>>
>  Hi devs,
> 
>  Question: do we agree to disable "show active installs" for extensions
>  bundled in XE on e.x.o? (if I remember correctly that's why thomas
>  introduced this checkbox but I want to make sure we have the same
> opinion)
> 
>  The idea is not to drown the install figures with bundled extensions
> which
>  are not chosen by users (they get them by default).
> 
>  Right now we still have a few extensions that are bundled and have
> their
>  install count displayed. I can fix it but I want to make sure first.
> 
>  Also we need to decide what to do with contrib extensions bundled in
> XE.
>  For example:
>  - Tour app
>  - CKEditor
>  - Templates app
> 
>  I think we should also disable their active install count, following
> the
>  same rule, even though they can also be installed by themselves in
> older
>  versions of XE.
> 
>  WDYT?
> 
>  To see it:
>  http://extensions.xwiki.org/xwiki/bin/view/Extension/#|t=
>  extensions=1=30=installedCount=desc
> 
>  Thanks
>  -Vincent
> 
>  ___
>  devs mailing list
>  devs@xwiki.org
>  http://lists.xwiki.org/mailman/listinfo/devs
> 
> >>> ___
> >>> devs mailing list
> >>> devs@xwiki.org
> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> >>
> >>
> >> --
> >> Thomas Mortagne
> >
> >
> >
> > --
> > Thomas Mortagne
>
>
>
> --
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Disable install count on exo for extensions bundled in XE?

[Thomas Mortagne]

On Thu, Oct 6, 2016 at 12:01 PM, Thomas Mortagne
 wrote:
> On Thu, Oct 6, 2016 at 12:00 PM, Thomas Mortagne
>  wrote:
>> On Thu, Oct 6, 2016 at 11:02 AM, Eduard Moraru  wrote:
>>> Hi,
>>>
>>> First of all, I`m not sure what "show active installs" checkbox you`re
>>> mentioning, since I looked and found no such option anywhere on e.x.o. nor
>>> on EM.
>>
>> It's not in the UI. Look at object editor.
>>
>>>
>>> Re e.x.o, why not simply adding a boolean "Bundled" column in the livetable
>>> which could be a standard Yes/No/All select  (and maybe which would even
>>> filter to No by default)?
>>>
>>> I would find this clearer and more flexible than to no longer display the
>>> install count for some extensions. I would prefer to keep recording it
>>> because, at some point, bundled extensions can be un-bundled or viceversa,
>>> so the numbers would be relevant.
>
> This option have nothing to do with the recode. That's active install
> job and you can't really disable this.

s/recode/recording/

>
>>>
>>> On the same topic: AFAIU, we currently display the *total* install count,
>>> but what about displaying a *relative*/*recent* install count, i.e. for the
>>> last 1 (or 3 or 6) month(s)? This would allow people to sort by "popular"
>>> extensions instead of always seeing "dinosaur" extensions (like the ones
>>> you are trying to hide will eventually become), from a time when they were
>>> popular but which are no longer relevant. Of course, we could take this
>>> further and display on the extension's page an install graph, similar what
>>> the Jenkins plugins repository does with its "Usage" graphs (ex [1]).
>>>
>>> Thanks,
>>> Eduard
>>>
>>> --
>>> [1] https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin
>>>
>>> On Thu, Oct 6, 2016 at 10:48 AM, Vincent Massol  wrote:
>>>
 Hi devs,

 Question: do we agree to disable "show active installs" for extensions
 bundled in XE on e.x.o? (if I remember correctly that's why thomas
 introduced this checkbox but I want to make sure we have the same opinion)

 The idea is not to drown the install figures with bundled extensions which
 are not chosen by users (they get them by default).

 Right now we still have a few extensions that are bundled and have their
 install count displayed. I can fix it but I want to make sure first.

 Also we need to decide what to do with contrib extensions bundled in XE.
 For example:
 - Tour app
 - CKEditor
 - Templates app

 I think we should also disable their active install count, following the
 same rule, even though they can also be installed by themselves in older
 versions of XE.

 WDYT?

 To see it:
 http://extensions.xwiki.org/xwiki/bin/view/Extension/#|t=
 extensions=1=30=installedCount=desc

 Thanks
 -Vincent

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

>>> ___
>>> devs mailing list
>>> devs@xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Thomas Mortagne
>
>
>
> --
> Thomas Mortagne



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Disable install count on exo for extensions bundled in XE?

[Thomas Mortagne]

On Thu, Oct 6, 2016 at 12:00 PM, Thomas Mortagne
 wrote:
> On Thu, Oct 6, 2016 at 11:02 AM, Eduard Moraru  wrote:
>> Hi,
>>
>> First of all, I`m not sure what "show active installs" checkbox you`re
>> mentioning, since I looked and found no such option anywhere on e.x.o. nor
>> on EM.
>
> It's not in the UI. Look at object editor.
>
>>
>> Re e.x.o, why not simply adding a boolean "Bundled" column in the livetable
>> which could be a standard Yes/No/All select  (and maybe which would even
>> filter to No by default)?
>>
>> I would find this clearer and more flexible than to no longer display the
>> install count for some extensions. I would prefer to keep recording it
>> because, at some point, bundled extensions can be un-bundled or viceversa,
>> so the numbers would be relevant.

This option have nothing to do with the recode. That's active install
job and you can't really disable this.

>>
>> On the same topic: AFAIU, we currently display the *total* install count,
>> but what about displaying a *relative*/*recent* install count, i.e. for the
>> last 1 (or 3 or 6) month(s)? This would allow people to sort by "popular"
>> extensions instead of always seeing "dinosaur" extensions (like the ones
>> you are trying to hide will eventually become), from a time when they were
>> popular but which are no longer relevant. Of course, we could take this
>> further and display on the extension's page an install graph, similar what
>> the Jenkins plugins repository does with its "Usage" graphs (ex [1]).
>>
>> Thanks,
>> Eduard
>>
>> --
>> [1] https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin
>>
>> On Thu, Oct 6, 2016 at 10:48 AM, Vincent Massol  wrote:
>>
>>> Hi devs,
>>>
>>> Question: do we agree to disable "show active installs" for extensions
>>> bundled in XE on e.x.o? (if I remember correctly that's why thomas
>>> introduced this checkbox but I want to make sure we have the same opinion)
>>>
>>> The idea is not to drown the install figures with bundled extensions which
>>> are not chosen by users (they get them by default).
>>>
>>> Right now we still have a few extensions that are bundled and have their
>>> install count displayed. I can fix it but I want to make sure first.
>>>
>>> Also we need to decide what to do with contrib extensions bundled in XE.
>>> For example:
>>> - Tour app
>>> - CKEditor
>>> - Templates app
>>>
>>> I think we should also disable their active install count, following the
>>> same rule, even though they can also be installed by themselves in older
>>> versions of XE.
>>>
>>> WDYT?
>>>
>>> To see it:
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/#|t=
>>> extensions=1=30=installedCount=desc
>>>
>>> Thanks
>>> -Vincent
>>>
>>> ___
>>> devs mailing list
>>> devs@xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Disable install count on exo for extensions bundled in XE?

[Eduard Moraru]

Hi,

First of all, I`m not sure what "show active installs" checkbox you`re
mentioning, since I looked and found no such option anywhere on e.x.o. nor
on EM.

Re e.x.o, why not simply adding a boolean "Bundled" column in the livetable
which could be a standard Yes/No/All select  (and maybe which would even
filter to No by default)?

I would find this clearer and more flexible than to no longer display the
install count for some extensions. I would prefer to keep recording it
because, at some point, bundled extensions can be un-bundled or viceversa,
so the numbers would be relevant.

On the same topic: AFAIU, we currently display the *total* install count,
but what about displaying a *relative*/*recent* install count, i.e. for the
last 1 (or 3 or 6) month(s)? This would allow people to sort by "popular"
extensions instead of always seeing "dinosaur" extensions (like the ones
you are trying to hide will eventually become), from a time when they were
popular but which are no longer relevant. Of course, we could take this
further and display on the extension's page an install graph, similar what
the Jenkins plugins repository does with its "Usage" graphs (ex [1]).

Thanks,
Eduard

--
[1] https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin

On Thu, Oct 6, 2016 at 10:48 AM, Vincent Massol  wrote:

> Hi devs,
>
> Question: do we agree to disable "show active installs" for extensions
> bundled in XE on e.x.o? (if I remember correctly that's why thomas
> introduced this checkbox but I want to make sure we have the same opinion)
>
> The idea is not to drown the install figures with bundled extensions which
> are not chosen by users (they get them by default).
>
> Right now we still have a few extensions that are bundled and have their
> install count displayed. I can fix it but I want to make sure first.
>
> Also we need to decide what to do with contrib extensions bundled in XE.
> For example:
> - Tour app
> - CKEditor
> - Templates app
>
> I think we should also disable their active install count, following the
> same rule, even though they can also be installed by themselves in older
> versions of XE.
>
> WDYT?
>
> To see it:
> http://extensions.xwiki.org/xwiki/bin/view/Extension/#|t=
> extensions=1=30=installedCount=desc
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Brainstorming] Disable install count on exo for extensions bundled in XE?

[Vincent Massol]

Hi devs,

Question: do we agree to disable "show active installs" for extensions bundled 
in XE on e.x.o? (if I remember correctly that's why thomas introduced this 
checkbox but I want to make sure we have the same opinion)

The idea is not to drown the install figures with bundled extensions which are 
not chosen by users (they get them by default).

Right now we still have a few extensions that are bundled and have their 
install count displayed. I can fix it but I want to make sure first.

Also we need to decide what to do with contrib extensions bundled in XE. For 
example:
- Tour app
- CKEditor 
- Templates app

I think we should also disable their active install count, following the same 
rule, even though they can also be installed by themselves in older versions of 
XE.

WDYT?

To see it:
http://extensions.xwiki.org/xwiki/bin/view/Extension/#|t=extensions=1=30=installedCount=desc

Thanks
-Vincent

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