xwiki-devs June 2010

xwiki-devs@xwiki.org

34 participants
97 discussions

[xwiki-devs] [Proposal] Documentation Standard Document & Call to Vote

by Sorin Burjan

Hello. Silvia and me have created a DRAFT for XWiki.org Documentation Standard found at : http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiOrgDocumentationStandard In order to move towards the final version, we need your input on 2 issues. - For which project version we create & maintain documentation - Which skins we are going to support in the documentation (latest/all) Although, these issues were discussed in December 2009, no final result came out of them. http://markmail.org/message/ou7hgdiiwgayghku#query:+page:1+mid:ou7hgdiiwgay… 1. the project version (XE version for ex) for which the documentation is created/updated/maintained. We have several choices: a) We make the documentation only for the latest version. b) We make the documentation only for the latest version, and we export the pages at release time and make it available as a zipped HTML export so that people using the older version can refer to them. c) We make the doc work the last 2 releases. That would be 2.3 and 2.4. Note: If option b) is chosen then we need to add a step to the release process. (export for every release) 2. The skin used for documenting steps. This also includes the screenshots. Again we have several choices: a) Document only for the latest default skin. b) Document for all supported skins. Right now that would be Toucan + Colibri (not sure about Albatross, I don't think we've officially said it wasn't supported). Note: If option b) is chosen, this would mean 2 screenshots for the same feature (one for each skin) The vote content was mostly taken from the markmail link above. If you have any other suggestions regarding this draft, please reply and state your opinion. We need as much feedback as possible in order to create a solid documentation standard.

14 years, 6 months

Re: [xwiki-devs] [xwiki-notifications] r29399 - in platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src: main/java/org/xwiki/configuration/internal test/java/org/xwiki/configuration/internal

by Vincent Massol

On Jun 10, 2010, at 5:43 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-06-10 17:43:32 +0200 (Thu, 10 Jun 2010) > New Revision: 29399 > > Modified: > platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/main/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSource.java > platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java > Log: > XWIKI-5264: Cannot get the value of a property stored in the space preferences using the configuration module > Fix important regression: when using a peace of enityreference to create another one it should be cloned otherwise it's breaking the initial reference Thanks for the fix Thomas. [snip] > Modified: platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java > =================================================================== > --- platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java 2010-06-10 14:14:50 UTC (rev 29398) > +++ platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java 2010-06-10 15:43:32 UTC (rev 29399) > @@ -55,15 +55,19 @@ > ConfigurationSource source = getComponentManager().lookup(ConfigurationSource.class, "space"); > > final DocumentReference webPreferencesReference = new DocumentReference("wiki", "space", "WebPreferences"); > + final DocumentReference currentDocument = new DocumentReference("wiki", "space", "page"); > + > mockery.checking(new Expectations() {{ > allowing(bridge).getCurrentDocumentReference(); > - will(returnValue(new DocumentReference("wiki", "space", "page"))); > + will(returnValue(currentDocument)); > oneOf(bridge).getProperty(webPreferencesReference, webPreferencesReference, "key"); > will(returnValue("value")); > }}); > > String result = source.getProperty("key", String.class); > + > Assert.assertEquals("value", result); > + Assert.assertEquals(currentDocument.getName(), currentDocument.getParent().getChild().getName()); This last line is going to be very hard to remember in the future (ie why we've written that). IMO it's not the right place for this test. If you want to keep it at least it needs to be heavily commented (but this indicates IMO that it's not the right place). Thanks -Vincent

14 years, 6 months

[xwiki-devs] Proposing addition to DocumentAccessBridge

by Andreas Jonsson

Hi, Should not this method in DocumentAccessBridge: Object getProperty(String documentReference, String className, int objectNumber, String propertyName); be deprecated and replaced with a method: Object getProperty(DocumentReference documentReference, DocumentReference classReference, int objectNumber, String propertyName); Also, to be able to use it, there should be a method like: Iterable<Integer> getObjectNumbers(DocumentReference documentReference, DocumentReference classReference); With these changes, it would be possible to read the access rights objects without being depending on the core. But the rights service would still need the core for querying group memberships, checking the document creator, and checking the wiki owner. Or have I missed something? Best regards, /Andreas

14 years, 6 months

Re: [xwiki-devs] [xwiki-notifications] r29377 - in platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-include: . src/main/java/org/xwiki/rendering/internal/macro/include src/test/java/org/xwiki/rendering/internal/macro

by Vincent Massol

On Jun 9, 2010, at 6:01 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-06-09 18:01:08 +0200 (Wed, 09 Jun 2010) > New Revision: 29377 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-include/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-include/src/main/java/org/xwiki/rendering/internal/macro/include/IncludeMacro.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-include/src/test/java/org/xwiki/rendering/internal/macro/IncludeMacroTest.java > Log: > XWIKI-4115: Include macro should protect from recursive inclusion > [snip] > + > + @Test > + public void testIncludeMacroWithRecursiveInclude() throws Exception > + { > + this.mockSetup.mockery.checking(new Expectations() {{ > + oneOf(mockSetup.documentReferenceResolver).resolve("wiki:Space.Page"); > + will(returnValue(new DocumentReference("wiki", "Space", "Page"))); > + oneOf(mockSetup.documentReferenceResolver).resolve("Space.Page"); > + will(returnValue(new DocumentReference("wiki", "Space", "Page"))); > + }}); > + > + this.includeMacro.setDocumentAccessBridge(mockSetup.bridge); > + > + MacroBlock includeMacro = new MacroBlock("include", Collections.singletonMap("document", "wiki:Space.Page"), false); > + new MacroMarkerBlock("include", Collections.singletonMap("document", "Space.Page"), Collections.<Block>singletonList(includeMacro), false); > + MacroTransformationContext context = new MacroTransformationContext(); > + context.setCurrentMacroBlock(includeMacro); > + > + IncludeMacroParameters parameters = new IncludeMacroParameters(); > + parameters.setDocument("wiki:Space.Page"); > + parameters.setContext(Context.CURRENT); > + > + List<Block> blocks; > + try { > + blocks = this.includeMacro.execute(parameters, null, context); > + > + Assert.fail("The include macro did not checked the recusive inclusion"); > + } catch (MacroExecutionException e) { s/e/expected/ ? > + if (!e.getMessage().startsWith("Found recursive inclusion")) { > + throw e; I think you should do an Assert.assertTrue() instead here. Thanks -Vincent

14 years, 6 months

Re: [xwiki-devs] [xwiki-users] [Vote][Proposal] Rights Management

by Jerome Velociter

Hi Caty, all, It took me some time and thinking to figure out how the UI works and what the yellow highlight means. I'm not sure we reduced complexity, which was one of the objective of the UI redesign. If this is basic, I imagine the advanced UI will be pretty scary :) Once you understand it, the UI makes sense. The visual clue that specifiying a right to evalica forbid the same right for all group and guest is very good. Note: I have not followed the thread about this UI redesign (my look at it is "fresh", for what it worth). Jerome. ----- "Ecaterina Valica" <valicac(a)gmail.com> wrote: > Hi, > > For a while we've been discussing how the new Rights Management UI is > gonna > look like. After 5 prototype versions, we may have reached a > conclusion. > > Please take a look at: > *Prototype* > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space > *Explanations* > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/RightsProposal > > Please cast your vote if this is gonna be the final Rights > representation, > so that we may start the implementation. > my +1 > Any feedback is welcomed and we can still added improvements to this > version. > > The current version is a collaborative work done by me, Denis > Gervalle, > Raluca Stavro, Alex Busenius, Roman Muntyanu and many others > (Guillaume, > Sergiu, Vincent, Thomas). Thanks everyone for participating in the > process. > > Thanks, > Caty > > p.s: former discussion about mocking process can be seen at > [Proposal] > Rights Management UI http://markmail.org/thread/zgzufskvhe6xt6ey > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users

14 years, 6 months

[xwiki-devs] [Proposal] Rights Management UI

by Ecaterina Valica

Hi, Please give feedback for Rights Management UI Proposal. *Partial Prototype* - Wiki Level: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights2Wiki - Space Level: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights2Space - Page Level: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights2Page *Desired Interaction * - http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights2Proposal#HI… Thanks, Caty

14 years, 6 months

[xwiki-devs] [Proposal] Rights Management UI

by Ecaterina Valica

Hi, Take a look at Rights 5 http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights5Space Added: * information regarding the advanced rights (inherits, overrides) * icons built together as a whole http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/i… * representation of "advanced rights" with the same abstract icon, but with different color (no text; we can debate this) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/c… * inheritance arrow married with +/- IMGs (in case of browser problem) - collapsed: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/r… - expanded: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/r… On Fri, Jun 4, 2010 at 10:42, Denis Gervalle <dgl(a)softec.lu> wrote: > Hi Caty, > > On Thu, Jun 3, 2010 at 18:09, Ecaterina Valica <valicac(a)gmail.com> wrote: > > > Hi Denis, > > > > I want to thank you again for all the help you are giving :P > > > > This is pleasure to participate especially because you provide really good > proposals. > I would also like to see others participating, currently the discussion is > becoming to much bilateral IMO. > > > > > > Please take a look at a proposal for "V3 and my 3)" version with elements > > from Rights2 :) > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal > > and in "action" > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Space > > > Really nice job ! I really appreciate. > > > > The prototype is not reflecting the "desired" interaction: both inherited > > info and rights change appear on hover (right icon and arrow), instead of > > hover | click. > > > > I am not sure what are really your intend. I think that the big tooltips > describing the rights should be the only tooltips, and should be show on > hover only after a small timeout (like the yellow one currently). Clicking > any where on the +/- icon or v would then open the menu. > Is it what you try ? > > yes, on hover show the tooltip, on click show the menu. > > > > > That "v" needs to be an arrow like the one we use in the action menus. > > > > On Tue, Jun 1, 2010 at 19:06, Denis Gervalle <dgl(a)softec.lu> wrote: > > > > > Caty, > > > > > > Really nice and interesting post, I will try to reach that level... but > > > without visual :\ > > > > > > I really think that using the collapsed view for editing would helps > > basic > > > users to have a simplified and more easy interface to understand. We > may > > > even imagine that only "advanced user" (those marked so in their > > profile), > > > has access to the expanded view. > > > > > > I think that the collapsed view missed an additional icon that > summarize > > > the > > > rights that are not shown. This one would only be shown if there is any > > > non-defaulted additional right in action. > > > > This is a signal that extended > > > rights are in use (See it like the grey box of Windows when special > > rights > > > are setup, which is inviting to go into advanced view to know more). > This > > > one would be obviously not editable, and should probably work like the > > ... > > > or replace it ? In place of the ... . Concerning the ..., I am not > sure, > > > but > > > I would also prefer to see a textual link "advanced" in small font, and > > > only > > > visible when row is hovered. > > > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal#H… > > > Sorry to insist, but the information regarding the advanced rights is still > missing in collapsed mode. > I really would like to have a indicator that some advanced rights has been > set locally or not without having to go advanced mode. Else, you will have > to expand all rows to check that information, which is not practical. > > > > > > > > > Order of right are not significant, so I would prefer that in all view, > > > these where in the same order, with the basic right first (V/C/E/D/A/P) > > and > > > the additional right in their order of registration (hope that it will > > stay > > > constant... or we will have to find a way to keep them ordered). > > > The "right" part of each icon should be grayed if the right is > inherited > > > and > > > not grayed if the right is set locally, this improve the information > > > provided in V3. > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal#H… > > > > The problem with this icons (taken from Silk) is that there is little > > difference for View, Comment, Admin icons between the two states > > (inherited, > > locally set) - but this is something we can easily improve (by changing > the > > icons and looking for some more contrast). > > Example: This is how they look when all rights are set locally (full > color) > > > > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Propos… > > > > > > > > > I also think that the +/- (which is never grayed) could be > > > nearer to the right icon. Maybe you could use a green V and a read > "stop" > > > in > > > place of +/- ? > > > > > > > The other mockup versions (like > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space) > > used > > v/x for the allow/deny representation, and yes, I agree that they are > more > > suited than +/-. > > > > The problem is that we are using in XWiki, X to represent delete, so > having > > two xX was too much, that's why I introduced +/-. Maybe we can find > another > > solution. > > > > I think we need some polishing on the icons used. Building them > specifically > would be nice, but I do not know if you or anyone want to have a try at > that. My feeling is that the couple +/- or better v/x and the right icon > should be built together and closer to each other providing the information > as a whole and not giving the impression of two part. Using a v for > suggesting the menu is nice, could be even improved by styling some "button > like" borders on hover. > > All menus could also be improved by using the inheritance arrow married > with > +/- (or v/x) to show immediately what will be the right if inheritance is > used. > > > > > > > > > > > > Regarding the collapsed view, I see three possibilities to investigate > > for > > > allowing edition while improving readability (note that readability has > > the > > > same issue in expanded view, but it seems to be less annoying) : > > > > > > 1) use V3, but when hovering a row, use V2 on that row and allow > > drag/drop > > > (keeping V2 until drop even is hover is temporary lost). Not sure this > > will > > > be nice in practice ? see 2) > > > > > > 2) use a presentation in 4 columns, for both collapsed and expanded > view, > > > the first column behing a read-only summary like V3, and the 3 column > > being > > > an ordered V1. However, dragging from summary would be allowed. The 3 > > > detailed column could be shown only when a drag is started from > summary, > > or > > > with a global horizontal expansion button... Basic user would have > access > > > to > > > this, but not necessarily to vertical row expansion. Not sure this is > not > > > an > > > increase in complexity ? so, see 3) > > > > > > 3) use V3, and a similar interface to what we have in current right > > > management interface. Since saved are postponed (not like we have > > > currently), using this one may be both practical and could helps the > > > transition for existing user as well. With all the belts and whistle > > added > > > to clearly state changes and inheritance, this will be similar but > really > > > better than what we have. > > > > > > If we go for V3 and my 3) proposal, I also wonder if the current table > > > header is well done. I do not like it when nothing is expanded since it > > is > > > confusing, too large, and not significant. It will be even more > > unexpected > > > if you follow me on the "advance user" case, when a basic user look at > > it. > > > Maybe you could try a changing header, only expanding when there is > > > expanded > > > row, or, you could move the expanded header in each expanded row, > keeping > > a > > > simplified header at the top. > > > > > > WDYT ? > > > > > > Denis > > > > > > > > Other problem that this proposal has is the representation of "advanced > > rights". If we don't like the textual description and we want to add > icons, > > IMO we have two solutions: > > > > A) use the same abstract icon, but with different color, ex. a key or > lock > > icon with color representation ("blue" for "programming", "green" for > > "captchaComment", etc) > > - the problem here is for the people that have some kind color blindness > > and > > will not distinguish between some color tones (this is the case when we > > gonna have lots of "advanced" | non default rights) > > > > B) use the same abstract icon and with an order index (like numbers 1, 2, > > etc or characters A, B, etc) > > > > These representations are based on the fact that "advanced rights" will > be > > added by other developers and the icon will not be custom made for a > specif > > right. > > > > Why not just use the big Icons from the menu (using the inheritance arrow > married with +/- as proposed above), and directly followed by the v arrow. > All this in front of the text ? > inheritance arrow + "right" - to describe "right" as inherited allowed inheritance arrow - "right" - to describe "right" as inherited denied + "right" - to describe "right" allowed - "right" - to describe "right" denied yes - we could do that if we decide to use the textual variant. > > Using a generic icon will not improve information and detailed view of > advanced right in collapsed mode is not expected. > > It is not clearly shown on your samples, how multiple advance right would > be > shown. I think one per row is nice, or if you want to limit space, 2 or 3 > at > most, shown in columns ? > this depends on which version (textual, icons) we choose for the advanced rights (I would prefer something linear) > I also wonder is this would help or not to also extends basic rights in > advanced mode, showing the icons and the text ? > > I think this would only add duplicates and mess a bit the meaning of "advanced" by combining them with "regular". > > > > > > Another thing we need to consider for this proposal is how the filtering > is > > gonna be made. > > > > Good point. Here is some proposal for each column: > > 1) a dropdown list proposing local (default), global or both ? > I would prefer rights separation depending on the location: - if you want to see global rights - go to global; - if you want to see wiki rights - go to wiki, etc. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Proposal#HN… Why would you like to see both local and global? (filtering?) I think it will be easier for the user if they are separated. 2) a textbox which filter on names > For advanced users would be nice to have queries, like "allow view" AND "inherit deny delete" :) > 3) a dropdown list proposing all (default), hide inherited only, and maybe > the list of rights, showing only rows where the selected right is set > locally ? > > The dropdown with the list of rights (view, edit, etc.) could also have another dropdown next to it to set the state of the right (inherited, allowed, denied) Thanks, Caty

14 years, 6 months

[xwiki-devs] Benchmarking of the RightService

by Andreas Jonsson

Hi, I did a quick benchmarking on the right service, to see what the benefits of caching is. I measured the time in nano-seconds over the methods checkAccess and hasAccessLevel. The server is run on a virtual machine, so the statistics is not entirely reliable. I have made some interesting observations, however: * hasAccessLevel is called a large number of times per page view. It is called around 20 times as often as checkAccess, which should normally be called once per accessed wiki-document. * The main reason for the large number of calls to hasAccessLevel are these variable initializations in xwikivars.vm: #set($hasEdit = $xwiki.hasAccessLevel("edit")) #set($hasAdmin = $xwiki.hasAccessLevel("admin")) ## Note: In order to know if the user has the right to create a space we compute a space name that doesn't exist and check edit rights on that space #set($hasCreateSpace = $xwiki.hasAccessLevel("edit", "${doc.space}${mathtool.random(0, 999)}.DocumentReservedForInternalXWikiUsage")) ## Note: In order to know if the user has the right to create a page we compute a page name that doesn't exist and check edit rights on that page #set($hasCreatePage = $xwiki.hasAccessLevel("edit", "${doc.space}.DocumentReservedForInternalXWikiUsage${mathtool.random(0, 999)}")) #set($hasGlobalAdmin = $xwiki.hasAccessLevel("admin", $context.user, "XWiki.XWikiPreferences")) ## Note: The document name is not internally used to determine if a user has programming access level. We pass XWiki.XWikiPreferences for consistency with the call for global admin #set($hasProgramming = $xwiki.hasAccessLevel("programming", $context.user, "XWiki.XWikiPreferences")) #set($hasSpaceAdmin = $xwiki.hasAccessLevel("admin", $context.user, "${doc.space}.WebPreferences")) Due to the ugly hack with randomly generated space names and document names for initiating the variables "$hasCreateSpace" and "$hasCreatePage", the caching implementation perform worse than it could, as this will cause many cache misses and waste cache space. However, my new implementation internally operates by computing and caching the rights corresponding to an EntityReference, which may refer to a document, a space, or a wiki. If this is exposed via the API it will be possible to query for the rights on a space and wiki directly. By removing the randomness : #set($hasCreateSpace = $xwiki.hasAccessLevel("edit", "${doc.space}INTERNAL.DocumentReservedForInternalXWikiUsage")) #set($hasCreatePage = $xwiki.hasAccessLevel("edit", "${doc.space}.DocumentReservedForInternalXWikiUsage")) and running a test by reloading the same page over and over, we see the benefit of caching: Original implementation: Statistics for checkAccess: DescriptiveStatistics: n: 2030 min: 522859.0 max: 5.39733259E8 mean: 1.7198616874876842E7 std dev: 3.7962038152575314E7 median: 659100.0 skewness: 4.262358507299374 kurtosis: 30.885271611362477 Statistics for hasAccessLevel: DescriptiveStatistics: n: 39402 min: 69016.0 max: 6.40750283E8 mean: 8595126.655296639 std dev: 2.770284412153291E7 median: 592985.0 skewness: 5.682505086745415 kurtosis: 50.72341779375682 ----------------------------------------- My new implementation: Statistics for checkAccess: DescriptiveStatistics: n: 2030 min: 27763.0 max: 3.01349107E8 mean: 3118090.7699507335 std dev: 1.6890870361759447E7 median: 132935.0 skewness: 8.995243673145804 kurtosis: 105.30119067606974 Statistics for hasAccessLevel: DescriptiveStatistics: n: 33368 min: 26086.0 max: 1.239094745E9 mean: 767290.0766902551 std dev: 1.0969784229187453E7 median: 32915.5 skewness: 55.482434651126056 kurtosis: 5256.531317809735 Considering the skewed nature of the distribution, the mean value cannot be used to predict the delay caused by the right service. Considering that hasAccessLevel seems to be called more than 30 times per page request, a naive interpretation suggests that over 200 ms was polished of the average request time (7.8 ms * 30). This is obviously bogus, since the mean request time was 170.027 ms for the original implementation and 144.743 ms for my new implementation. The requests were performed with 'ab -c 10 -n 1000 -k ': Output for original implementation: Server Software: Apache-Coyote/1.1 Server Hostname: wiki Server Port: 8080 Document Path: /xw/bin/view/Gob/WebHome Document Length: 0 bytes Concurrency Level: 10 Time taken for tests: 170.027 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Non-2xx responses: 1000 Keep-Alive requests: 995 Total transferred: 414975 bytes HTML transferred: 0 bytes Requests per second: 5.88 [#/sec] (mean) Time per request: 1700.269 [ms] (mean) Time per request: 170.027 [ms] (mean, across all concurrent requests) Transfer rate: 2.38 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 3 Processing: 445 1694 412.3 1654 3663 Waiting: 445 1694 412.3 1654 3663 Total: 445 1694 412.4 1654 3663 -------------------------------------------------------------------------------- Output for my new implementation: Server Software: Apache-Coyote/1.1 Server Hostname: wiki Server Port: 8080 Document Path: /xw/bin/view/Gob/WebHome Document Length: 0 bytes Concurrency Level: 10 Time taken for tests: 144.743 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Non-2xx responses: 1000 Keep-Alive requests: 993 Total transferred: 414965 bytes HTML transferred: 0 bytes Requests per second: 6.91 [#/sec] (mean) Time per request: 1447.426 [ms] (mean) Time per request: 144.743 [ms] (mean, across all concurrent requests) Transfer rate: 2.80 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 4 Processing: 374 1441 428.1 1415 3228 Waiting: 374 1441 428.1 1415 3228 Total: 374 1441 428.1 1415 3228 My implementation needs some more testing, but I will try to upload it to Jira by tomorrow. Best regards, Andreas Jonsson

14 years, 6 months

Re: [xwiki-devs] [Proposal] Move xwiki-application-invitation to platform-applications and include in XEnterprise

by Jerome Velociter

Hi Caleb, Just a quick remark : The application creates a space "Invitation" for which the home page does not exists. This home page should probably be what currently is "Invitation.Invitation" (i.e. the user interface entry point). I'll test more and give more feedback. Jerome. ----- "Caleb James DeLisle" <calebdelisle(a)lavabit.com> wrote: > Hello all, > > First my proposal: > I propose we add the invitation application to platform/applications > and give it a jira top level project > name, I further propose we add a dependency to the Enterprise pom.xml > and merge the UI tests which I have > wrote into the Enterprise UI tests. > I would rather not move the translation keys into the default document > bundle until nearer release time > because it would be nice to use the new internationalization module if > possible and as development is still > going fast, there will be changes to translations. > > > The state of the invitation application: > All major refactoring is finished and I am now just squashing bugs and > adding new features. > > Lately I have been debugging using tests rather than manual debugging, > So far I have 7 UI tests which > with framework comprise 1207 lines in 8 files. Maintaining a fork of > the UI tests is becoming > burdensome and I think the invitation application is ready to be > included. > > Improvements since the version which is on the incubator: > * Each message has a "history", a list of status changes, the user who > made the change and a log > (if any) which they left regarding the change. > * An invitation sent to multiple addresses is handled as a group of > invitations each of which may > be accepted/declined individually, the sender or admin can view the > group and see all of the > messages in it as a table. > * Users see an info macro at the bottom of the screen telling them how > many pending invitations > they have (if any). > * Admins see a warning macro at the bottom of the page telling them > how many message have been > reported as spam (if any have). > * Templates are translatable and (should be) compatible with more > email clients. > > > Tasks still to be done include: > * A means by which invitees can be allowed into a closed wiki. > * Invitation of a mailing list. > * Handling "join requests". > * Use javascript to make it easier to use and implement livetable > * Improve CSS. > > > WDYT? > > Caleb > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

14 years, 6 months

[xwiki-devs] [ANN] XWiki Office 1.2 M1 Released!

by Florin Ciubotaru

The XWiki development team is pleased to announce the release of XWiki Office 1.2 Milestone 1. This new release features the new XWiki annotations integration. - display annotations as Word comments - update annotations - filter by author/reviewer Detailed release notes are available at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXOffice12M1 To download XWiki Office go to: http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiOffice For more information about XWiki Office please visit: http://xoffice.xwiki.org Thanks, - The XWiki dev team

14 years, 6 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2010