Re: [xwiki-devs] [VOTE] Drop support for IE11
Tweet from Bootstrap on 3 Jan: "As we start thinking about v5, what should we remove from Bootstrap? Already dropping jQuery and very likely IE10/11 in our next major version." and "Need IE8/9? Use v3. Need IE10/11? Keep using v4. Don’t need IE10/11? Consider v5 whenever it comes :)" see https://twitter.com/getbootstrap/status/1080602583704625153 Thanks, Caty On Tue, Jun 12, 2018 at 8:06 PM Adel Atallah wrote: > Another solution would be to use non-IE11 features like CSS Flex or > grids and replace (in some way) css rules for IE11 browsers. > That way, we could have new features for newer browsers and a fallback > for IE11 browsers. > The main problem is that we would have more complexity, there would be > more code to write and also some cases might be difficult to handle. > So I wouldn't particularly go for this solution but I think it's worth > mentioning. > > Thanks, > Adel > > > On Tue, Jun 12, 2018 at 6:47 PM, Vincent Massol > wrote: > > My POV: > > > > * We need feedback from users, so I’d have asked on the forum first, > asking users. > > * I’d not drop support for IE11 right now in 10.x but in 11.0 at best > (and it’ll depend on the answer on the first point) > > * What is keeping support for IE11 costing us ATM, apart from the QA we > do for it? Are there things we’re preventing from doing that we could do if > we didn’t have IE11 to support? (sorry if it was in the older thread, > didn’t read it yet) > > > > Thanks > > -Vincent > > > >> On 12 Jun 2018, at 18:41, Ecaterina Moraru (Valica) > wrote: > >> > >> So, this dropping of IE11 needs to be discussed, so please disregard the > >> [VOTE] part of the mail subject and provide feedback about this idea and > >> the needs you have technically. > >> > >> Thanks, > >> Caty > >> > >> On Tue, Jun 12, 2018 at 7:28 PM, Ecaterina Moraru (Valica) < > >> vali...@gmail.com> wrote: > >> > >>> IE is the last browser we are supporting at a particular version, see > >>> http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy . > >>> For all the other browsers, we are supporting just the latest release. > >>> > >>> We are supporting the latest version of Microsoft Edge since XWiki 9.9, > >>> starting from 24/Oct/17. Microsoft Edge replaced Internet Explorer as > the > >>> default web browser since the release of Windows 10 (launched Jul > 2015). > >>> Internet Explorer 11 is maintained on Windows 10 for compatibility > >>> purposes, but is deprecated in favor of Edge and is no longer actively > >>> developed. > >>> > >>> We discussed dropping IE11 in the past Oct 6, 2017 (see > >>> https://xwiki.markmail.org/thread/qsrkka6zfrmyxv3d), but the vote > failed. > >>> > >>> Some updated statistics: > >>> > >>> -- > >>> > >>> XWiki.org's 1 year traffic (between Sep 30, 2016 - Sep 30, 2017) > compared > >>> to Oct 1, 2017 - May 31, 2018: > >>> - Internet Explorer dropped from (5.84%) to (4.65%) > >>> -- from this percentage, IE 11 usage has increased from (88.43%) to > >>> (88.76%) > >>> - Edge increased from (1.56%) to (1.84%). > >>> > >>> In terms of Worldwide market share for Desktops, for the past 12 months > >>> (according to > >>> http://gs.statcounter.com/browser-market-share/desktop/ ), we have > Sep, > >>> 2016 - Sep, 2017 compared to May 2017 - May 2018: > >>> - Internet Explorer dropped from 8.21% to 6.97% > >>> - Edge dropped from 4.3% to 4.15% > >>> > >>> In May 2018, Global Market Share Worldwide for All Platforms contains: > >>> - Chrome 58.09% > >>> - Safari 13.78% > >>> - UC Browser 8.16% > >>> - Firefox 5.27% > >>> - Opera 3.68% > >>> - Internet Explorer combined is at 3.08% (with IE 11 having 2.65%. > IE11 in > >>> August 2017 had 3.04%) > >>> - Edge combined having 1.91% (Edge combined in August 2017 had 1.8%) > >>> - etc. > >>> > >>> -- > >>> > >>> In terms of statistics, IE11 is more used than Microsoft Edge. The only > >>> argument of dropping IE11 is that it's a browser that is deprecated for > >>> about 3 years, and it's limiting the usage of newer specifications > (like > >>> CSS Flex, Grid, etc.) > >>> > >>> I'm curios about how this period of supporting both IE11 and Edge went, > >>> and if you have other examples of things you wanted to use and are not > >>> supported by IE11. > >>> > >>> Thanks, > >>> Caty > >>> > > >
Re: [xwiki-devs] [Proposal] Document picker in include and display macros
On Wed, Jan 23, 2019 at 3:08 PM Adel Atallah wrote:
> On Wed, Jan 23, 2019 at 11:31 AM Marius Dumitru Florea
> wrote:
> > It's not that simple.. If the reference parameter already has a value
> that
> > is not a document reference then by showing the document picker that
> value
> > will be parsed / resolved as a document reference and thus displayed as
> if
> > a document has been selected. This can confuse the users. For instance,
> if
> > someone writes in wiki syntax:
> >
> > {{include reference="path.to.p...@file.txt" type="ATTACHMENT"/}}
> >
> > and then edit the page with the WYSIWYG editor, he will see "txt" as
> > selected value when editing the macro...
>
>
> I just tried with `{{display reference="sandbox.webh...@xwikilogo.png"
> type="ATTACHMENT"/}}` and the element was displayed as is in the
> WYSIWYG editor.
> I think this is because the picker uses the search REST API
> (/wikis/{wikiName}/search) which doesn't seems to use a reference
> resolver.
> So one issue is that you won't have autocompletion if you use a prefix
> on a document reference.
>
>
> Also one think I don't currently like is that you cannot edit the
> selected item in the picker, which means, for instance, that if you
> made a typo in "sandbo.webh...@xwikilogo.png" then you'll have to
> delete this element and rewrite the whole reference.
>
I think you can copy the text, delete the option and paste the copied text.
It's not a big issue for me.
>
> I'll make a PR and show you some screenshots or videos so you can see
> what we could currently have.
>
Re: [xwiki-devs] [Proposal] Document picker in include and display macros
On Wed, Jan 23, 2019 at 11:31 AM Marius Dumitru Florea
wrote:
> It's not that simple.. If the reference parameter already has a value that
> is not a document reference then by showing the document picker that value
> will be parsed / resolved as a document reference and thus displayed as if
> a document has been selected. This can confuse the users. For instance, if
> someone writes in wiki syntax:
>
> {{include reference="path.to.p...@file.txt" type="ATTACHMENT"/}}
>
> and then edit the page with the WYSIWYG editor, he will see "txt" as
> selected value when editing the macro...
I just tried with `{{display reference="sandbox.webh...@xwikilogo.png"
type="ATTACHMENT"/}}` and the element was displayed as is in the
WYSIWYG editor.
I think this is because the picker uses the search REST API
(/wikis/{wikiName}/search) which doesn't seems to use a reference
resolver.
So one issue is that you won't have autocompletion if you use a prefix
on a document reference.
Also one think I don't currently like is that you cannot edit the
selected item in the picker, which means, for instance, that if you
made a typo in "sandbo.webh...@xwikilogo.png" then you'll have to
delete this element and rewrite the whole reference.
I'll make a PR and show you some screenshots or videos so you can see
what we could currently have.
Re: [xwiki-devs] [Proposal] Document picker in include and display macros
On Wed, Jan 23, 2019 at 12:36 PM Vincent Massol wrote:
>
>
> > On 23 Jan 2019, at 11:30, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Mon, Jan 21, 2019 at 4:10 PM Adel Atallah
> wrote:
> >
> >> To sum up, here is what I can do:
> >>
> >> On XWiki Commons:
> >> * Introduce a PropertyDisplayType annotation that we can use to
> >> specify with which type the macro parameter should be rendered.
> >> * Add the *display type* in the property descriptor (use the existing
> >> *property type* as default)
> >>
> >> On XWiki Rendering:
> >> * Add the *display type* in the parameter descriptor (use the existing
> >> *property type* as default)
> >>
> >> On XWiki Platform:
> >> * Use the PropertyDisplayType annotation, on reference macro
> >> parameters, with the EntityReference type (for the include and display
> >> macro)
> >>
> >
> >
> >> * Display a document picker for the EntityReference type and make sure
> >> free text is enabled (so that we can enter a reference manually)
> >>
> >
> > It's not that simple.. If the reference parameter already has a value
> that
> > is not a document reference then by showing the document picker that
> value
> > will be parsed / resolved as a document reference and thus displayed as
> if
> > a document has been selected. This can confuse the users. For instance,
> if
> > someone writes in wiki syntax:
> >
> > {{include reference="path.to.p...@file.txt" type="ATTACHMENT"/}}
> >
> > and then edit the page with the WYSIWYG editor, he will see "txt" as
> > selected value when editing the macro…
>
>
> Yes, I agree, this is what I was mentioning by "However if the user has
> used the macro in wiki mode, we’ll need to only display the
> DocumentReference picker if the type is Document.”.
>
The issue is that this part "*display the DocumentReference picker if the
type is Document*" is not easy to express through the macro descriptor.
That is: display the picker P for parameter X if another parameter Y has
the value V. Plus, the picker would need to change if the value of the
other parameter changes. The WYSIWYG editor doesn't have custom code for a
specific macro. It just looks at the macro descriptor and does whatever is
specified there, for any macro. ATM it sees two separate parameters,
reference and type, each with its own "picker" (a plain text input field
for now). It doesn't know it needs to reload the picker for reference when
the value of type changes. A possible solution is to be able to associate a
picker to a parameter group (reference+type).
Thanks,
Marius
>
> Thanks
> -Vincent
>
> >
> >>
> >> On the CKeditor application:
> >> * Use the *display type* instead of the *property type* when using the
> >> html displayer.
> >>
> >> I'll create the Jira issues and make the related PRs if we agree on
> this.
> >>
> >> On Mon, Jan 21, 2019 at 9:30 AM Adel Atallah
> >> wrote:
> >>>
> >>> On Sat, Jan 19, 2019 at 11:33 AM Vincent Massol
> >> wrote:
>
> Hi Adel,
>
> > On 18 Jan 2019, at 11:59, Adel Atallah
> >> wrote:
> >
> > On Fri, Jan 18, 2019 at 11:27 AM Vincent Massol
> >> wrote:
> >>
> >> Hi Adel,
> >>
> >>> On 17 Jan 2019, at 11:05, Adel Atallah
> >> wrote:
> >>>
> >>> Hi devs,
> >>>
> >>> After discussing with Marius and Thomas, we thought it might be a
> >> good
> >>> idea to do the following to have a document picker in the include
> >> and
> >>> display maros:
> >>> * Remove the deprecation of the document parameter (only for the
> >> include macro).
> >>
> >> I don’t understand this part. Sounds counter-intuitive to me since
> >> we want users to use the “reference” one. Could you explain?
> >
> > We currently only have a document picker that we can use for
> > DocumentReferences. To have auto-suggestion on the "reference"
> > parameter, we would need to make another picker for all type of
> > references, not just document.
>
> Ok I understand.
>
> But I don’t think it’s a good idea to remove the deprecation on
> >> “document”. This is deprecated for a good reason. And if we undeprecate
> it
> >> then we’ll need to redeprecate it soon enough and it also means
> >> “deprecating" “reference” so that it’s moved to the advanced section.
> It’s
> >> also bad for users who’ve been told to not use the “document” parameter.
> >> Without mentioning that the document parameter is only available in the
> >> legacy module and thus without legacy modules it wouldn’t work. Raises
> >> plenty of problems.
>
> Other Ideas instead:
> 1) Use the DocumentReference picker when the Type is Document and when
> >> the type is changed to something else, let the user type the reference.
> 2) Improve the picker to support picking any type of references:
> >> documents, spaces, wiki, attachments, objects, properties.
> 3) Now in practice the include macro only supports including Documents
> >> so we could also
Re: [xwiki-devs] MyXWiki.org legal information
1) Removed the CC part for the main wiki. Currently it will say: "This farm is governed by French and International legislation on copyright and intellectual property. Each wiki owner is responsible for their own content. Also the target of this farm are non-profit organizations and individuals, so the generated wiki should not be used for commercial purposes." 2) I've replaced XWikiSASGroup with the XWikiAdminGroup. I've updated the content of XWikiAdminGroup based on the data on XWiki.org's Hall Of Fame ( https://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame ). Currently the groups contains 8 admins, see https://www.myxwiki.org/xwiki/bin/view/XWiki/XWikiAdminGroup Thanks for your feedback. Caty On Wed, Jan 23, 2019 at 11:55 AM Thomas Mortagne wrote: > On Tue, Jan 22, 2019 at 8:43 PM Vincent Massol wrote: > > > > Hi Caty, > > > > > On 22 Jan 2019, at 12:52, Ecaterina Moraru (Valica) > wrote: > > > > > > Hi Devs, > > > > > > We had an user ask about MyXWiki.org privacy agreements, see > > > > https://forum.xwiki.org/t/agreement-on-wiki-at-myxwiki-org-privacy/4241 > > > > > > I've added more details on MyXWiki.org homepage about: > > > * Who is the legal entity behind MyXWiki? > > > * What about Copyright and Intellectual Property? > > > * What about Privacy Policy? > > > > > > See https://www.myxwiki.org/xwiki/bin/view/Main/ > > > > > > Please review it, see if you have more adjustments / details. > > > > Thanks for working on this! Looks good to me overall. Some small remarks > below. > > > > 1) "The content of this farm is licensed under a Creative Commons > license. Still, each wiki owner is responsible for their own content. Also > the target of this farm are non-profit organizations and individuals, so > the generated wiki should not be used for commercial purposes..”. > > > > I don’t understand these sentences. What is under CC? IMO the user is > free to choose the license they want for their contents. > > > > Or are you talking about the content of the main wiki only. If this is > the case then we should mention that. > > > > I agree it should be made a little bit more clear, but not really sure > we really need this since it does not really affect sub wiki content > which is the target of this documentation. > > > 2) "MyXWiki.org administrators have technical access…” > > > > The group used is wrong IMO. It shouldn’t be XWikiSASGroup but an > AdminGroup for Myxwiki.org which can include active committers from > different companies and not just XWiki SAS. Also some non-active committers > should be removed IMO (Caleb for example). > > > > Easiest might be to point to > https://www.myxwiki.org/xwiki/bin/view/XWiki/XWikiAdminGroup. Not sure > why we need an XWikiSASGroup BTW. > > +1, XWiki SAS is a sponsor here and not an admin > > > > > WDYT? > > > > Thanks > > -Vincent > > > > > Thanks, > > > Caty > > > > > -- > Thomas Mortagne >
Re: [xwiki-devs] [Proposal] Document picker in include and display macros
> On 23 Jan 2019, at 11:30, Marius Dumitru Florea
> wrote:
>
> On Mon, Jan 21, 2019 at 4:10 PM Adel Atallah wrote:
>
>> To sum up, here is what I can do:
>>
>> On XWiki Commons:
>> * Introduce a PropertyDisplayType annotation that we can use to
>> specify with which type the macro parameter should be rendered.
>> * Add the *display type* in the property descriptor (use the existing
>> *property type* as default)
>>
>> On XWiki Rendering:
>> * Add the *display type* in the parameter descriptor (use the existing
>> *property type* as default)
>>
>> On XWiki Platform:
>> * Use the PropertyDisplayType annotation, on reference macro
>> parameters, with the EntityReference type (for the include and display
>> macro)
>>
>
>
>> * Display a document picker for the EntityReference type and make sure
>> free text is enabled (so that we can enter a reference manually)
>>
>
> It's not that simple.. If the reference parameter already has a value that
> is not a document reference then by showing the document picker that value
> will be parsed / resolved as a document reference and thus displayed as if
> a document has been selected. This can confuse the users. For instance, if
> someone writes in wiki syntax:
>
> {{include reference="path.to.p...@file.txt" type="ATTACHMENT"/}}
>
> and then edit the page with the WYSIWYG editor, he will see "txt" as
> selected value when editing the macro…
Yes, I agree, this is what I was mentioning by "However if the user has used
the macro in wiki mode, we’ll need to only display the DocumentReference picker
if the type is Document.”.
Thanks
-Vincent
>
>>
>> On the CKeditor application:
>> * Use the *display type* instead of the *property type* when using the
>> html displayer.
>>
>> I'll create the Jira issues and make the related PRs if we agree on this.
>>
>> On Mon, Jan 21, 2019 at 9:30 AM Adel Atallah
>> wrote:
>>>
>>> On Sat, Jan 19, 2019 at 11:33 AM Vincent Massol
>> wrote:
Hi Adel,
> On 18 Jan 2019, at 11:59, Adel Atallah
>> wrote:
>
> On Fri, Jan 18, 2019 at 11:27 AM Vincent Massol
>> wrote:
>>
>> Hi Adel,
>>
>>> On 17 Jan 2019, at 11:05, Adel Atallah
>> wrote:
>>>
>>> Hi devs,
>>>
>>> After discussing with Marius and Thomas, we thought it might be a
>> good
>>> idea to do the following to have a document picker in the include
>> and
>>> display maros:
>>> * Remove the deprecation of the document parameter (only for the
>> include macro).
>>
>> I don’t understand this part. Sounds counter-intuitive to me since
>> we want users to use the “reference” one. Could you explain?
>
> We currently only have a document picker that we can use for
> DocumentReferences. To have auto-suggestion on the "reference"
> parameter, we would need to make another picker for all type of
> references, not just document.
Ok I understand.
But I don’t think it’s a good idea to remove the deprecation on
>> “document”. This is deprecated for a good reason. And if we undeprecate it
>> then we’ll need to redeprecate it soon enough and it also means
>> “deprecating" “reference” so that it’s moved to the advanced section. It’s
>> also bad for users who’ve been told to not use the “document” parameter.
>> Without mentioning that the document parameter is only available in the
>> legacy module and thus without legacy modules it wouldn’t work. Raises
>> plenty of problems.
Other Ideas instead:
1) Use the DocumentReference picker when the Type is Document and when
>> the type is changed to something else, let the user type the reference.
2) Improve the picker to support picking any type of references:
>> documents, spaces, wiki, attachments, objects, properties.
3) Now in practice the include macro only supports including Documents
>> so we could also simply do an override as you suggested (but on the
>> “reference” field), that would be used only for the WYSIWYG (when in wiki
>> mode you’d be able to enter only Document references). However if the user
>> has used the macro in wiki mode, we’ll need to only display the
>> DocumentReference picker if the type is Document.
>>>
>>> I think 3) is the simplest solution for now. We could always show the
>>> document picker on the "reference" field but allow free text so that
>>> other references can be manually entered.
>>>
I don’t think there are really good user use-cases for using something
>> else than the Document type since it’ll always translate into a Document in
>> the end so the user can always pick that doc instead of letting the macro
>> resolve it for him.
Note: If 1) or 2) or 3) are too hard for 11.0 (and it seems we’re too
>> late already since we’re releasing RC Monday!) then we could push that one
>> for later for the include/display macros and instead support other and
>> simpler well known macros in 11.0, from
>>
Re: [xwiki-devs] [Proposal] Document picker in include and display macros
On Mon, Jan 21, 2019 at 4:10 PM Adel Atallah wrote:
> To sum up, here is what I can do:
>
> On XWiki Commons:
> * Introduce a PropertyDisplayType annotation that we can use to
> specify with which type the macro parameter should be rendered.
> * Add the *display type* in the property descriptor (use the existing
> *property type* as default)
>
> On XWiki Rendering:
> * Add the *display type* in the parameter descriptor (use the existing
> *property type* as default)
>
> On XWiki Platform:
> * Use the PropertyDisplayType annotation, on reference macro
> parameters, with the EntityReference type (for the include and display
> macro)
>
> * Display a document picker for the EntityReference type and make sure
> free text is enabled (so that we can enter a reference manually)
>
It's not that simple.. If the reference parameter already has a value that
is not a document reference then by showing the document picker that value
will be parsed / resolved as a document reference and thus displayed as if
a document has been selected. This can confuse the users. For instance, if
someone writes in wiki syntax:
{{include reference="path.to.p...@file.txt" type="ATTACHMENT"/}}
and then edit the page with the WYSIWYG editor, he will see "txt" as
selected value when editing the macro...
>
> On the CKeditor application:
> * Use the *display type* instead of the *property type* when using the
> html displayer.
>
> I'll create the Jira issues and make the related PRs if we agree on this.
>
> On Mon, Jan 21, 2019 at 9:30 AM Adel Atallah
> wrote:
> >
> > On Sat, Jan 19, 2019 at 11:33 AM Vincent Massol
> wrote:
> > >
> > > Hi Adel,
> > >
> > > > On 18 Jan 2019, at 11:59, Adel Atallah
> wrote:
> > > >
> > > > On Fri, Jan 18, 2019 at 11:27 AM Vincent Massol
> wrote:
> > > >>
> > > >> Hi Adel,
> > > >>
> > > >>> On 17 Jan 2019, at 11:05, Adel Atallah
> wrote:
> > > >>>
> > > >>> Hi devs,
> > > >>>
> > > >>> After discussing with Marius and Thomas, we thought it might be a
> good
> > > >>> idea to do the following to have a document picker in the include
> and
> > > >>> display maros:
> > > >>> * Remove the deprecation of the document parameter (only for the
> include macro).
> > > >>
> > > >> I don’t understand this part. Sounds counter-intuitive to me since
> we want users to use the “reference” one. Could you explain?
> > > >
> > > > We currently only have a document picker that we can use for
> > > > DocumentReferences. To have auto-suggestion on the "reference"
> > > > parameter, we would need to make another picker for all type of
> > > > references, not just document.
> > >
> > > Ok I understand.
> > >
> > > But I don’t think it’s a good idea to remove the deprecation on
> “document”. This is deprecated for a good reason. And if we undeprecate it
> then we’ll need to redeprecate it soon enough and it also means
> “deprecating" “reference” so that it’s moved to the advanced section. It’s
> also bad for users who’ve been told to not use the “document” parameter.
> Without mentioning that the document parameter is only available in the
> legacy module and thus without legacy modules it wouldn’t work. Raises
> plenty of problems.
> > >
> > > Other Ideas instead:
> > > 1) Use the DocumentReference picker when the Type is Document and when
> the type is changed to something else, let the user type the reference.
> > > 2) Improve the picker to support picking any type of references:
> documents, spaces, wiki, attachments, objects, properties.
> > > 3) Now in practice the include macro only supports including Documents
> so we could also simply do an override as you suggested (but on the
> “reference” field), that would be used only for the WYSIWYG (when in wiki
> mode you’d be able to enter only Document references). However if the user
> has used the macro in wiki mode, we’ll need to only display the
> DocumentReference picker if the type is Document.
> >
> > I think 3) is the simplest solution for now. We could always show the
> > document picker on the "reference" field but allow free text so that
> > other references can be manually entered.
> >
> > >
> > >
> > > I don’t think there are really good user use-cases for using something
> else than the Document type since it’ll always translate into a Document in
> the end so the user can always pick that doc instead of letting the macro
> resolve it for him.
> > >
> > >
> > > Note: If 1) or 2) or 3) are too hard for 11.0 (and it seems we’re too
> late already since we’re releasing RC Monday!) then we could push that one
> for later for the include/display macros and instead support other and
> simpler well known macros in 11.0, from
> https://design.xwiki.org/xwiki/bin/view/Proposal/AutocompleteOnReference#HWYIWYGMacros,
> like DocumentTree macro.
> > >
> > > What I’d like is to have at least one macro that can use the picker in
> 11.0, mostly to prove that it works and to have something to report for
> users in the release notes and to show progress.
> > >
> > >
Re: [xwiki-devs] MyXWiki.org legal information
On Tue, Jan 22, 2019 at 8:43 PM Vincent Massol wrote: > > Hi Caty, > > > On 22 Jan 2019, at 12:52, Ecaterina Moraru (Valica) > > wrote: > > > > Hi Devs, > > > > We had an user ask about MyXWiki.org privacy agreements, see > > https://forum.xwiki.org/t/agreement-on-wiki-at-myxwiki-org-privacy/4241 > > > > I've added more details on MyXWiki.org homepage about: > > * Who is the legal entity behind MyXWiki? > > * What about Copyright and Intellectual Property? > > * What about Privacy Policy? > > > > See https://www.myxwiki.org/xwiki/bin/view/Main/ > > > > Please review it, see if you have more adjustments / details. > > Thanks for working on this! Looks good to me overall. Some small remarks > below. > > 1) "The content of this farm is licensed under a Creative Commons license. > Still, each wiki owner is responsible for their own content. Also the target > of this farm are non-profit organizations and individuals, so the generated > wiki should not be used for commercial purposes..”. > > I don’t understand these sentences. What is under CC? IMO the user is free to > choose the license they want for their contents. > > Or are you talking about the content of the main wiki only. If this is the > case then we should mention that. > I agree it should be made a little bit more clear, but not really sure we really need this since it does not really affect sub wiki content which is the target of this documentation. > 2) "MyXWiki.org administrators have technical access…” > > The group used is wrong IMO. It shouldn’t be XWikiSASGroup but an AdminGroup > for Myxwiki.org which can include active committers from different companies > and not just XWiki SAS. Also some non-active committers should be removed IMO > (Caleb for example). > > Easiest might be to point to > https://www.myxwiki.org/xwiki/bin/view/XWiki/XWikiAdminGroup. Not sure why we > need an XWikiSASGroup BTW. +1, XWiki SAS is a sponsor here and not an admin > > WDYT? > > Thanks > -Vincent > > > Thanks, > > Caty > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Document picker in include and display macros
Sounds good. +1 for me I would also add: * Use the PropertyDisplayType annotation, on page macro parameters, with the PageReference type (for the include and display macro). Does not cost anything and won't have any effect yet but it prepare for the future since that's what we'll want to do. On Mon, Jan 21, 2019 at 3:10 PM Adel Atallah wrote: > > To sum up, here is what I can do: > > On XWiki Commons: > * Introduce a PropertyDisplayType annotation that we can use to > specify with which type the macro parameter should be rendered. > * Add the *display type* in the property descriptor (use the existing > *property type* as default) > > On XWiki Rendering: > * Add the *display type* in the parameter descriptor (use the existing > *property type* as default) > > On XWiki Platform: > * Use the PropertyDisplayType annotation, on reference macro > parameters, with the EntityReference type (for the include and display > macro) > * Display a document picker for the EntityReference type and make sure > free text is enabled (so that we can enter a reference manually) > > On the CKeditor application: > * Use the *display type* instead of the *property type* when using the > html displayer. > > I'll create the Jira issues and make the related PRs if we agree on this. > > On Mon, Jan 21, 2019 at 9:30 AM Adel Atallah wrote: > > > > On Sat, Jan 19, 2019 at 11:33 AM Vincent Massol wrote: > > > > > > Hi Adel, > > > > > > > On 18 Jan 2019, at 11:59, Adel Atallah wrote: > > > > > > > > On Fri, Jan 18, 2019 at 11:27 AM Vincent Massol > > > > wrote: > > > >> > > > >> Hi Adel, > > > >> > > > >>> On 17 Jan 2019, at 11:05, Adel Atallah wrote: > > > >>> > > > >>> Hi devs, > > > >>> > > > >>> After discussing with Marius and Thomas, we thought it might be a good > > > >>> idea to do the following to have a document picker in the include and > > > >>> display maros: > > > >>> * Remove the deprecation of the document parameter (only for the > > > >>> include macro). > > > >> > > > >> I don’t understand this part. Sounds counter-intuitive to me since we > > > >> want users to use the “reference” one. Could you explain? > > > > > > > > We currently only have a document picker that we can use for > > > > DocumentReferences. To have auto-suggestion on the "reference" > > > > parameter, we would need to make another picker for all type of > > > > references, not just document. > > > > > > Ok I understand. > > > > > > But I don’t think it’s a good idea to remove the deprecation on > > > “document”. This is deprecated for a good reason. And if we undeprecate > > > it then we’ll need to redeprecate it soon enough and it also means > > > “deprecating" “reference” so that it’s moved to the advanced section. > > > It’s also bad for users who’ve been told to not use the “document” > > > parameter. Without mentioning that the document parameter is only > > > available in the legacy module and thus without legacy modules it > > > wouldn’t work. Raises plenty of problems. > > > > > > Other Ideas instead: > > > 1) Use the DocumentReference picker when the Type is Document and when > > > the type is changed to something else, let the user type the reference. > > > 2) Improve the picker to support picking any type of references: > > > documents, spaces, wiki, attachments, objects, properties. > > > 3) Now in practice the include macro only supports including Documents so > > > we could also simply do an override as you suggested (but on the > > > “reference” field), that would be used only for the WYSIWYG (when in wiki > > > mode you’d be able to enter only Document references). However if the > > > user has used the macro in wiki mode, we’ll need to only display the > > > DocumentReference picker if the type is Document. > > > > I think 3) is the simplest solution for now. We could always show the > > document picker on the "reference" field but allow free text so that > > other references can be manually entered. > > > > > > > > > > > I don’t think there are really good user use-cases for using something > > > else than the Document type since it’ll always translate into a Document > > > in the end so the user can always pick that doc instead of letting the > > > macro resolve it for him. > > > > > > > > > Note: If 1) or 2) or 3) are too hard for 11.0 (and it seems we’re too > > > late already since we’re releasing RC Monday!) then we could push that > > > one for later for the include/display macros and instead support other > > > and simpler well known macros in 11.0, from > > > https://design.xwiki.org/xwiki/bin/view/Proposal/AutocompleteOnReference#HWYIWYGMacros, > > > like DocumentTree macro. > > > > > > What I’d like is to have at least one macro that can use the picker in > > > 11.0, mostly to prove that it works and to have something to report for > > > users in the release notes and to show progress. > > > > > > Thanks > > > -Vincent > > > > > > > > > > >> > > > >> Thanks > > > >> -Vincent > > > >> > >
