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

[xwiki-devs] [Investigation] SOLR integration

by Fabio Mancinelli

Hi everybody, for the 3.2 release cycle I said that I was going to investigate a bit the SOLR search engine and how to use/integrate it in the current platform. I wrote a document that you can find here: http://dev.xwiki.org/xwiki/bin/view/Design/SOLRIntegration about some of the things I looked at. There is a lot of room for discussion/improvement but I think the document is already a good starting point. Feedback is welcome. Thanks, Fabio

14 years

2
3
0 0

[xwiki-devs] [PROPOSAL] Introduce a work directory concept in the Container API

by Thomas Mortagne

Hi devs, Right now there is no way for a component to know where is the standard work directory (the one used for Lucene or filesystem attachments for example) so I would like to add an API to access it. That said I propose to add a File getWorkDirectory() in org.xwiki.container.ApplicationContext which will use XWiki#getWorkDirectory() behind the scene probably for now. WDYT ? -- Thomas Mortagne

14 years

5
20
0 0

[xwiki-devs] [Proposal] Global versioning brainstorming

by Vincent Massol

Hi devs, I'd like to brainstorm about the idea of having global versioning in XE. First here is a use case: * I have a given state in my wiki with pages in different versions * I add some pages or make modifications to existing pages * I want to go back to the previous state A good use case could be for example to return to a state before one or several applications have been installed. Proposed solution ============== * Store a global version number in the DB. Let's call it VERSION * Whenever a doc is modified, use VERSION + 1 as the new doc version * When we rollback (to say version OLDVERSION) do a query on all docs in the wiki having a version > OLDVERSION and for each of them rollback to their last version <= OLDVERSION * Write a migrator that runs the whole wiki history by looking at all versions of all docs (map in memory) and recompute the new version starting a VERSION = 1 and incrementing. * We would also need to modify the XAR importer so that importing a XAR with an older versioning scheme will work. BTW knowing that it's an old scheme is relatively easy since all old versions have a dot in their name. More notes: * This would also allow us to rollback before a given date * If we wanted we could easily add the notion of Tags later on, i.e. to associate a name with a VERSION * I've been thinking about this in the context of the new model but it's probably easier to implement it first with the old model * JRCS uses the format X.Y for versions but we could decide to only use the major, i.e always have versions of the form X.0 * In order to continue to support minor edits we would need a way to save that information. One solution is to use the minor to signify a minor edit, for ex: X.1 would mean that X is a minor. Another, probably better solution would be to store that information in the DB in the xwikircs table WDYT? Do you see any drawback of using a global versioning scheme? Do you think this is doable or too much work? Is there anything Git can tell us re managing versions that would be useful to this discussion? Thanks -Vincent

14 years

3
3
0 0

[xwiki-devs] Usability feedback on first time usage for setting a logo

by Vincent Massol

