Re: [xwiki-devs] [Brainstorming] What XAR file type for Mail Template pages?

[Vincent Massol]

> On 7 May 2018, at 18:18, Thomas Mortagne  wrote:
> 
> On Mon, May 7, 2018 at 5:02 PM, Vincent Massol  wrote:
>> 
>> 
>>> On 7 May 2018, at 16:48, Thomas Mortagne  wrote:
>>> 
>>> On Mon, May 7, 2018 at 4:33 PM, Vincent Massol  wrote:
 Hi,
 
 It seems we forgot to handle mail template pages. For example 
 XWiki.ResetPasswordMailContent
 
 We need to decide the type: demo, default, etc.
 
 WDYT about demo (i.e. as soon as the user starts modifying it, we don’t 
 upgrade it anymore)?
 
 Thanks
 -Vincent
 
>>> 
>>> All types with allowed edit prevent upgrade.
>> 
>> I’m not sure we need more than 1 such type. See other mail thread.
>> 
>>> I think a more important question is: is it OK to delete it ?
>> 
>> We could. See below
>> 
>>> 
>>> Seems to me delete is not OK in this context. Unless it's possible to
>>> change the mail template used for password reset ?
>> 
>> Re delete, I think there’s another thread discussing it, no? I don’t 
>> remember the discussion too well and don’t master all the details but AFAIR 
>> my preference was to not prevent deletion in general (I’m worried about 
>> unplanned use cases requiring a delete, like renaming the page to another 
>> place to save it, and then import some XAR containing the new mail template).
>> 
>> IMO all pages should be deletable without endangering the system. In this 
>> case we could imagine:
>> * if the template is missing then the password reset page would mention it 
>> with the ability to create a default mail template
>> * and/or report a mail error in the admin UI when sending the email (since 
>> the template doesn’t exist). This means that the template factory for emails 
>> should check the existence of the page. This should be handled here: 
>> https://github.com/xwiki/xwiki-platform/blob/6e281a093d3751666fdcd3fb3a69cb638cca9b59/xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-send/xwiki-platform-mail-send-default/src/main/java/org/xwiki/mail/internal/factory/template/DefaultMailTemplateManager.java#L143
>>  AFAICS it will currently report a NPE….
> 
> As you said, deleting that page would break reset password feature and
> since I don't plan to rewrite it right now it means delete should be
> protected IMO. If someone improve this feature later then the type can
> be changed to "demo".
> 
>> 
>> Have we decided what we do about deletes in general?
> 
> There hasn't been such discussion.

I’m referring to http://markmail.org/message/kjtyzvjp5zzh4gyf (and I’m sure I 
saw another discussion about that but cannot find it ATM).

I still don’t understand why we’re mixing upgradability with deletability (and 
trying to find names that represent both). Aren’t they 2 different topics?

Thanks
-Vincent

> I don't even understand what this
> mean, it's obvious to me that deleting some pages don't break anything
> while for others you are going to create a huge mess.
> 
>> 
>> Thanks
>> -Vincent
>> 
>>> --
>>> Thomas Mortagne
>> 
> 
> 
> 
> -- 
> Thomas Mortagne

Re: [xwiki-devs] [Brainstorming] What XAR file type for Mail Template pages?

[Thomas Mortagne]

On Mon, May 7, 2018 at 5:02 PM, Vincent Massol  wrote:
>
>
>> On 7 May 2018, at 16:48, Thomas Mortagne  wrote:
>>
>> On Mon, May 7, 2018 at 4:33 PM, Vincent Massol  wrote:
>>> Hi,
>>>
>>> It seems we forgot to handle mail template pages. For example 
>>> XWiki.ResetPasswordMailContent
>>>
>>> We need to decide the type: demo, default, etc.
>>>
>>> WDYT about demo (i.e. as soon as the user starts modifying it, we don’t 
>>> upgrade it anymore)?
>>>
>>> Thanks
>>> -Vincent
>>>
>>
>> All types with allowed edit prevent upgrade.
>
> I’m not sure we need more than 1 such type. See other mail thread.
>
>> I think a more important question is: is it OK to delete it ?
>
> We could. See below
>
>>
>> Seems to me delete is not OK in this context. Unless it's possible to
>> change the mail template used for password reset ?
>
> Re delete, I think there’s another thread discussing it, no? I don’t remember 
> the discussion too well and don’t master all the details but AFAIR my 
> preference was to not prevent deletion in general (I’m worried about 
> unplanned use cases requiring a delete, like renaming the page to another 
> place to save it, and then import some XAR containing the new mail template).
>
> IMO all pages should be deletable without endangering the system. In this 
> case we could imagine:
> * if the template is missing then the password reset page would mention it 
> with the ability to create a default mail template
> * and/or report a mail error in the admin UI when sending the email (since 
> the template doesn’t exist). This means that the template factory for emails 
> should check the existence of the page. This should be handled here: 
> https://github.com/xwiki/xwiki-platform/blob/6e281a093d3751666fdcd3fb3a69cb638cca9b59/xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-send/xwiki-platform-mail-send-default/src/main/java/org/xwiki/mail/internal/factory/template/DefaultMailTemplateManager.java#L143
>  AFAICS it will currently report a NPE….

