xwiki-devs September 2011

xwiki-devs@xwiki.org

23 participants
65 discussions

[xwiki-devs] [VOTE] Should "delete" rights be considered at the document level?

by Sergiu Dumitriu

Rights have different scopes in XWiki. Administration rights can only be set on a space or wiki level, and any "admin" right set on a document alone will be silently ignored. Programming rights are only considered when set on the xwiki:XWiki.XWikiPreferences document, being ignored in any other virtual wiki and at the space or document level. Delete rights are a bit special as well. By default, the creator of a document has delete rights on that document. Unlike the other rights which default to true when no right is set, this one defaults to false. So, by default, when no "delete" rights are set on the document/space/wiki, only the creator of a document and administrators are allowed to delete it. Should we allow setting the delete right at the document level? Personally, I'd say no, since it's a rare requirement for a non-creator to be able to delete just one document. Space-level rights should be enough, IMO. -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 10 months

[xwiki-devs] [Proposal] Use artifact id as directory names

by Vincent Massol

Hi devs, The proposal is to use artifactid as directory names. Note that this is what I did for commons and rendering when I did the move to top level project. You can check how it looks like here: http://svn.xwiki.org/svnroot/xwiki/commons/ http://svn.xwiki.org/svnroot/xwiki/rendering/ I suggest we keep one strategy only for consistency. Some discussion here too: http://www.sonatype.com/people/2011/01/maven-tip-project-directories-and-ar… I know there are some cons (see my comment in the link above) but overall I find it simple to implement and with autocompletion not such a big issue. WDYT? If you don't like this then please propose an alternative solution and remember that we'll need to refactor commons and rendering in this case too. Thanks -Vincent

12 years, 10 months

[xwiki-devs] [PROPOSAL] Move oldcore query plugin to legacy

by Thomas Mortagne

Hi dev, The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query. So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it Note planning to do it in 3.2, that's for 3.3M1. WDYT ? +1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE -- Thomas Mortagne

12 years, 11 months

[xwiki-devs] [Proposal] XEclipse Release

by Vincent Massol

Hi devs, Fabio and Eddy are working on merging Jun's GSOC code in master for XEclipse and are preparing for a release (could you send us a proposal guys?). It seems that the last release of XEclipse was 1.2RC1 so it's a bit of a shitty situation since normally so much change would have warranted a 1.3 release. However I'm proposing that the next release be 1.2RC2 and when we've tested it enough we then quickly release 1.2 final to get it over with. The alternative is to: - get the 1.2RC1 tag - release it again as 1.2 final - consider all Jun's changes to be 1.3M1 However that solution has 2 issues: - it's more time consuming - we're not 100% sure that the last 1.2RC1's quality was good enough to be named 1.2 final WDYT? My preferences goes to having Jun's code be in a 1.2RC2 release. Thanks -Vincent

12 years, 11 months

[xwiki-devs] [VOTE] Generalize concept of legacy module to XWiki Commons and even more generally

by Vincent Massol

Hi devs, I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise). The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module. My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module. Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step. It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it). Here's my +1 to follow this practice across our code base and to document it on xwiki.org Thanks -Vincent

12 years, 11 months

[xwiki-devs] [VOTE] Release XWiki Enterprise+Manager 3.1.1

by Sergiu Dumitriu

Hi devs, Since the 3.2 release is approaching, I'd like to close the stable 3.1.x branch as well with a final 3.1.1 release, probably on October 3rd. If you have any important bugfixes you want to see in this release, please push them ASAP. -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 11 months

