xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] Fwd: XWiki Search not happening even after giving him the proper rights|| Adding user to different group by default

by mohit gupta

Just a minor connection in ISSUE2. here it is :- * ISSUE2:-*.As a part of single sign on process of XWiki with my webapplication i am creating empty user with API context.getWiki().createEmptyUser. But that user is getting added to group XWikiAllGroup <http://localhost:8888/myxwiki/bin/view/XWiki/XWikiAllGroup> automatically.Actually I want to decide the default group name where user will be added by default based on some condition . i am not getting where should i make the change for this. ---------- Forwarded message ---------- From: mohit gupta <motgupta(a)gmail.com> Date: Thu, Dec 22, 2011 at 5:24 PM Subject: XWiki Search not happening even after giving him the proper rights|| Adding user to different group by default To: devs(a)xwiki.org I have two issues when i am trying to integrate my webapplication with XWiki. One is related to not able to search the content even after giving the proper rights and another is when .As a part of single sign on process of XWiki with my webapplication i am creating empty user with API context.getWiki().createEmptyUser. But that user is getting added to group XWikiAllGroup <http://localhost:8888/myxwiki/bin/view/XWiki/XWikiAllGroup> automatically. I want to add this user to a to a different group say AccentureUserGroup instead of XWikiAllGroup<http://localhost:8888/myxwiki/bin/view/XWiki/XWikiAllGroup>. i am not getting where should i make the change for this. Below are the details:- * * *Issue1:- *My intention is if an user belongs to particular organisation and he is just a registered user but not admin user for that organization say Accenture he should be able to only view and search that organization spacevotherwise he should not be able to do any operation (not even search and view) on any other space *What I Did for to achieve above* :- I as admin created AccentureUser and AccentureUserGroup . Now i added AccentureUser under AccentureUserGroup. Also I created the space for this organization with Name AccentureSpace. Lets come to Rights Management. As there are two level of rights i.e at Wiki level and Space level. AT Wiki Level:- I gave only view rights to AccentureUserGroup AT Space Level:- I gave only view rights to AccentureUserGroup for AccentureSpace Now when i log in with AccentureUser credentials, i can see AccentureSpace space on a page just after log in but i am not able to search any content(space or page) for this AccentureSpace . Not Getting Why? Do i need to give any other Right too for search? I would be grateful if somebody can provide some insight about above issues on right management.Already I have gone thru below links but did not get through the issues http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement right management http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Access+Rights access and rights *ISSUE2:-*.As a part of single sign on process of XWiki with my webapplication i am creating empty user with API context.getWiki().createEmptyUser. But that user is getting added to group XWikiAllGroup <http://localhost:8888/myxwiki/bin/view/XWiki/XWikiAllGroup> automatically. I want to add this user to a to a different group say AccentureUserGroup instead of XWikiAllGroup<http://localhost:8888/myxwiki/bin/view/XWiki/XWikiAllGroup>. i am not getting where should i make the change for this. Posted issue 1 on XwikiUser group also but has not got any reply yet. Looking for quick reply.Thanks in advance.

13 years, 1 month

[xwiki-devs] XWiki Search not happening even after giving him the proper rights|| Adding user to different group by default

by mohit gupta

I have two issues when i am trying to integrate my webapplication with XWiki. One is related to not able to search the content even after giving the proper rights and another is when .As a part of single sign on process of XWiki with my webapplication i am creating empty user with API context.getWiki().createEmptyUser. But that user is getting added to group XWikiAllGroup <http://localhost:8888/myxwiki/bin/view/XWiki/XWikiAllGroup> automatically. I want to add this user to a to a different group say AccentureUserGroup instead of XWikiAllGroup<http://localhost:8888/myxwiki/bin/view/XWiki/XWikiAllGroup>. i am not getting where should i make the change for this. Below are the details:- * * *Issue1:- *My intention is if an user belongs to particular organisation and he is just a registered user but not admin user for that organization say Accenture he should be able to only view and search that organization spacevotherwise he should not be able to do any operation (not even search and view) on any other space *What I Did for to achieve above* :- I as admin created AccentureUser and AccentureUserGroup . Now i added AccentureUser under AccentureUserGroup. Also I created the space for this organization with Name AccentureSpace. Lets come to Rights Management. As there are two level of rights i.e at Wiki level and Space level. AT Wiki Level:- I gave only view rights to AccentureUserGroup AT Space Level:- I gave only view rights to AccentureUserGroup for AccentureSpace Now when i log in with AccentureUser credentials, i can see AccentureSpace space on a page just after log in but i am not able to search any content(space or page) for this AccentureSpace . Not Getting Why? Do i need to give any other Right too for search? I would be grateful if somebody can provide some insight about above issues on right management.Already I have gone thru below links but did not get through the issues http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement right management http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Access+Rights access and rights *ISSUE2:-*.As a part of single sign on process of XWiki with my webapplication i am creating empty user with API context.getWiki().createEmptyUser. But that user is getting added to group XWikiAllGroup <http://localhost:8888/myxwiki/bin/view/XWiki/XWikiAllGroup> automatically. I want to add this user to a to a different group say AccentureUserGroup instead of XWikiAllGroup<http://localhost:8888/myxwiki/bin/view/XWiki/XWikiAllGroup>. i am not getting where should i make the change for this. Posted issue 1 on XwikiUser group also but has not got any reply yet. Looking for quick reply.Thanks in advance.

13 years, 1 month

[xwiki-devs] [Vote][Proposal] New Skin/ColorTheme Improvements for XE 3.4

by Ecaterina Moraru (Valica)

Hi, Ludovic suggested we should refresh the Default Color Theme for XE 3.4 with something new. Since (and long before) we dropped support for IE6 and IE7 (XE 3.2) I wanted to add some CSS3 enhancement to our default skin: shadows, gradients, round corners, etc. So this is a good time to make a proposal that integrates some CSS3 (gradients on menus, panels, tabs, buttons, forms; text-shadows; box-shadows; border-radius;) and a new ColorTheme into Colibri skin: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/34Proposal There are 3 directions that can be voted for this proposal: *Var A:* Integrate the proposed Skin improvements and the new ColorTheme into platform Demo at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WebHome *Var B: *Don't integrate anything in the 3.4 timeframe and wait for a new complete skin in 4.x = Current skin + default ColorTheme (no changes) Demo at http://incubator.myxwiki.org/xwiki/bin/view/Drafts/WebHome *Var C:* Integrate just the new proposed ColorTheme that will replace the current DefaultColorTheme Demo at http://incubator.myxwiki.org/xwiki/bin/view/Standards/WebHome *Important remarks when making a decision:* *Var B* and *Var C *does not involve any changes, problems or advantages from the current Colibri skin. Advantages for *Var A*: - Tested on IE7, IE8, IE9, Opera 11, Chrome 16, Firefox 8, Safari 5 and works beautifully. - Uses CSS3 declarations that makes the skin more nice (gradients, round corners, shades, etc.) Problems for *Var A*: - The existing ColorThemes (from the ColorThemes space and extensions.xwiki.org) will become deprecated for XE 3.4 since the new skin needs shades for the gradients (this means the existing ColorThemes variables will be either used in ways they were not intended or they will not have all the variables declared). See my previous mail about "[Discussion] Problematic ColorTheme extensibility"<http://xwiki.markmail.org/thread/ex6fgou6fl6vjwfr> - The CSS will become even more invalid (right now we have a -moz-border-radius and a word-wrap non valid declarations), but the new code contains 154 declarations for the gradients (covering -moz-linear-gradient, -webkit-gradient, -webkit-linear-gradient, -o-linear-gradient, -ms-linear-gradient, linear-gradient and filter: progid:DXImageTransform.Microsoft.gradient proprietary declarations). The invalidity comes because the proprietary declarations are not yet W3C standard (and will not ever be a standard). The proposed standard W3C declaration (linear-gradient) is not yet supported consistently and correctly by browsers, but when it will become standard we can remove all the other proprietary declarations. Please cast your vote. Thanks, Caty

13 years, 1 month

[xwiki-devs] [VOTE] Create new xwiki-platform-messagestream-api and xwiki-platform-messagestream-ui modules

by Vincent Massol

Hi devs, Right now the Message Stream feature is split in several places: * xwiki-platform-messagestream/ for the API * xwiki-platform-user/xwiki-platform-user-ui for the Network tab of the user profile (XWikiUserNetworkSheet.xml) * xwiki-enterprise-ui/, in : ** Activity.xml which contains both the AS and the UI to post user messages ** MessageStreamConfig.xml: the admin page for message stream My proposal is to have instead: xwiki-platform-messagestream/ |_ xwiki-platform-messagestream-api/ |_ xwiki-platform-messagestream-ui/ Where xwiki-platform-messagestream-ui/ will contain: * XWikiUserNetworkSheet.xml as is (moved from xwiki-platform-user/xwiki-platform-user-ui) * MessageStreamConfig.xml as is (moved from xwiki-enterprise-ui/) * Creation of a new page (we need to find a name for it), for example: Main.MessageStream, which will contain the UI to post user messages and which will be included from Main.Activity Here's my +1 If you can think of a better split for Activity.xml please put it forward. Thanks -Vincent

13 years, 1 month

[xwiki-devs] [Proposal] Use the XWiki.org JIRA project more

by Vincent Massol

(I sent this mail once but it didn't make it on the list apparently so resending) Hi devs, I'd like to propose that we use the XWiki.org JIRA project more: http://jira.xwiki.org/browse/XWIKIORG The idea is to create issues in it whenever we see stuff to improve on xwiki.org. I'm also proposing to do the following actions: * Modify it in JIRA so that this project doesn't have any Affects and Fix for fields. The idea is to simple have a list of issues and no releases. * Add some documentation on the contribution page on xwiki.org to explain that creating jira issues for stuff to improve on xwiki.org is a way to contribute too * Send an email to the users list asking people to create jira issues for stuff to improve on xwiki.org * Modify the xwiki.org feedback form on xwiki.org to ask users to create jira issues for stuff they'd like to see improved * Move documentation located in JIRA Platform project (and possibly others) to the XWiki.org JIRA project Are you ok about this? Once this is all done I'll send another email to propose to start again the Doc Days (say one per month). Thanks -Vincent

13 years, 1 month

Re: [xwiki-devs] How to use WikiWords?

by Hamster

I still can't figure out how to use WikiWords. I have searched with Google on "XWiki +WikiWords", but nothing relevant came up. I have searched the XWiki-site for documentation on how to use WikiWords, but can't find any docs. Does anyone have a clue for me? Thanks! -- View this message in context: http://xwiki.475771.n2.nabble.com/How-to-use-WikiWords-tp7070568p7077791.ht… Sent from the XWiki- Dev mailing list archive at Nabble.com.

13 years, 1 month

[xwiki-devs] [VOTE] Create new User Application in platfom (and refactor Admin App)

by Vincent Massol

Hi Devs, Right now the Administration Application includes user profiles pages. I'd like to propose to move them to a new user application in platform: - in xwiki-platform-user/xwiki-platform-user-ui (the reason for this directory structure is because in the future we'll probably have an -api module for User API) - or directly in xwiki-platform-user/ FTM and refactor later on when we have the need for a user -api module The rationale for moving the user profile pages out of the Administration app is the following: * IMO we need to make the Admin app only contain technical pages making up the Admin page (i.e. http://localhost:8080/xwiki/bin/admin/XWiki/XWikiPreferences + the technical pages like ConfigurableClass, etc). * We should move specific admin pages to the extensions that bring them. For example WYSIWYG admin pages should be in the wysiwyg application and not in the administration app. * This will allow us to better document each feature. Right now the user has to know that he has to go to the Admin app to find documentation about user profile (which is missing btw ;)), wysiwyg administration, etc. More specifically here are the pages I'd like to move out in XE 3.4M1: * XWikiUserSheet * XWikiUserProfileSheet * XWikiUserPreferencesSheet * XWikiUserNetworkSheet Here's my +1 Thanks -Vincent

13 years, 1 month

[xwiki-devs] [Discussion] Problematic ColorTheme extensibility

by Ecaterina Moraru (Valica)

Hi, Since we introduces ColorThemes in XE 2.0 we've used them constantly, being a great improvement for the cases when we wanted to rapidly change the color variables used. The problem with the ColorThemes is that they contain a limited number of variables. There are places in Colibri where we've recycled and used variables that were not intended to be used there, for example: - Administration's vertical-menu is using $theme.panelCollapsedBackgroundColor (which was intended for the collapsed state of the panels); - Suggest search results is using for it's .resultContainer also $theme.panelCollapsedBackgroundColor; - etc. Also there are some variables in the ColorThemes like $theme.textPrimaryColor and $theme.textSecondaryColor or even $theme.backgroundSecondaryColor that are used quite randomly in the code (all being shades of gray in the default theme). Not knowing exactly what is the purpose and usage of a color is very easy when you create a ColorTheme to chose colors that in practice will not provide enough contrast or that will not look very nice together. Since their release, we've added just 6 new variables (2 for the "Add" menu and 4 for the notifications colors: warning, error, success and info). One of the reason behind not adding new colors was not to confuse the user with a wide range of color variations. The colortheme wizard was great at making it easy for the user to change the 36 variables, but having 50+ variables to set could be a difficult/complex task even when using a Wizard. Although when we created ColorThemes we had in mind that they will be skin independent I don't know if in practice this will be still valid. When we're going to create a new skin for XE it will have a different layout, a different semantic of the variables names and a different color pool need. These needs are not mappable on what we currently have. So I think the ColorThemes should be skin dependent and also version dependent in order to assure that is gonna look the way it was originally intended to look. For example I want to add some CSS3 gradients for the 3.4 Colibri skin, but I don't have enough variables to specify the gradient shades. To solve that I've used non semantically variables combinations like: background-image: -moz-linear-gradient(top, $theme.linkColor 0%, $theme.buttonPrimaryBackgroundColor 100%); background-image: -moz-linear-gradient(top, $theme.pageContentBackgroundColor 0%, $theme.buttonSecondaryBackgroundColor 100%); Even though the combination will work for the ColorTheme defined specially for XE 3.4, this means the other existing ColorThemes will be used in a way they were not designed for (like ColorThemes.Bordo theme, etc.) thus not being as good looking as before when applied on the new skin. The same use case will be for any other skin that we will create for the XE 4.x. IMO you can't assume that any defined colortheme will work "graciously" independent of the skin applied and version used. (they will work but the color mix will be random). So another solution would be add more colors to the ColorTheme. For variation of Colibri this will work, but for a new skin (that maybe will not have 2 sets of menus, or will not have 2 separate colors for the background and the content) all the semantic behind the variables naming will fail. We will end up with variables inside the colortheme that may never be used inside the new skin code and I don't even imagine how the ColorTheme Wizard would look like (a nice idea would be to adjust itself dynamically dependent of the enabled skin). Also I want to know what is your opinion regarding adding new variables. What is the backward compatibility strategy for that? Right now, we have a fallback ColorTheme that provides fallback colors in case the ColorTheme doesn't have those colors set. But this does not assure that installing an "old" red colortheme will look nice with the fallback blue colors. We are not telling the user anywhere that there are missing colors in the installed colortheme and also in the wizard is hard to know what colors are defined and what are the fallback ones (if you know what colors are missing than you can manual define them and you don't need to cover all wizard dialogs in order to find the inconsistencies). So IMO the only solution is to have ColorThemes designed dependent of a skin and a version, with the possibility to let the user manually enhance and reuse old colortheme to work on the new versions. Maybe you have other solutions. Thanks, Caty

13 years, 1 month

[xwiki-devs] [Announcement] XWiki Enterprise 3.3 and XWiki Enterprise Manager 3.3 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.3. Following the goals established for the 3.x cycle, XWiki Enterprise 3.3 delivers the first usable but experimental versions of App Within Minutes and Extension Manager features. The highlights of this release are: * Experimental "App Within Minutes" feature * Improved Extension Manager * Automatic external link checker * Better support for exporting CJK documents as PDF * LDAP user membership improvements * Attachment handling improvements * Debian packages for installing XWiki See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise33 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 1 month

[xwiki-devs] [Proposal] Community-sourcing of our compatibility grid

by Vincent Massol

Hi devs, Here's something I'd love to see: The idea is the following: * Allow end users to install the extension and run the tests on their current XWiki Enterprise instance * At the end of the test make the extension publish the result by POSTing the result to a xwiki.org URL. The results should include: ** XE version ** DB version ** DB driver version ** Browser version ** Console logs ** Screenshots taken * Display test results on several places of xwiki.org: ** On a general compatibility page ** On the Installation page for specific Servlet Containers and Databases Note that we need to improve a bit the test suite so that: * All tests create data in a Test space * If a test requires a default page of XE we need to verify it contains what we need before the test starts and if not then mark the test as skipped instead of failing it * Tests work independently of what data already exists in the wiki I've entered it as a jira here: http://jira.xwiki.org/jira/browse/XE-1064 WDYT? Thanks -Vincent

13 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs