No you need admin right for XAR extension (since it's saved with you as author) but you need PR for jar extensions (since jar extension can do anything).
On Tue, Apr 26, 2016 at 12:46 PM, Eduard Moraru <[email protected]> wrote: > On Tue, Apr 26, 2016 at 10:05 AM, Thomas Mortagne <[email protected] >> wrote: > >> That still require programming right :) >> > > I don`t understand. You need PR for your user in order to be able to > install extensions in EM? I thought you only need admin rights and that > there is no discrimination between extension types (xar, jar, etc.). > > Also, once the (jar) extension is installed, we no longer care about XWiki > rights since we have direct access to the platform (any events, etc.). > > Am I missing something? > > >> >> The best would be to have a helper for XAR extensions in the core. >> Something like a specific wiki listener which allow safely listen to >> some events without the need for programming right. >> >> On Tue, Apr 26, 2016 at 12:27 AM, Eduard Moraru <[email protected]> >> wrote: >> > Well, I guess that if a XAR extension needs to migrate its data, it will >> > have to depend on some jar extension that will have the migration code >> and >> > that will be its only purpose. >> > >> > Thanks, >> > Eduard >> > >> > On Mon, Apr 25, 2016 at 3:46 PM, Thomas Mortagne < >> [email protected]> >> > wrote: >> > >> >> On Mon, Apr 25, 2016 at 12:10 PM, Eduard Moraru <[email protected]> >> >> wrote: >> >> > On Fri, Apr 22, 2016 at 8:08 PM, Thomas Mortagne < >> >> [email protected]> >> >> > wrote: >> >> > >> >> >> On Fri, Apr 22, 2016 at 5:59 PM, Clemens Klein-Robbenhaar >> >> >> <[email protected]> wrote: >> >> >> > >> >> >> >> On Fri, Apr 22, 2016 at 5:34 PM, Thomas Mortagne >> >> >> >> <[email protected]> wrote: >> >> >> >>> Sounds good. >> >> >> >>> >> >> >> >>> What about upgrades, do you plan to provide a migrator ? >> >> >> >> >> >> >> >> (I would love to see my old calendars converted to new style ;)) >> >> >> >> >> >> >> > >> >> >> > I have to check out the >> >> >> >> >> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Nested+Pages+Migrator+Application >> >> >> > and see how it works / if it can be adapted to nested pages, etc. >> >> >> > >> >> >> > I guess this will be a separate application / helper etc in any >> case, >> >> or >> >> >> is there a way to trigger the migration when installing a newer >> version? >> >> >> >> >> >> There is an ExtensionUpgradedEvent event that an extension can listen >> >> >> to be called after it's upgraded. >> >> >> >> >> > >> >> > Cool! Did not know about that. So we can have per-extension migration >> >> > scripts, which would kind of superseed the XWiki migration framework >> >> (that >> >> > work with the XWiki DB version) and we would only be still using that >> for >> >> > core changes. Right now we use the XWiki DB version even for bundled >> app >> >> > migrations. >> >> > >> >> > I guess we should document that somewhere and make it a best practice >> (if >> >> > not already). >> >> >> >> It's OK in Java but impossible to use that in a XAR extension that >> >> might be installed without programming right (since wiki component >> >> require PR). >> >> >> >> > >> >> > Thanks, >> >> > Eduard >> >> > >> >> >> >> >> >> > >> >> >> > No deadline for this in my scedule yet, however .... >> >> >> > >> >> >> > >> >> >> >>> >> >> >> >>> On Fri, Apr 22, 2016 at 5:31 PM, Clemens Klein-Robbenhaar >> >> >> >>> <[email protected]> wrote: >> >> >> >>>> >> >> >> >>>> I see there has been some discussion on the list, as far as I >> >> >> understand there is no decision about it in general. >> >> >> >>>> >> >> >> >>>> However I would like to drop support for pre-nested pages for >> the >> >> >> mocca calendar on the master branch right now. >> >> >> >>>> >> >> >> >>>> The pre-nested spaces structure is: >> >> >> >>>> >> >> >> >>>> - Calendars are plain pages >> >> >> >>>> - Events are pages that have their calendar as parent page, >> but >> >> are >> >> >> usually placed as siblings in the same space >> >> >> >>>> (necessarily w/o nested pages) >> >> >> >>>> >> >> >> >>>> It is more natural to have calendars as nestable, non-terminal >> >> pages, >> >> >> and the corresponding events nested inside these calendar pages. >> >> >> >>>> >> >> >> >>>> Bugs that would be easy to solve after dropping support: >> >> >> >>>> >> >> >> >>>> http://jira.xwiki.org/browse/MOCCACAL-91 "Cannot create two >> >> events >> >> >> with the same title in the same calendar " >> >> >> >>>> This has been fixed in 2.5.1 for pre-nested pages, but that >> fix >> >> >> does not work for nested pages. >> >> >> >>>> Admittedly it could also be fixed with an if (nested space) >> do >> >> x >> >> >> else y >> >> >> >>>> I have to admit that I am reluctant to implement the if-else >> >> fork >> >> >> and fully test it (If I do not test both nested and pre-nested >> spaces it >> >> >> will be broken with high probability) >> >> >> >>>> In some places there are already horrible if-else clauses to >> >> >> support both colibri and flamingo, which I put there and the >> experience >> >> >> makes me unwilling to try this again with nested spaces. >> >> >> >>>> >> >> >> >>>> http://jira.xwiki.org/browse/MOCCACAL-93 "Preinstalled "Other >> >> >> Events" Calendar should not be a terminal page" >> >> >> >>>> This actually can not be fixed in a pre-nested spaces >> compatible >> >> >> way (I think) >> >> >> >> >> >> >> >> Another great feature of nested space based calendar: you can >> watch a >> >> >> >> single calendar just by watching its page instead of having to >> watch >> >> >> >> eveything. >> >> >> >> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> Proposal: >> >> >> >>>> a) there is already a "stable-2.5" branch. >> >> >> >>>> all fixes and improvements for pre-nested spaces >> will/should go >> >> >> on this branch >> >> >> >>>> b) master will switch its xwiki platform dependency from 5.4 to >> >> 7.4.2 >> >> >> >>>> (not 7.2 for me, because 7.4.2 is what I am willing to test >> >> >> against ... any takers to test with 7.2 ?) >> >> >> >>>> c) for now, the old "parent-child" relationship will still be >> used >> >> >> to determine which events belong to which calendar >> >> >> >>>> so no migration from pre-nested spaces is really necessary >> - at >> >> >> least I think so. Of course this should be tested. >> >> >> >>>> (It would be nice to have such migration, of course. I am >> not >> >> >> sure how to write this, however.) >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> Any opinions? Should I send an official [vote] request? >> >> >> >>>> >> >> >> >>>> Clemens >> >> >> >>>> _______________________________________________ >> >> >> >>>> devs mailing list >> >> >> >>>> [email protected] >> >> >> >>>> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> -- >> >> >> >>> Thomas Mortagne >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > mit freundlichen Grüßen >> >> >> > Clemens Klein-Robbenhaar >> >> >> > >> >> >> > -- >> >> >> > Clemens Klein-Robbenhaar >> >> >> > Software Development >> >> >> > EsPresto AG >> >> >> > Breite Str. 30-31 >> >> >> > 10178 Berlin/Germany >> >> >> > Tel: +49.(0)30.90 226.763 >> >> >> > Fax: +49.(0)30.90 226.760 >> >> >> > [email protected] >> >> >> > www.espresto.de >> >> >> > >> >> >> > HRB 77554 B - Berlin-Charlottenburg >> >> >> > Vorstand: Maya Biersack, Peter Biersack >> >> >> > Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber >> >> >> > Zertifiziert nach ISO 9001:2008 >> >> >> > _______________________________________________ >> >> >> > devs mailing list >> >> >> > [email protected] >> >> >> > http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Thomas Mortagne >> >> >> _______________________________________________ >> >> >> devs mailing list >> >> >> [email protected] >> >> >> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> >> > _______________________________________________ >> >> > devs mailing list >> >> > [email protected] >> >> > http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> >> >> >> >> -- >> >> Thomas Mortagne >> >> _______________________________________________ >> >> devs mailing list >> >> [email protected] >> >> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