Hi devs, I've just installed a new wiki with someone (an xwiki newbie) and realized that we have some usability issues. I'm listing just one below to start with. Usability issue #1: Color theme usage Story: * A user wants to change the logo * First he has to know it's done in the Color theme but let's imagine that this is fine… (although it's not since Color theme means changing colors, not the logo…) * He click on "customize" for the Color Theme then realizes that he wants his own color theme (for ex because he doesn't want that a future upgrade overwrites his theme) * He clicks on manager color themes * He sees the "create new color theme" and use it. However he finds that the new color theme isn't the same as the color theme he wants to use as the basis for the new color theme (btw the new color theme should be the default color theme IMO and not a different one as it is now). * Then he's stuck because the doesn't offer the possibility to copy an existing theme * Imagine that he understands that he can go a color theme page and click the copy action… * He goes there clicks copy, he finds that he wants to copy in a new space but he cannot (this is fixed in 3.2 I think so cool). He copies in the new space. * Then he edits the new color theme, finds the way to set the logo * He sees a field where he has to enter information and doesn't see how to upload his logo. Reading more carefully the text he understand that he has to cancel the edit, go to the attachment tab, upload the logo, edit again, edit the header again and there he's stuck again because he doesn't remember the name of his logo. So he has to do it all again this time copy pasting his logo name * Then he saves his modifications * .. and realizes that nothing is happening: the displayed theme is still the same as before. He hits refresh (because he's a clever guy!) and finds it doesn't help * Then someone points to him that he has to go back to the admin, click on presentation and sets the color theme to use to be his new color theme. * So he does this and finds that his new color theme doesn't appear in the list but OTOH there are 2 color themes with the same name * Then someone mentions to him that it's because he hasn't changed the title of this copied page... Ideas for improving this experience: * In the Admin>L&F>Presentation screen, next to "customize", add a new button "Create new colortheme". * In the new color theme page screen, add the possibility to copy from an existing theme *AND* that sets the new title! * In color theme edit mode, add the capability to select the logo using the widget used in the user profile to select/upload images * When saving the new color theme, go back automatically to the admin page from where the user clicked on "create new colortheme" and set the newly created theme as the selected them * The user press save and he's done WDYT? In addition to all this we should probably rename Color Theme into something else to make it more clear that it's not just about colors (or move the logo out). Also it's probably not very clear what's the difference between color themes and skins. Note: I really did all those steps mentioned above in the story and it was a real pain from a newbie user POV. Thanks -Vincent

14 years

4
4
0 0

Re: [xwiki-devs] 5

by dennis.coonich＠comcast.net

Visit this site. I hope it will help you to rid of shyness.. http://www.endrik.com/com.page.php?jfuGIS=50up9

14 years

1
0
0 0

[xwiki-devs] (no subject)

by dennis.coonich＠comcast.net

Life is not boring!!!. http://www.kempsu-huolto.fi/com.page.php?iaolid=25o0

14 years

1
0
0 0

[xwiki-devs] Blockers for XE 3.2M3 and XE 3.2 release?

by Vincent Massol

Hi devs, Can we list blocker issues in this thread? I can think of the following: - http://jira.xwiki.org/jira/browse/XWIKI-6925: ActivityStream nolonger works if upgrading a legacy system. - http://jira.xwiki.org/jira/browse/XRENDERING-46: Upgrade to HTML Cleaner 2.2 This one is a blocker because we want to put XE 3.2M3 and XE 3.2 final on Maven Central for Commons and Rendering and we're using HTML Cleaner 2.1 which isn't located on Central but version 2.2 is. An alternative is to push version 2.1 of HTML Cleaner on Central. - http://jira.xwiki.org/jira/browse/XWIKI-6939: Can't find any core extension when executed in a folder with white space - upgrade myxwiki to XE 3.3M3 There are also 47 issues marked "Critical" in JIRA… We need to review them and verify if they're really critical. Please add more if you know blocker issues. Also, we need volunteers to work on them! Thanks -Vincent

14 years

4
4
0 0

Re: [xwiki-devs] 8

by dennis.coonich＠comcast.net

Cool! I want you to visit this site too!. http://mpbarnehage.no/com.page.php?jcaolid=60w4

14 years

1
0
0 0

[xwiki-devs] Unable to build xwiki code

by Karamjit Singh