[xwiki-devs] [Announcement] XWiki Enterprise 3.2 Milestone 3 released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Enterprise 3.2 Milestone 3, the last milestone of the XWiki Enterprise 3.2 version (see the roadmap at http://enterprise.xwiki.org/xwiki/bin/Main/Roadmap ). Main new features include: * improved Lucene scoring * new implementation of the sheet system * support for OpenOffice 3.3 as the backend of the office importer * better support for IE9 in the WYSIWYG editor * many improvements in the extension manager and extension repository * the removal of the Albatross skin from the distribution * ... and quite a lot of dependency upgrades and bug fixes See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32M3 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 11 months

[xwiki-devs] What happens when you do a permissions check and how it can happen faster.

by Caleb James DeLisle

Hi folks, I decided to do an analysis of how exactly how permissions are checked so we might be able to brainstorm about where there is low hanging fruit in the optimization field. 0. Check that the user is authenticated 1. If user is attempting write operation on read-only wiki, return false. 2. If user is a guest, get XWikiPreferences for the wiki and do 4 checks on the XWikiPreferences object to see if the action requires authentication. 3. If action is "delete", get current document and check if current user created that document. 4. Determine if user is superadmin 5. Load DocumentReferenceResolver from ComponentManager and normalize username then compare to superadmin name. 6. Check for admin status on main wiki 7. Get XWikiPreferences document for main wiki 8. scan for rights objects which allow the user "admin" permission, return if found 9. get list of all groups which user is a member of, repeat check for each, returning if found 10. If checking permission for "programming" then repeat from step 7 with "programming" as permission. 11. If the permission being checked is programming, return the result even if false. 12. If in a subwiki, get the XWikiServer<subwiki> document and return if the current user is the owner. 13. If checking for register permission then get the XWikiPreferences document for the wiki. 14. scan for rights objects which allow the user, return if found 15. get list of all groups which user is a member of, repeat check for each, returning if found 16. if no match is found, check for deny rights on the user, return if found 17. get list of all groups which user is a member of, repeat check for each, returning if found 18. Get XWikiPreferences from wiki 19. scan for rights objects which allow the user "admin" permission, return if found. 20. get list of all groups which user is a member of, repeat check for each, returning if found 21. Get WebPreferences for space where document to check permissions resides. 22. scan for rights objects which allow the user "admin" permission, return if found. 23. get list of all groups which user is a member of, repeat check for each, returning if found 24. if the WebPreferences document specifies another Space as it's "parent" then change to that space and return to step 21. 25. Get the document to check permission on 26. scan for rights objects which deny the user, return if found 27. get list of all groups which user is a member of, repeat check for each, returning if found 28. scan for rights objects which allow the user, return if found 29. get list of all groups which user is a member of, repeat check for each, returning if found 30. Get the WebPreferences document for the space where document to check permission on resides. 31. scan for rights objects which deny the user, return if found 32. get list of all groups which user is a member of, repeat check for each, returning if found. 33. scan for rights objects which allow the user, return if found 34. get list of all groups which user is a member of, repeat check for each, returning if found. 35. Check if the WebPreferences document specifies a "parent space" if so, change to that space and go to step 30. 36. Get the XWikiPreferences document for the wiki 37. scan for rights objects which deny the user, return if found 38. get list of all groups which user is a member of, repeat check for each, returning if found 39. scan for rights objects which allow the user, return if found 40. get list of all groups which user is a member of, repeat check for each, returning if found Getting the list of groups which a user is a member of is relatively quick after the first run since it is cached. After being loaded it is stored in the context but the implementation doesn't trust the version in the context and gets it again. It could be a little bit faster by just assuming that anything in the context is still valid. If a group is a member of another group then the checks will be repeated twice each time. One thought that comes to mind is that we could check permissions on a user and all of the groups of which he is a member, simultaneously. This would reduce the number of scans over the list of objects in a given document and since this is such a hotspot, I think optimizations like this might pay off. Documents which need to be loaded include: The XWikiPreferences for the main wiki XWikiPreferences for the subwiki (if applicable) WebPreferences for the space (and any space listed as a parent) The document which we are checking If in a subwiki, the XWikiServer<subwiki> document This means that for any level of performance, all documents other than the document we are checking need to remain in the cache perpetually. Since the vast majority of checks are for things like view and edit with users who don't have programming or admin permission, it makes sense to rearrange the checks so that the most common path executes the fastest. This would be a major project though. Any other thoughts and ideas about it? Caleb

12 years, 11 months

[xwiki-devs] Fresh install of XWiki Enterprise Manager required

by David Henry

Hi Guys, I need a fresh install of XWiki Enterprise Manager. Drop me a line if you're interested. David Henry** *Modus* * * 18 Exchange Street Upper, Temple Bar, Dublin 2, Ireland. e: david(a)modus.ie | p: +353 1 677 9745 | m: +353 86 8300943

12 years, 11 months

[xwiki-devs] [VOTE] Workspaces extension as part of the platform in 3.2

by Eduard Moraru

Hi devs, I`m asking for your vote to include Workspaces [1] as an extension that would be part of the platform for the 3.2 release. It would not be bundled by default just yet, but it will be available to install as an extension using the Extension Manager. This vote is related to the previous mail [2] I`ve sent about adding some hooks in the platform specifically for the workspaces feature. The difference now is that the feature would no longer be an "external" extension but it would be supported and maintained by XWiki devs (me). This means accepting the technical debt introduced by the proposed hooks [2] and making it my responsibility to maintain the application and ensure the hooks are gradually removed from the platform when cleaner alternatives are introduced. An overview of the workspaces feature is available in the project preview mail [3] (or even [4]) I`ve sent some time ago that included the live demo [5]. Thanks, Eduard References: ----------------- [1] https://github.com/xwiki-contrib/wiki30/tree/master/wiki30-social [2] http://xwiki.markmail.org/thread/qgjcehgmqpkbwbvw [3] http://xwiki.markmail.org/thread/223ensce4tikygmz [4] http://xwiki.markmail.org/thread/3cbms22ctbqi4yqp

12 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2011