As you said, deleting that page would break reset password feature and
since I don't plan to rewrite it right now it means delete should be
protected IMO. If someone improve this feature later then the type can
be changed to "demo".

>
> Have we decided what we do about deletes in general?

There hasn't been such discussion. I don't even understand what this
mean, it's obvious to me that deleting some pages don't break anything
while for others you are going to create a huge mess.

>
> Thanks
> -Vincent
>
>> --
>> Thomas Mortagne
>



-- 
Thomas Mortagne

Re: [xwiki-devs] Repository request for "application-relations"

[Vincent Massol]

And here’s the JIRA:
* https://jira.xwiki.org/projects/PAGEREL/summary

Thanks
-Vincent

> On 7 May 2018, at 16:49, Vincent Massol  wrote:
> 
> done: https://github.com/xwiki-contrib/application-page-relations
> -Vincent
> 
>> On 7 May 2018, at 16:44, Stéphane Laurière  
>> wrote:
>> 
>> Hi Alex,
>> 
>> Sure, "application-page-relations" sounds good to me. Vincent, can I ask you 
>> to rename the repository accordingly?
>> 
>> Thanks a lot,
>> 
>> Stéphane
>> 
>> Alex Cotiugă:
>>> Hi Stéphane,
>>> Is it possible to have the repository name a little bit more specific as in
>>> "application-pagerelations" or "application-linkrelations", for example? I
>>> feel that there can be many more relations that could be modeled in an
>>> application. WDYT?
>>> Thanks,
>>> Alex
>>> On Mon, May 7, 2018 at 5:31 PM, Stéphane Laurière <
>>> stephane.lauri...@xwiki.com> wrote:
 Hi all,
 
 I'd like to request a repository for a new application allowing to create
 relations between pages and to show direct / inverse relations. It's
 similar to the use of links / backlinks except that in the case of this
 application, the links to other pages can be added as objects rather than
 in the content itself. Also, in the future, we may consider the option to
 name each relation, so as to have something similar to what RDF proposes.
 
 Here's the name of the repository I would like to request, if you agree:
 "application-relations". I saw there was an issue with the JIRA contrib
 project template plugin, there's no need for a JIRA project right now.
 
 Thanks a lot,
 
 Stéphane
 
 
>> 
>> 
>> -- 
>> Stéphane Laurière
>> XWiki www.xwiki.com
>> @slauriere
>> 
> 

Re: [xwiki-devs] Repository for AppWithinMinutes Charts

[Vincent Massol]

Done for JIRA:
* https://jira.xwiki.org/projects/AWMCHARTS/summary

Thanks
-Vincent

> On 7 May 2018, at 16:01, Vincent Massol  wrote:
> 
> Hi Ludo,
> 
>> On 7 May 2018, at 15:44, Ludovic Dubost  wrote:
>> 
>> Hi,
>> 
>> I would like to publish an extension to add charts and statistics to
>> AppWithinMinutes.
>> Could I have the repo
>> 
>> appwithinminutes-charts
> 
> * Github: https://github.com/xwiki-contrib/appwithinminutes-charts
> * JIRA: Since we upgraed to JIRA 7.9 our contrib project template plugin 
> isn’t working anymore so I haven’t created a jira project yet. I’ll check if 
> I can make it work again first. Let me know if you need a JIRA project right 
> now.
> 
> Thanks
> -Vincent
> 
>> 
>> Thanks
>> Ludovic
>> 
>> 
>> --
>> *Ludovic Dubost*
>> *Founder and CEO*
>> ludo...@xwiki.com
>> skype: ldubost
>> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>>   - Try Cryptpad: Secure
>> realtime Wysiwyg Editing 
> 

Re: [xwiki-devs] [NEW API] XAR entry type

[Thomas Mortagne]

Just started a wiki page to list pages with specific type (decided or
still discussed)
http://design.xwiki.org/xwiki/bin/view/Proposal/XARentriestypes

On Mon, May 7, 2018 at 4:29 PM, Thomas Mortagne
 wrote:
> Since I hit more and more the need to allow to customize an entry
> point without deleting it (or it will break a hardcoded menu/link) I
> just introduce the following type:
>
> * "customizable": same thing as "home" and for the same reasons but
> more generic. I guess we could simply get rid of "home" type since the
> main use case seems to tend to "demo" (see dedicated mails thread)
>
> I tough about "editable" but I find it too wide.
>
> On Mon, Apr 30, 2018 at 11:14 AM, Thomas Mortagne
>  wrote:
>> On Mon, Apr 30, 2018 at 10:00 AM, Vincent Massol  wrote:
>>> Hi Thomas,
>>>
 On 23 Apr 2018, at 12:27, Thomas Mortagne  
 wrote:

 Hi devs,

 When dealing with extension pages protection we ended up with a very
 visible issue: EVERYONE customize the home page so it does not make
 much sense to warn every user trying to edit it that it's dangerous
 and might break the extensions.

 Since it's not the only use case 10.3 introduce the concept of XAR
 entry type which allow controlling a bit more edit/delete and upgrade
 behavior. See 
 http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+Module+Specifications#Hpackage.xml
 for more details.

 On component side it's possible to decide the default type of a page
 reference (that's where "Main.WebHome" type come from currently). It's
 also possible to override the upgrade behavior for a specific type or
 even a specific reference for more exotic use cases.

 So it's now possible to control the type you want for a page at XAR
 descriptor level. I already typed a few page, for example
 "Main.WebHome" is now of type "home" which means "it's OK to edit it
 and you should only upgrade it if no customization have been made".

 Cool home page is covered but we now entered a new era of endless
 debates to decide of what type some page should be and what other
 types to introduce :)
>>>
>>> Could you list all pages for which you’ve put “demo”, “home” and 
>>> “configuration" types so far?
>>
>> The current status is (hope I don't forget anything):
>>
>> * demo 
>> (https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ctype%3Edemo%3C%2Ftype%3E%22&type=)
>> ** Sandbox visible sub pages
>> ** Color themes
>> ** XWiki.DefaultSkin
>> ** soon Main.WebHome it seems :)
>> ** [jetty+hsqldb+flavor] Admin user
>>
>> * configuration
>> (https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ctype%3Econfiguration%3C%2Ftype%3E%22&type=)
>> ** XWiki.XWikiPreferences (default type provided by a component)
>> ** [jetty+hsqldb+flavor] XWikiAdminGroup and XWikiAllGroup
>>
>> * home 
>> (https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ctype%3Ehome%3C%2Ftype%3E%22&type=)
>> ** Sandbox.WebHome since it's the hardcoded entry point of the sandbox
>> application so not too nice to delete it
>>
>> * to discuss AFAIK:
>> ** Dashboard.WebHome home page, either "demo" or something a bit more
>> restrictive like "home" since it's the entry point of dashboard
>> application so not very nice to delete it
>> ** and of course Contrib extensions will need to take care of that too
>>
>>>
>>> Also in the doc you say "   • default: used to force the default. Edit 
>>> and delete are not allowed and a 3-way merge is applied to the document 
>>> during upgrades.”
>>>
>>> AFAIU this is the default when no type is specified, right? Did you mean to 
>>> say “Edit and delete are allowed”?
>>
>> It's not about making that page behave as a non-extension page, it's
>> only here to force the default extension page behavior.
>>
>> It's possible trough components to indicate a type for a given local
>> reference when no explicit type a been set. So this value allow to
>> bypass this when you want to make extra sure your page will have the
>> default behavior (for example some flavor in which you are not
>> supposed to touch the Main.WebHome since Main.WebHome is current
>> getting its type as "the default type for Main.WebHome reference in
>> general").
>>
>>>
>>> Thanks
>>> -Vincent
>>>

 We are not going to discuss all these in this mail so everyone with a
 doubt should start a discussion for a standard page (or a set of
 standard page which are obviously very similar like color themes).

 Currently, protected page produce a warning that you can force. The
 plan in 10.4 is to keep the warning only for advanced completely
 prevent basic user to modify protected pages by default and also allow
 configuring all that (indicate in your profile that you don't want to
 be bothered with that, override edit/delete right even for advanced
 users, etc.). But before that we need to make sure basic users are
>>>

Re: [xwiki-devs] [Brainstorming] What XAR file type for Mail Template pages?

[Ecaterina Moraru (Valica)]

On Mon, May 7, 2018 at 5:48 PM, Thomas Mortagne 
wrote:

> On Mon, May 7, 2018 at 4:33 PM, Vincent Massol  wrote:
> > Hi,
> >
> > It seems we forgot to handle mail template pages. For example
> XWiki.ResetPasswordMailContent
> >
> > We need to decide the type: demo, default, etc.
> >
> > WDYT about demo (i.e. as soon as the user starts modifying it, we don’t
> upgrade it anymore)?
> >
> > Thanks
> > -Vincent
> >
>
> All types with allowed edit prevent upgrade.
>
> I think a more important question is: is it OK to delete it ?
>
> Seems to me delete is not OK in this context. Unless it's possible to
> change the mail template used for password reset ?
>

If someone delete it, can't we auto-generate it blank from code?

I also see the templates (validation, confirmation, invitation, etc.) as
demo. They should be modified by the user. We just need to make sure they
don't contain too much code / velocity variables definitions that could
benefit from an upgrade.


>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [Brainstorming] What XAR file type for Mail Template pages?

[Vincent Massol]

> On 7 May 2018, at 16:48, Thomas Mortagne  wrote:
> 
> On Mon, May 7, 2018 at 4:33 PM, Vincent Massol  wrote:
>> Hi,
>> 
>> It seems we forgot to handle mail template pages. For example 
>> XWiki.ResetPasswordMailContent
>> 
>> We need to decide the type: demo, default, etc.
>> 
>> WDYT about demo (i.e. as soon as the user starts modifying it, we don’t 
>> upgrade it anymore)?
>> 
>> Thanks
>> -Vincent
>> 
> 
> All types with allowed edit prevent upgrade.

I’m not sure we need more than 1 such type. See other mail thread.

> I think a more important question is: is it OK to delete it ?

We could. See below

> 
> Seems to me delete is not OK in this context. Unless it's possible to
> change the mail template used for password reset ?

Re delete, I think there’s another thread discussing it, no? I don’t remember 
the discussion too well and don’t master all the details but AFAIR my 
preference was to not prevent deletion in general (I’m worried about unplanned 
use cases requiring a delete, like renaming the page to another place to save 
it, and then import some XAR containing the new mail template).

IMO all pages should be deletable without endangering the system. In this case 
we could imagine:
* if the template is missing then the password reset page would mention it with 
the ability to create a default mail template
* and/or report a mail error in the admin UI when sending the email (since the 
template doesn’t exist). This means that the template factory for emails should 
check the existence of the page. This should be handled here: 
https://github.com/xwiki/xwiki-platform/blob/6e281a093d3751666fdcd3fb3a69cb638cca9b59/xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-send/xwiki-platform-mail-send-default/src/main/java/org/xwiki/mail/internal/factory/template/DefaultMailTemplateManager.java#L143
 AFAICS it will currently report a NPE….

Have we decided what we do about deletes in general?

Thanks
-Vincent

> -- 
> Thomas Mortagne

Re: [xwiki-devs] Repository request for "application-relations"

[Vincent Massol]

done: https://github.com/xwiki-contrib/application-page-relations
-Vincent

> On 7 May 2018, at 16:44, Stéphane Laurière  
> wrote:
> 
> Hi Alex,
> 
> Sure, "application-page-relations" sounds good to me. Vincent, can I ask you 
> to rename the repository accordingly?
> 
> Thanks a lot,
> 
> Stéphane
> 
> Alex Cotiugă:
>> Hi Stéphane,
>> Is it possible to have the repository name a little bit more specific as in
>> "application-pagerelations" or "application-linkrelations", for example? I
>> feel that there can be many more relations that could be modeled in an
>> application. WDYT?
>> Thanks,
>> Alex
>> On Mon, May 7, 2018 at 5:31 PM, Stéphane Laurière <
>> stephane.lauri...@xwiki.com> wrote:
>>> Hi all,
>>> 
>>> I'd like to request a repository for a new application allowing to create
>>> relations between pages and to show direct / inverse relations. It's
>>> similar to the use of links / backlinks except that in the case of this
>>> application, the links to other pages can be added as objects rather than
>>> in the content itself. Also, in the future, we may consider the option to
>>> name each relation, so as to have something similar to what RDF proposes.
>>> 
>>> Here's the name of the repository I would like to request, if you agree:
>>> "application-relations". I saw there was an issue with the JIRA contrib
>>> project template plugin, there's no need for a JIRA project right now.
>>> 
>>> Thanks a lot,
>>> 
>>> Stéphane
>>> 
>>> 
> 
> 
> -- 
> Stéphane Laurière
> XWiki www.xwiki.com
> @slauriere
> 

Re: [xwiki-devs] [Brainstorming] What XAR file type for Mail Template pages?

[Thomas Mortagne]

On Mon, May 7, 2018 at 4:33 PM, Vincent Massol  wrote:
> Hi,
>
> It seems we forgot to handle mail template pages. For example 
> XWiki.ResetPasswordMailContent
>
> We need to decide the type: demo, default, etc.
>
> WDYT about demo (i.e. as soon as the user starts modifying it, we don’t 
> upgrade it anymore)?
>
> Thanks
> -Vincent
>

All types with allowed edit prevent upgrade.

I think a more important question is: is it OK to delete it ?

Seems to me delete is not OK in this context. Unless it's possible to
change the mail template used for password reset ?

-- 
Thomas Mortagne

Re: [xwiki-devs] Repository request for "application-relations"

[Stéphane Laurière]

Hi Alex,

Sure, "application-page-relations" sounds good to me. Vincent, can I ask you to 
rename the repository accordingly?

Thanks a lot,

Stéphane

Alex Cotiugă:

Hi Stéphane,

Is it possible to have the repository name a little bit more specific as in
"application-pagerelations" or "application-linkrelations", for example? I
feel that there can be many more relations that could be modeled in an
application. WDYT?

Thanks,
Alex



On Mon, May 7, 2018 at 5:31 PM, Stéphane Laurière <
stephane.lauri...@xwiki.com> wrote:


Hi all,

I'd like to request a repository for a new application allowing to create
relations between pages and to show direct / inverse relations. It's
similar to the use of links / backlinks except that in the case of this
application, the links to other pages can be added as objects rather than
in the content itself. Also, in the future, we may consider the option to
name each relation, so as to have something similar to what RDF proposes.

Here's the name of the repository I would like to request, if you agree:
"application-relations". I saw there was an issue with the JIRA contrib
project template plugin, there's no need for a JIRA project right now.

Thanks a lot,

Stéphane





--
Stéphane Laurière
XWiki www.xwiki.com
@slauriere

Re: [xwiki-devs] Repository request for "application-relations"

[Vincent Massol]

Hi Stephane,

> On 7 May 2018, at 16:31, Stéphane Laurière  
> wrote:
> 
> Hi all,
> 
> I'd like to request a repository for a new application allowing to create 
> relations between pages and to show direct / inverse relations. It's similar 
> to the use of links / backlinks except that in the case of this application, 
> the links to other pages can be added as objects rather than in the content 
> itself. Also, in the future, we may consider the option to name each 
> relation, so as to have something similar to what RDF proposes.
> 
> Here's the name of the repository I would like to request, if you agree: 
> "application-relations". I saw there was an issue with the JIRA contrib 
> project template plugin, there's no need for a JIRA project right now.

Done: https://github.com/xwiki-contrib/application-relations

Thanks
-Vincent

> 
> Thanks a lot,
> 
> Stéphane
> 
> 
> -- 
> Stéphane Laurière
> XWiki www.xwiki.com
> +33 645 816 202 @slauriere
> 
> 

Re: [xwiki-devs] Repository request for "application-relations"

[Alex Cotiugă]

Hi Stéphane,

Is it possible to have the repository name a little bit more specific as in
"application-pagerelations" or "application-linkrelations", for example? I
feel that there can be many more relations that could be modeled in an
application. WDYT?

Thanks,
Alex



On Mon, May 7, 2018 at 5:31 PM, Stéphane Laurière <
stephane.lauri...@xwiki.com> wrote:

> Hi all,
>
> I'd like to request a repository for a new application allowing to create
> relations between pages and to show direct / inverse relations. It's
> similar to the use of links / backlinks except that in the case of this
> application, the links to other pages can be added as objects rather than
> in the content itself. Also, in the future, we may consider the option to
> name each relation, so as to have something similar to what RDF proposes.
>
> Here's the name of the repository I would like to request, if you agree:
> "application-relations". I saw there was an issue with the JIRA contrib
> project template plugin, there's no need for a JIRA project right now.
>
> Thanks a lot,
>
> Stéphane
>
>
> --
> Stéphane Laurière
> XWiki www.xwiki.com
> +33 645 816 202 @slauriere
>
>
>

[xwiki-devs] [Brainstorming] What XAR file type for Mail Template pages?

[Vincent Massol]

Hi,

It seems we forgot to handle mail template pages. For example 
XWiki.ResetPasswordMailContent

We need to decide the type: demo, default, etc.

WDYT about demo (i.e. as soon as the user starts modifying it, we don’t upgrade 
it anymore)?

Thanks
-Vincent

[xwiki-devs] Repository request for "application-relations"

[Stéphane Laurière]

Hi all,

I'd like to request a repository for a new application allowing to create 
relations between pages and to show direct / inverse relations. It's similar to 
the use of links / backlinks except that in the case of this application, the 
links to other pages can be added as objects rather than in the content itself. 
Also, in the future, we may consider the option to name each relation, so as to 
have something similar to what RDF proposes.

Here's the name of the repository I would like to request, if you agree: 
"application-relations". I saw there was an issue with the JIRA contrib project 
template plugin, there's no need for a JIRA project right now.

Thanks a lot,

Stéphane


--
Stéphane Laurière
XWiki www.xwiki.com
+33 645 816 202 @slauriere

Re: [xwiki-devs] [NEW API] XAR entry type

[Thomas Mortagne]

Since I hit more and more the need to allow to customize an entry
point without deleting it (or it will break a hardcoded menu/link) I
just introduce the following type:

* "customizable": same thing as "home" and for the same reasons but
more generic. I guess we could simply get rid of "home" type since the
main use case seems to tend to "demo" (see dedicated mails thread)

I tough about "editable" but I find it too wide.

On Mon, Apr 30, 2018 at 11:14 AM, Thomas Mortagne
 wrote:
> On Mon, Apr 30, 2018 at 10:00 AM, Vincent Massol  wrote:
>> Hi Thomas,
>>
>>> On 23 Apr 2018, at 12:27, Thomas Mortagne  wrote:
>>>
>>> Hi devs,
>>>
>>> When dealing with extension pages protection we ended up with a very
>>> visible issue: EVERYONE customize the home page so it does not make
>>> much sense to warn every user trying to edit it that it's dangerous
>>> and might break the extensions.
>>>
>>> Since it's not the only use case 10.3 introduce the concept of XAR
>>> entry type which allow controlling a bit more edit/delete and upgrade
>>> behavior. See 
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+Module+Specifications#Hpackage.xml
>>> for more details.
>>>
>>> On component side it's possible to decide the default type of a page
>>> reference (that's where "Main.WebHome" type come from currently). It's
>>> also possible to override the upgrade behavior for a specific type or
>>> even a specific reference for more exotic use cases.
>>>
>>> So it's now possible to control the type you want for a page at XAR
>>> descriptor level. I already typed a few page, for example
>>> "Main.WebHome" is now of type "home" which means "it's OK to edit it
>>> and you should only upgrade it if no customization have been made".
>>>
>>> Cool home page is covered but we now entered a new era of endless
>>> debates to decide of what type some page should be and what other
>>> types to introduce :)
>>
>> Could you list all pages for which you’ve put “demo”, “home” and 
>> “configuration" types so far?
>
> The current status is (hope I don't forget anything):
>
> * demo 
> (https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ctype%3Edemo%3C%2Ftype%3E%22&type=)
> ** Sandbox visible sub pages
> ** Color themes
> ** XWiki.DefaultSkin
> ** soon Main.WebHome it seems :)
> ** [jetty+hsqldb+flavor] Admin user
>
> * configuration
> (https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ctype%3Econfiguration%3C%2Ftype%3E%22&type=)
> ** XWiki.XWikiPreferences (default type provided by a component)
> ** [jetty+hsqldb+flavor] XWikiAdminGroup and XWikiAllGroup
>
> * home 
> (https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ctype%3Ehome%3C%2Ftype%3E%22&type=)
> ** Sandbox.WebHome since it's the hardcoded entry point of the sandbox
> application so not too nice to delete it
>
> * to discuss AFAIK:
> ** Dashboard.WebHome home page, either "demo" or something a bit more
> restrictive like "home" since it's the entry point of dashboard
> application so not very nice to delete it
> ** and of course Contrib extensions will need to take care of that too
>
>>
>> Also in the doc you say "   • default: used to force the default. Edit 
>> and delete are not allowed and a 3-way merge is applied to the document 
>> during upgrades.”
>>
>> AFAIU this is the default when no type is specified, right? Did you mean to 
>> say “Edit and delete are allowed”?
>
> It's not about making that page behave as a non-extension page, it's
> only here to force the default extension page behavior.
>
> It's possible trough components to indicate a type for a given local
> reference when no explicit type a been set. So this value allow to
> bypass this when you want to make extra sure your page will have the
> default behavior (for example some flavor in which you are not
> supposed to touch the Main.WebHome since Main.WebHome is current
> getting its type as "the default type for Main.WebHome reference in
> general").
>
>>
>> Thanks
>> -Vincent
>>
>>>
>>> We are not going to discuss all these in this mail so everyone with a
>>> doubt should start a discussion for a standard page (or a set of
>>> standard page which are obviously very similar like color themes).
>>>
>>> Currently, protected page produce a warning that you can force. The
>>> plan in 10.4 is to keep the warning only for advanced completely
>>> prevent basic user to modify protected pages by default and also allow
>>> configuring all that (indicate in your profile that you don't want to
>>> be bothered with that, override edit/delete right even for advanced
>>> users, etc.). But before that we need to make sure basic users are
>>> allowed to edit all the pages they are supposed to edit.
>>>
>>> Happy tuning :)
>>>
>>> --
>>> Thomas Mortagne
>>
>
>
>
> --
> Thomas Mortagne



-- 
Thomas Mortagne

Re: [xwiki-devs] [Vote] Assignee for PR: Contributor or Committer?

[Vincent Massol]

Hi,

We forgot to document it so I’ve put it at 
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HRule:Assigncontributorwhenthere27saPullRequest

Also note that several use cases were missing so I’ve added some too, please 
verify they’re ok for you:
* no jira account
* substantial rewrite of the PR

Thanks
-Vincent

> On 2 Dec 2014, at 12:52, Ecaterina Moraru (Valica)  wrote:
> 
> Hi,
> 
> Vote 1: Contributor received 5 +1 binding, and 1 +1 non binding votes.
> 
> Thanks for your votes.
> 
> 
> On Wed, Nov 26, 2014 at 7:39 PM, Sergiu Dumitriu  wrote:
> 
>> +1 for 1.
>> 
>> On 11/26/2014 08:21 AM, Ecaterina Moraru (Valica) wrote:
>>> Hi,
>>> 
>>> We have discussed this subject multiple times, but we don't have an
>>> official vote and conclusion on the topic.
>>> 
>>> Problem: In JIRA who is the Assignee of an issue fixed by a Pull Request?
>>> 1: Contributor
>>> - he provided the solution
>>> - giving the attributions, the contributor might feel encouraged to
>>> contribute more
>>> - we could do some JIRA statistics on external contributions, but this
>> use
>>> case can be covered by  GitHub statistics
>>> 
>>> 2: Committer
>>> - he does the merging on his account and he becomes responsible for the
>>> committed code.
>>> - in case there are problems, the committer needs to find solution, since
>>> we can't rely on contributors availability
>>> - in doing the PR review, the committer spends a lot of time analyzing
>> and
>>> testing the provided solution
>>> 
>>> We are talking here about complete solutions provided by the PR, since in
>>> case of partial solutions, the committer can assign himself on the issue
>>> (depends on the quantity of modification he does).
>>> 
>>> Let me know what you think,
>>> Caty
>> 
>> --
>> Sergiu Dumitriu
>> http://purl.org/net/sergiu
>> ___
>> 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] Repository for AppWithinMinutes Charts

[Vincent Massol]

Hi Ludo,

> On 7 May 2018, at 15:44, Ludovic Dubost  wrote:
> 
> Hi,
> 
> I would like to publish an extension to add charts and statistics to
> AppWithinMinutes.
> Could I have the repo
> 
> appwithinminutes-charts

* Github: https://github.com/xwiki-contrib/appwithinminutes-charts
* JIRA: Since we upgraed to JIRA 7.9 our contrib project template plugin isn’t 
working anymore so I haven’t created a jira project yet. I’ll check if I can 
make it work again first. Let me know if you need a JIRA project right now.

Thanks
-Vincent

> 
> Thanks
> Ludovic
> 
> 
> --
> *Ludovic Dubost*
> *Founder and CEO*
> ludo...@xwiki.com
> skype: ldubost
> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>   - Try Cryptpad: Secure
> realtime Wysiwyg Editing 

[xwiki-devs] Repository for AppWithinMinutes Charts

[Ludovic Dubost]

Hi,

I would like to publish an extension to add charts and statistics to
AppWithinMinutes.
Could I have the repo

appwithinminutes-charts

Thanks
Ludovic


--
*Ludovic Dubost*
*Founder and CEO*
ludo...@xwiki.com
skype: ldubost
Blog: http://blog.ludovic.orgTry XWiki on the cloud
  - Try Cryptpad: Secure
realtime Wysiwyg Editing 

Re: [xwiki-devs] Release new version of the Publication Workflow Application ?

[Ecaterina Moraru (Valica)]

+1

On Mon, May 7, 2018 at 11:03 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1
>
> On Sun, May 6, 2018 at 12:27 AM, Clemens Robbenhaar <
> robbenh...@green-meadows.de> wrote:
>
> > Hi devs,
> > Hi Anca Luca especially :)
> >
> > I have been working on some issues with the Publication Workflow
> > Application lately (on a branch called XAWORKFLOW-37 ... which ended up
> > containing several other fixes, too.)
> >
> > I'd like to merge these fixes into the master and make a new release 1.9
> > soon, preferably near the end of the next week.
> >
> > The list of fixes so far are in this list:
> >
> > https://jira.xwiki.org/browse/XAWORKFLOW-20?jql=project%20%3
> > D%20XAWORKFLOW%20AND%20fixVersion%20%3D%201.8%
> 20ORDER%20BY%20created%20ASC
> >
> > Also this will raise the required XWiki version to 7.2, mainly as I did
> > not want to test if it still works with a pre-"nested pages" XWiki :-/
> >
> > Any objections? Or anyone sees the need and want to do a code review?
> >
> > I am still in the process of testing if everything works with the latest
> > XWiki version (I had developed it against an old 8.0-instance that I had
> > lying around). I know a few folks who will test the release and I am
> > prepared to shoot out a 1.8.1 in case I seriously goofed up something. ;)
> >
> > Thanks,
> > Clemens
> >
>

Re: [xwiki-devs] Release new version of the Publication Workflow Application ?

[Marius Dumitru Florea]

+1

On Sun, May 6, 2018 at 12:27 AM, Clemens Robbenhaar <
robbenh...@green-meadows.de> wrote:

> Hi devs,
> Hi Anca Luca especially :)
>
> I have been working on some issues with the Publication Workflow
> Application lately (on a branch called XAWORKFLOW-37 ... which ended up
> containing several other fixes, too.)
>
> I'd like to merge these fixes into the master and make a new release 1.9
> soon, preferably near the end of the next week.
>
> The list of fixes so far are in this list:
>
> https://jira.xwiki.org/browse/XAWORKFLOW-20?jql=project%20%3
> D%20XAWORKFLOW%20AND%20fixVersion%20%3D%201.8%20ORDER%20BY%20created%20ASC
>
> Also this will raise the required XWiki version to 7.2, mainly as I did
> not want to test if it still works with a pre-"nested pages" XWiki :-/
>
> Any objections? Or anyone sees the need and want to do a code review?
>
> I am still in the process of testing if everything works with the latest
> XWiki version (I had developed it against an old 8.0-instance that I had
> lying around). I know a few folks who will test the release and I am
> prepared to shoot out a 1.8.1 in case I seriously goofed up something. ;)
>
> Thanks,
> Clemens
>