Hi Team, I am unable to build xwiki from source its source code. I am getting below error message while executing Maven goal:- *[ERROR] Failed to execute goal on project xwiki-platform-rest-server: Could not resolve dependencies for project org.xwiki.platform:xwiki-platform-rest-server:jar:3.2-SNAPSHOT: Could not find artifact org.jboss.cache:jbosscache-core:jar:3.2.5.GA in xwiki-externals (http://maven.xwiki.org/externals) -> [Help 1]* Looks like jboss cache core lib does not exist on maven external repository * * *Please help me. Its very urgent as I am stuck and unable to deploy new changes to our server.* * * *I shall be very thankful.* * * *Thanks* *Karamjit.*

14 years

2
2
0 0

[xwiki-devs] [Proposal] Naming rules for translation resource properties + deprecated properties

by Vincent Massol

Hi devs, I see that in ApplicationResources.properties we now have some wrongly named properties. For example for the scheduler I find properties of the type xe.scheduler.* but the scheduler is now in the platform. There are also resources named core.* Thus I'd like to propose a simple rule: <short top level projet name>.<short module name>.<propertyName> where: <short top level projet name> = top level projet name without the "xwiki-" prefix, for example: commons, rendering, platform, enterprise, manager, etc <short module name> = the name of the maven module without the <short top level project name> prefix, for example: oldcore, scheduler, activitystream, etc <propertyName> = the name of the property using camel case, ex: updateJobClassCommitComment For example the property core.importer.package.version would be renamed in platform.web.packageVersion The only issue is when we rename modules we need to rename the properties for that module but I don't see any way out of this if we want to have expressive property names. But at least it's an easy and mechanic change I also propose to introduce a different resource property file that will hold deprecated properties and that we can put in the xwiki-platform-legacy module. We could call it DeprecatedApplicationResources*.properties Of course in the future each module should be able to contribute both resource properties (but they would use the same naming scheme!). Even though this is not the topic of this mail this is how I'd implement this in the future: * Implement a TranslationPropertiesConfigurationSource that is initialized by reading all property files found in the classloader under META-INF/translations.properties and META-INF/translations-deprecated.properties. This component would listen to observation events so that when a new jar is installed by the extension manager it can check if it provides some translations and add them. * Have a Translation Manager component which is the main API to be used by other modules wishing to get translations. This manager would use the TranslationPropertiesConfigurationSource component. WDYT? Thanks -Vincent

14 years

2
1
0 0

[xwiki-devs] Build improvement actions

by Vincent Massol

Hi devs, We've had a meeting with Marius, Thomas and myself and we brainstormed about what to improve in our builds and we've come up with the following actions: 1- create twitter account for xwiki.org and tweet about releases (basically tweet links to blog posts). Category: Release Process improvement. Who: Vincent Massol 2- Refactor distribution for installers to share more. Who: Thomas Mortagne 3- Check latest version of izpack. Who: Marius 4- Configure nexus to cache other repos → speed improvement. Who: Vincent Massol 5- Add definition xwiki remote repo to top level repos in github. Who: Vincent Massol 6- Define a location for passwords. Who: Thomas Mortagne 7- Publish with commons and rendering on central repo. Who: ? I've started to work on items 4 and 5 and will do 1 soon. Also I've analyzed 7 and there's only 1 external reps not available in the Maven Central Repo: <groupId>org.reflections</groupId> <artifactId>reflections</artifactId> It should be pretty easy to submit it using https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+… To publish our artifacts to the central repo I propose to use Sonatype OSS service, see https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+… Thanks -Vincent

14 years

2
18
0 0

[xwiki-devs] DBStringList property and checkbox functionality example.

by Karel Gardas

Hello, is there any example which shows usage of DBStringList property together with support for selecting multiple values of this property (by for example using checkboxes) and also showing how such values are later obtained from the property? I'm asking since I'm not sure if property is able to kind of change into property list (probably) and also I'm fighting with this and I'm still not able to obtain more than one value from returned property object. Thanks! Karel

14 years

2
4
0 0

[xwiki-devs] [VOTE] Remove migrated code from svn.xwiki.org

by Vincent Massol

Hi devs, I'd like that we remove code that we've moved to github from svn.xwiki.org as it's misleading for people arriving there. Secifically: - commons - enterprise - manager - platform - rendering - watch - xeclipse - xoffice Here's my +1 Thanks -Vincent

14 years

9
12
0 0

[xwiki-devs] [VOTE] New thumbnails module

by Jerome Velociter

Hello again, I would like to introduce a new module in platform : xwiki-platform-thumbnails. The idea of the module is to provide means of handling thumbnails in XWiki. Right now the main purpose is to expose APIs to retrieve thumbnails URLs for images stored as attachments. This module first use will be to generate thumbnails of user avatars. In this scenario, it will also introduce a performance improvement compared to today's way of computing avatar URLS, since the module caches both the property values (the fact that user X has set an avatar Z.png) and the thumbnail URL for this avatar. I've already pushed it in a feature branch/. You can check in particular https://github.com/xwiki/xwiki-platform/commit/3f5aa1e24ba00fcc939b73b8f9ba… and all commits in the branch at https://github.com/xwiki/xwiki-platform/commits/feature-thumbnails Let me know what you think. -- Jerome Velociter Winesquare http://www.winesquare.net/

14 years

3
7
0 0

[xwiki-devs] Include macro behavior with respect to sheets

by Marius Dumitru Florea

Hi devs, I think we all agree that the result of {{include document="Space.Page" context="new" /}} must be similar with what we see when we view Space.Page. Now, suppose Space.Page has an object of type Space.Class and Space.Class has a sheet named Space.Sheet. If the sheet is applied to Space.Page using the include macro in the content field like this: {{include document="Space.Sheet" /}} then the result of the first include macro is as expected. If we don't use the content field to apply the sheet (which is the case of the sheet management module I'm working on) then the result of the first include macro is not anymore as expected. The reason is that rendering the content of Space.Page (could be empty) is different than rendering the Space.Sheet in the context of Space.Page. I could modify the include macro to use the sheet module when context=new, but I think it's better to hide the sheet module from the include macro, e.g. by modifying the getRenderedContent() method to use the sheet module instead. WDYT? Thanks, Marius

14 years

2
1
0 0

[xwiki-devs] velocity script render a List<Block>

by Mark Wallace

I have a macro (implemented in Java) with this interface: public List<Block> execute(InferenceParameter parameters, String content, MacroTransformationContext context) ; I want to call this macro from within a velocity script. When I do, it returns a List<Block>. How do I get the velocity script to render the List<Block> properly? -- Mark Wallace Principal Engineer, Semantic Applications Modus Operandi, Melbourne, FL, USA

14 years

3
6
0 0

[xwiki-devs] [Proposal] Stop Jenkins notifications for 3.1 branch

by Vincent Massol

Hi devs, I'd like to stop sending jenkins emails for the 3.1 builds for the following reason: * We don't have enough time to fix the tests on that branch as we did for the master branch * Almost all (if not all) emails are false positives * We're stabilizing the build and we're trying to reduce all false positive emails and this is not helping us go in the right direction * This branch is supposed to go away in not too long * We don't do many commits on that branch (and we shouldn't) So the idea is that we don't receive emails anymore for that branch **but** it'll be up to the Release Manager when we release this branch to review the failing tests with the other devs when it's time to release it to ensure that we don't have real test failures. WDYT? Thanks -Vincent

14 years

4
7
0 0

[xwiki-devs] [VOTE] Introduce ActionExecutingEvent event

by Thomas Mortagne

Hi devs, I started to move (very) old notification system to legacy but I'm stuck because there is one thing still not supported by new observation system: event sent before executing an action. So here it is: I propose to add it with the name ActionExecutingEvent in the bridge. At the same time I would also like to come with ActionExecutedEvent in the bridge to replace the ActionExecuteEvent which is currently in observation API (and that should never have been there). WDYT ? here is my +1 -- Thomas Mortagne

14 years

3
11
0 0

[xwiki-devs] Determine the sheet on create

by Marius Dumitru Florea

