- xwiki-devs@xwiki.org - lists.xwiki.org

Re: [xwiki-devs] How to add a user to a group programmatically?
by jordiduran 04 Apr '13

04 Apr '13

Hello, first I would like to say thank you for your reply, and tell you I use XEM 4.0. I use the code bellow to authorize a user and the same time to assign in a group, if he/she doesn't exist. The problems is when the code performs the assignment in a group, since you are not logged in, you are a XWikiGuest, the group page have to have explicit rights (edit) for the guest. /** * * @author jdurancal */ @Component public class LTIAuthServiceImpl extends XWikiAuthServiceImpl { @Override public Principal authenticate(String username, String password, XWikiContext context) throws XWikiException { XWikiServletRequest request = (XWikiServletRequest) context.getRequest(); if (!context.getAction().equalsIgnoreCase("logout")) { try { LTIEnvironment LTIEnvironment = new LTIEnvironment(request); if (LTIEnvironment.isAuthenticated()) { String usernameLTI = LTIEnvironment.getUserName(); if (usernameLTI.contains(":")) { usernameLTI = usernameLTI.split(":")[1]; } // get the group to assigna to the user. String group = LTIEnvironment.getParameter("custom_groups"); return syncUser(usernameLTI, group, context, LTIEnvironment.isInstructor()); } else { Exception lastException = LTIEnvironment.getLastException(); System.out.println("Error LTI authentication " + (lastException != null ? lastException.getMessage() : "")); } } catch (Exception ex) { System.out.println("Execption authentication " + ex); } } // Fallback on standard XWiki authentication return super.authenticate(username, password, context); } /** * Creates the user if he doesn't exist in the XWiki repository. User is assigned * to the default XWikiAllGroup * @param user * @param context * @throws com.xpn.xwiki.XWikiException */ protected Principal syncUser(String user, String groupName, XWikiContext context, boolean isInstructor) throws XWikiException { String xwikiUser = super.findUser(user, context); String wikiNameShow = context.getDatabase(); System.out.println("["+wikiNameShow+"] usernameLTI="+user+", GroupsLTI:"+groupName); if (xwikiUser == null) { System.out.println("["+wikiNameShow+"] LTI Create user: User " + user + " does not exist"); String wikiname = context.getWiki().clearName(user, true, true, context); context.getWiki().createEmptyUser(wikiname, "edit", context); System.out.println("["+wikiNameShow+"] LTI Create user: User " + user + " has been created"); xwikiUser = "XWiki."+user; // if the user is "instructor", assign admin rights except in speakapps wiki if (isInstructor && !context.getWiki().getName().equalsIgnoreCase("speakapps")) { try { this.addUserGroup(xwikiUser, user, "XWikiAdminGroup", context); }catch(Exception ex) { System.out.println("["+wikiNameShow+"] Execption adding admin user "+ex); } } } // És un group però no és l'administrador if (groupName != null && !groupName.equalsIgnoreCase("XWikiAdminGroup")) { try { this.addUserGroup(xwikiUser, user, groupName, context); }catch(Exception ex) { System.out.println("["+wikiNameShow+"] Execption adding user a \""+groupName+"\" group "+ex); } } return new SimplePrincipal(context.getDatabase() + ":" + xwikiUser); } private boolean addUserGroup(String xwikiUser, String user, String groupName, XWikiContext context) throws XWikiException { boolean isAdded = false; Group group = Group.getGroup("XWiki", groupName, context); if (group != null && !group.isMember(xwikiUser, context)) { if (group.addUser(user, context)) { group.save(context); isAdded = true; System.out.println("["+context.getDatabase()+"] add a \""+groupName+"\" member " + xwikiUser); } } return isAdded; } } Best regards. -- View this message in context: http://xwiki.475771.n2.nabble.com/How-to-add-a-user-to-a-group-programmatic… Sent from the XWiki- Dev mailing list archive at Nabble.com.

1 0

[xwiki-devs] [ANN] XWiki 5.0 Milestone 2 released
by Thomas Mortagne 03 Apr '13

03 Apr '13

The XWiki development team is proud to announce the availability of XWiki 5.0 Milestone 2. This release introduces some important changes like the new security module by default, XWiki is now always in virtual mode, JQuery is embedded by default, xwiki/1.0 syntax is now disabled and lots of other improvements. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki50M2 Thanks -The XWiki dev team

1 0

Re: [xwiki-devs] How to add a user to a group programmatically?
by jordiduran 03 Apr '13

03 Apr '13

Hi Adreas, I'm the same problem as you, have you got the solution? Thanks! -- View this message in context: http://xwiki.475771.n2.nabble.com/How-to-add-a-user-to-a-group-programmatic… Sent from the XWiki- Dev mailing list archive at Nabble.com.

3 2

[xwiki-devs] [ANN] Test Reporting Application
by Sorin Burjan 02 Apr '13

02 Apr '13

Hello everybody, I have created a Test Reporting Application in order to make the Manual Testing Plan more easily to follow and execute. The rationale behind this is: * Hard to update a monolith page with all the manual tests performed * When someone who is testing is updating the page, no other user can update the page * It allows existing manual cases to be marked as automated (if we have an automated tests for them) * Easier to follow, track over what has been tested and what not Since I'd like to propose this to be used in the XWiki community for our Manual Test cases, I have put a live version on Incubator along with some test cases so I can get your suggestions before putting it in actual production/usage. I'm sure you will have some cool suggestions on how to improve it even further. So give it a try. I have also added a suggestions page linked form the application homepage. Note that the application was designed to be generic, so everybody can use it in their own software project. Contrib repo: https://github.com/xwiki-contrib/application-testreporting Incubator Live version: http://incubator.myxwiki.org/xwiki/bin/view/QA/WebHome Suggestions page: http://incubator.myxwiki.org/xwiki/bin/view/QA/Suggestions Looking forward to get your feedback ! Regards, Sorin B.

5 6

[xwiki-devs] Two skins, one DB?
by Paul Libbrecht 02 Apr '13

02 Apr '13

Hello fellow developers, has anyone tried running two XWiki instances on the same DB? I think everyone doing clustering does this, with the addition of the observation module for emptying caches when appropriate. Has anyone tried running this same configuration (two servers simultaneously) but with two different URLs and two different skins? (but the same core)? It looks just as doable to me. Or? Thanks for hints. Paul

3 4

[xwiki-devs] [Retrospective] Big slippage on all aspects for 5.0M2 - Chance to learn
by Vincent Massol 02 Apr '13

02 Apr '13

Hi devs, I'd just like to point out that 5.0M2 seems to be a very bad release WRT the roadmap we had defined, although a lot of hard work has been done. It's been a long time since we've diverged that much actually. Let's take this as a chance to learn and do a quick retrospective. Roadmap: http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome Misses from Roadmap: * SOLR implementation missing the scheduler and thus cannot replace the default search. Main reason: Edy is sick currently. * AppWithinMinutes work * Scalable import/export * Home page improvements (XE) and usability improvements in general * Horizontal Menu management (add, remove pages) * XEM Homepage / Portal investigation * New Activity Stream Investigation Hits: * EM upgrade of subwikis. Mostly done but still missing a few things * virtual=1 by default * WYSIWYG Editor improvements * 60% of listed important bugs * General Flavours Investigation And WRT dates we're slipping by 10 to 15 days…. Other miss: the build stability. The whole build has been down for over 10 days and there are still failing modules. There has been a lot of stuff done of course but they were not planned (i.e not on the roadmap). This is our biggest miss and what I want to point out: we've not followed the defined roadmap and instead we've done other stuff like putting the new security module on by default which took us very long. We need to learn from what happened to handle it better next time and we now need to get back on track and go back to following our defined roadmap. IMO the following should have been done better (and that's what we should learn for next time): * Discuss replacing some items from the roadmap by others from the beginning. For ex don't take the task of setting the new security as the default without putting it in the roadmap * Setting the new security module should have been done on a branch and the tests/code fixed there before merging it on master. As a general rule nobody should commit anything on master knowing that it would break the build. Because that impacts everyone and prevents everyone from working on what they have to work on. * Similarly, if a commit is done and we realize afterwards that it breaks a lot of stuff, we should revert and put on a branch (I have the JUnit 4.11 upgrade in mind, which changed test order) * Removing xwiki/1.0 syntax by default with the breakage of several tests should also not have been committed directly without fixing the tests first, either locally or on a branch if we want to share the workload WDYT? Do we agree about handling it this way for next time? Since I wasn't there during most of this timeframe (holiday for 1 week and then conference for another week) I may have missed some other stuff an I may even be wrong about what happened. Please correct me or add what I missed. Thanks -Vincent

1 0

Re: [xwiki-devs] [xwiki-notifications] xwiki-platform Quality Checks - Build # 210 - Failure!
by Sergiu Dumitriu 01 Apr '13

01 Apr '13

On 04/01/2013 03:20 PM, Jenkins wrote: > [WARNING] Insufficient code coverage for INSTRUCTION: 9.47% < 9.48% Happened again... -- Sergiu Dumitriu http://purl.org/net/sergiu

1 0

[xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
by Denis Gervalle 01 Apr '13

01 Apr '13

Hi devs, We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg: xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService (Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.) So this vote is about changing the default in xwiki.cfg before 5.0M2. pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones - possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki. - may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1 WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

9 28

[xwiki-devs] [Idea] Add similar issue feature to our JIRA
by Vincent Massol 01 Apr '13

01 Apr '13

Hi guys, I'd like to add the "similar issues" features of http://www.plugenta.com/suggestimate/jira/tour.html You can see it in action at https://jira.exoplatform.org/browse/CRASH-114 for example. I've asked plugenta for a free open source license. Hope this is fine with you all. Let me know if you have any issue with this. Thanks -Vincent

2 2

[xwiki-devs] [VOTE] Retire the old WYSIWYG editor
by Sergiu Dumitriu 01 Apr '13

01 Apr '13

Hi devs, Related to the other vote about disabling the xwiki/1.0 syntax [1], I'd like to retire the old WYSIWYG editor. Although there aren't any obvious benefits, on the contrary it, removes an important feature, the advantages for doing this are: - fewer bugs (there are known bugs that we've decided not to fix since we agreed not to maintain it anymore) - less code (the .vm templates that support the editor are really crappy and I'd be very happy to get rid of them completely) - strongly encourages (developer) users to migrate to the new syntax - less non-valid, non-accessible code (standards compliance) - fewer places where XSS holes can hide (security) Personally I'd like to remove it completely, but there's also the option of putting it in a -legacy- module, still enabled in the final releases. This makes two options: A) Move the editor in a xwiki-contrib retired module B) Move the editor in xwiki-platform-legacy-web and leave it enabled My +1 goes for A. [1] http://xwiki.markmail.org/thread/6damxrncgohtk4oc -- Sergiu Dumitriu http://purl.org/net/sergiu/

5 4