Hi devs, I'm working on a sheet management module (see https://github.com/xwiki/xwiki-platform/compare/feature-sheets ) and I have an issue. My component returns the list of sheets "registered" for a document or a class. The component methods take document references as input. The consequence is that my component always "queries" the saved document (taken from the database/cache). I have modified the edit.vm template to check if there is a sheet available for the current document. It works great with one exception: when you create a document (e.g. when you create a blog post). The problem is this: although the information required to detect the sheet is present on the current/context document (e.g. it has an object of type BlogPostClass) my component fails to access this information because the document wasn't saved, it doesn't even exist. The reason I used document references on my component interface is obvious: I didn't want to depend on the core (at least not the interface, because the implementation does right now). The solution to keep the current component interface is to explicitly specify the sheet on the edit URL (only) for the create form. For instance, replace: /edit/Blog/MyNewBlogPost?template=Blog.BlogPostTemplate with: /edit/Blog/MyNewBlogPost?template=Blog.BlogPostTemplate&sheet=Blog.BlogPostSheet but I think it's a bit too much to ask from the application developers. Another solution, suggested by Thomas Mortagne, is to: * change the component interface to use DocumentModelBridge (which is implemented by XWikiDocument) instead of DocumentReference (=> keep the interface independent of old core) * change the script service to use api.Document instead of DocumentReference, and to extract the XWikiDocument from it through reflection, to avoid programming rights issues. It's not a clean solution but it is better from the application developers' point of view. WDYT? Any alternatives? Thanks, Marius

14 years

1
0
0 0

[xwiki-devs] [VOTE] Add hasWikiAdminRights() method to XWikiRightService and api.Api to avoid confusion and security issues

by Eduard Moraru

Hi Devs, The current hasAdminRights(XWikiContext) method checks if the current user has admin rights on the current wiki or on the current space. However, the javadoc currently available (and also general knowledge) did not include the "or current space" part and the method ended up being used in places where admin right for the current space was not enough to allow performing certain actions (ex. wiki manager plugin, etc.) While it is still useful to check for admin right on wiki or space, it is more useful to have a method that checks admin right only for the wiki (stronger admin). Using the current api, it's cumbersome to have to specify "XWiki.XWikiPreferences" each time so I propose adding a new method to handle this: /** * Checks that the current user in the context (the currently authenticated user) has administration rights on the * current wiki, regardless of any space admin rights that might also be available. * * @param context the xwiki context of this request * @return {@code true} if the current user in the context has the {@code admin} right, {@code false} otherwise */ public boolean hasWikiAdminRights(XWikiContext context); And, obviously, the fixed javadoc for hasAdminRights(XWikiContext). You can check out the pull request at https://github.com/xwiki/xwiki-platform/pull/22 Here's my +1 Thanks, Eduard P.S.: Existing code using the hasAdminRights(XWikiContext) method will have to be adjusted accordingly.

14 years

5
4
0 0

[xwiki-devs] Performance of synchronization in XWiki.

by Caleb James DeLisle

I ran some testing by injecting printline statements after the beginning of each synchronization block in all of the xwiki codebase and then ran some tests. xwiki webstandards test: pages loaded: 925 synchronization blocks entered: 2,512,524 synchronizations per page: 2,716 Excluding the first page load on start-up, these are the total synchronizations from running the webstandards tests. Note that they don't add up to exactly 2,512,524 because some were spoiled when 2 threads tried to write to stdout simultaneously. Total Percent Location 1651401 65.73% XWikiCacheStore.java:115 316411 12.59% EmbeddableComponentManager.java:352 142094 5.66% XWikiContext.java:260 103028 4.10% XWiki.java:5380 58151 2.31% XWikiContext.java:282 54891 2.18% XWiki.java:5455 46324 1.84% DefaultVelocityFactory.java:72 46320 1.84% DefaultVelocityFactory.java:82 29447 1.17% EmbeddableComponentManager.java:138 15010 0.60% DefaultBeanManager.java:204 14595 0.58% DefaultXWikiRenderingEngine.java:239 10933 0.44% URIClassLoader.java:438 3812 0.15% XWiki.java:5406 3262 0.13% DefaultVelocityEngine.java:227 3262 0.13% DefaultVelocityEngine.java:245 2867 0.11% XWikiNotificationManager.java:130 1941 0.08% XWikiGroupServiceImpl.java:798 958 0.04% XWikiConfigurationService.java:50 958 0.04% XWikiNotificationManager.java:254 958 0.04% XWikiNotificationManager.java:265 957 0.04% XWikiCacheStore.java:704 951 0.04% XWikiNotificationManager.java:230 949 0.04% XWikiNotificationManager.java:241 917 0.04% XWikiNotificationManager.java:219 852 0.03% XWikiStatsServiceImpl.java:182 371 0.01% XWikiDocumentQueue.java:88 351 0.01% XWikiDocumentQueue.java:55 142 0.01% XWikiDocumentQueue.java:69 112 0.00% XWikiDocumentQueue.java:98 66 0.00% AdminAction.java:57 24 0.00% RightsManager.java:164 15 0.00% EditAction.java:59 UI tests were also run to give a more well rounded view of what real traffic might look like: 1666727 57.98% XWikiCacheStore.java:115 463369 16.12% EmbeddableComponentManager.java:352 234027 8.14% XWiki.java:5380 175972 6.12% XWikiContext.java:260 70156 2.44% XWikiContext.java:282 65952 2.29% XWiki.java:5455 43553 1.52% DefaultVelocityFactory.java:72 43552 1.52% DefaultVelocityFactory.java:82 33512 1.17% EmbeddableComponentManager.java:138 13451 0.47% DefaultBeanManager.java:204 9650 0.34% DefaultXWikiRenderingEngine.java:239 9450 0.33% XWikiNotificationManager.java:130 5176 0.18% XWikiGroupServiceImpl.java:798 5019 0.17% URIClassLoader.java:438 3965 0.14% XWiki.java:5406 2850 0.10% DefaultVelocityEngine.java:227 2850 0.10% DefaultVelocityEngine.java:245 2717 0.09% XWikiConfigurationService.java:50 2694 0.09% XWikiCacheStore.java:704 2624 0.09% XWikiNotificationManager.java:219 2624 0.09% XWikiNotificationManager.java:230 2624 0.09% XWikiNotificationManager.java:241 2590 0.09% XWikiNotificationManager.java:254 2590 0.09% XWikiNotificationManager.java:265 749 0.03% XWikiDocumentQueue.java:69 718 0.02% XWikiStatsServiceImpl.java:182 554 0.02% XWikiDocumentQueue.java:88 550 0.02% EmbeddableComponentManager.java:201 476 0.02% XWikiDocumentQueue.java:55 406 0.01% XWikiHibernateVersioningStore.java:142 403 0.01% XWikiNotificationManager.java:140 403 0.01% XWikiNotificationManager.java:155 403 0.01% XWikiNotificationManager.java:167 403 0.01% XWikiNotificationManager.java:181 403 0.01% XWikiNotificationManager.java:194 403 0.01% XWikiNotificationManager.java:206 282 0.01% XWikiDocumentQueue.java:98 209 0.01% EditAction.java:59 101 0.00% RightsManager.java:164 81 0.00% AdminAction.java:57 61 0.00% EmbeddableComponentManager.java:289 52 0.00% EmbeddableComponentManager.java:256 44 0.00% LucenePlugin.java:656 35 0.00% InlineAction.java:39 23 0.00% DefaultCSRFToken.java:130 19 0.00% MutableHttpServletRequestFactory.java:43 15 0.00% AbstractGenericComponentManager.java:93 13 0.00% LucenePlugin.java:450 5 0.00% XWikiNotificationManager.java:56 2 0.00% MacroRepository.java:65 2 0.00% XWiki.java:408 1 0.00% ActivityStreamCleaner.java:89 1 0.00% EmbeddableComponentManager.java:163 1 0.00% EmbeddableComponentManager.java:269 1 0.00% RightsManagerListener.java:85 1 0.00% SchedulerPlugin.java:561 1 0.00% StackingComponentEventManager.java:69 1 0.00% XWikiGroupServiceImpl.java:150 1 0.00% XWikiGroupServiceImpl.java:162 1 0.00% XWikiGroupServiceImpl.java:180 1 0.00% XWikiHibernateBaseStore.java:142 1 0.00% XWikiHibernateBaseStore.java:265 1 0.00% XWikiHibernateBaseStore.java:557 1 0.00% XWiki.java:5493 1 0.00% XWiki.java:5515 These numbers seem to be quite conclusive that XWikiCacheStore.java:115 is the lowest hanging fruit in the synchronization field. An examination of XWikiCacheStore reveals that the "per load" synchronization should be avoidable if it is not lazy initialized and is flushed differently. Is synchronization the best place to attack for performance gains? Synchronization cost is difficult to measure because it varies based on number of processor cores and processor sockets. In the worst case, the caches in multiple cores on multiple processor sockets all need to be flushed and this would be the case with high contention mutexes. As a matter of good practice, I think we should reduce the amount of synchronization as much as is reasonable. Caleb

14 years

3
2
0 0

[xwiki-devs] [Discussion] Generate and publish sources for snapshot builds in the CI

by Eduard Moraru

Hi devs, I was wondering why we don`t generate source artefacts for snapshots, just like we do for final versions? While I do agree that final versions are the important ones, it's often very annoying to have to manually add sources from the filesystem (assuming you have cloned locally the git repo) for all the maven modules that you want to see the code or even the javadoc or method parameter names. For final releases we don`t have that problem because Eclipse and the Maven plugin (for example) can automatically download the sources in the background providing an effortless process. However, while working with snapshots, you are nagged continuously that the sources can not be found automatically and you experience a bit of unneeded frustration :). Not only that Would it be that much of a storage penalty for the extra sources jars to accompany the snapshot builds? Would it be that much of a build time penalty for actually generating source builds for each artefact? WDYT? Thanks, Eduard

14 years

4
4
0 0

[xwiki-devs] Small widget possibly of interest : ajaxify forms in popups

by Jerome Velociter

Hi all, I've written a small Ajax widget for XWiki that magically ajaxifies a form in a modal popup. Right now I have no use for it directly in XWiki, but I though it would worth advertising it here as this might come handy at some point for the platform. It even works with multipart forms. The widget is here : https://gist.github.com/1184560 Regards, -- Jérôme Velociter Winesquare http://www.winesquare.net/

14 years

2
1
0 0

[xwiki-devs] Sheets and programming rights

by Marius Dumitru Florea

Hi devs, I need your feedback regarding two use cases: (A) /view/Space1/PageWithPR?sheet=Space2.SheetWithoutPR Drop permissions when rendering the sheet, right? (B) /view/Space1/PageWithoutPR?sheet=Space2.SheetWithPR How often did you write class/document sheets requiring programming rights? I don't think it's possible/safe to keep PageWithoutPR as context document and render SheetWithPR using programming rights. WDYT? Thanks, Marius

14 years

5
9
0 0

[xwiki-devs] How to check if a specific document has programming rights?

by Marius Dumitru Florea

Hi devs, I tried to use: $someDoc.hasProgrammingRights() but unfortunately this method checks the current/context document, not the one on which it is called. The code is in com.xpn.xwiki.api.Api: /** * Check if the current document has programming rights, meaning that it was last saved by a user with the * programming right globally granted. * * @return <tt>true</tt> if the current document has the Programming right or <tt>false</tt> otherwise. */ public boolean hasProgrammingRights() { com.xpn.xwiki.XWiki xwiki = this.context.getWiki(); return xwiki.getRightService().hasProgrammingRights(this.context); } So how do you check if a specific document has programming rights? AFAICS I need to either access the rights service or change the context document, but both require programming rights.. How can I check programming rights without needing them? Thanks, Marius

14 years

5
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs