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

[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

15 years, 3 months

2
2
0 0

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

15 years, 3 months

2
2
0 0

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

15 years, 3 months

2
1
0 0

[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

15 years, 3 months

8
36
0 0

[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

15 years, 3 months

5
23
0 0

[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

15 years, 3 months

2
1
0 0

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

15 years, 3 months

3
5
0 0

[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

15 years, 3 months

1
0
0 0

[xwiki-devs] showing xwiki-page incl. images in jsp.

by -the-

hi, i'm new on the group but i use xwiki since 3 years. for a automatic display panel application we show a xwiki-page via rpc like the reference "http://platform.xwiki.org/xwiki/bin/view/Features/XMLRPC" but with this code we can't display images. only the name of the picture will displayed. have anybody a solution/reference for this problem. with regards -the-

15 years, 3 months

2
3
0 0

[xwiki-devs] Table Syntax

by Sales, G. (Grant)

How can I make row spanning in the xwiki syntax? I know tables are |=Heading | cell 1,2 | cell 1, 3 |=Heading | cell 2, 2 | cell 2, 3 |=Heading | cell 3, 2 | cell 3, 3 But how can I make the heading be col spanning. Or a row be row spanning. | | cell 1,2 | cell 1, 3 |=Heading | cell 2, 2 | cell 2, 3 | | cell 3, 2 | cell 3, 3 Or | |= Heading1| | cell 1, 2 | cell 2, 2 | cell 2, 3 | cell 1, 3 | cell 3, 2 | cell 3, 3 Grant Sales Security Operations Analyst ING 20 Washington Ave South Minneapolis, MN 55401 Tel: 612.342.7889 Fax: 612.342.3428 Cell: 320.761.0966 Email: grant.sales(a)us.ing.com www.ing-usa.com ING. Your future. Made easier. (r) --------------------------------------------------------- NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. ============================================================================================

15 years, 3 months

2
1
0 0

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

by Caleb James DeLisle

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

15 years, 3 months

2
1
0 0

[xwiki-devs] footer

by Sales, G. (Grant)

If we invoke it twice in a row: {{hello greetUser="true" /}} {{hello /}} The second invocation will not print "Hello World!" as we'd expect. But it will print the same result as the first invocation. The reasons are: * Macro parameters are implemented as global parameters. So, they remains the same across multiple macro invocations. * If $context.macro.params.greetUser contains "null", it will not be assigned to $greetUser. This is different from C/C++ or Java. So in order to get around it, you can use: #set($greetUser="$!context.macro.params.greetUser") Tags: [+] <http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial?showTag…> Created by Asiri Rathnayake <http://www.xwiki.org/xwiki/bin/view/XWiki/asiri> on 2009/07/20 08:30 Last modified by Thomas Mortagne <http://www.xwiki.org/xwiki/bin/view/XWiki/ThomasMortagne> on 2010/05/12 19:42 How can I add the Last Modified by in the bottom by the Created by like on Xwiki.org? Should be an easy way but I can't seem to figure out how to add code below the page like that. Is it in the Admin tools? If so where in there? Grant Sales Security Operations Analyst ING 20 Washington Ave South Minneapolis, MN 55401 Tel: 612.342.7889 Fax: 612.342.3428 Cell: 320.761.0966 Email: grant.sales(a)us.ing.com www.ing-usa.com ING. Your future. Made easier. ® --------------------------------------------------------- NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. ============================================================================================

15 years, 3 months

1
0
0 0

[xwiki-devs] Nested spaces and right service implementation

by Andreas Jonsson

Hi, I have almost finished writing a new right service implementation and have some questions about nested spaces. I am using the EntityReference classes for representing the document hierarchy, with the addition for using the main wiki as the parent of a virtual wiki. XWikiRightServiceImpl is using the parent field in the space's preferences to form a space hierarchy. The EntityReference classes support a list of spaces, but this does not seem to be implemented yet. Can a right service implementation assume that the nested space hierarchy was resolved externally and was inserted into the DocumentReference as a list of spaces? Will the list of spaces in an EntityReference correspond to following parent fields in the space preferences or does a right service implementation need to resolve these parent fields for backwards compliancy? Best Regards, Andreas Jonsson

15 years, 3 months

2
2
0 0

[xwiki-devs] Calling only one property

by Sales, G. (Grant)

Here is how you filter out one dead property (or hide it) #foreach($prop in $class.properties) #if($prop.getName() != "unused_author") ; $prop.prettyName : $doc.display($prop.getName()) #end #end How can you call just the properties you want with out using a for each loop? Grant Sales Security Operations Analyst ING 20 Washington Ave South Minneapolis, MN 55401 Tel: 612.342.7889 Fax: 612.342.3428 Cell: 320.761.0966 Email: grant.sales(a)us.ing.com www.ing-usa.com ING. Your future. Made easier. (r) --------------------------------------------------------- NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. ============================================================================================

15 years, 3 months

3
5
0 0

Re: [xwiki-devs] [Proposal] Wiki Macros vs Java Macros in the default XE distribution

by Vincent Massol

On Jun 3, 2010, at 1:01 PM, Ludovic Dubost wrote: > Le 03/06/10 12:48, Vincent Massol a écrit : >> On Jun 3, 2010, at 12:20 PM, Ludovic Dubost wrote: >> >> >>> Le 03/06/10 11:33, Vincent Massol a écrit : >>> >>>> On Jun 3, 2010, at 10:31 AM, Vincent Massol wrote: >>>> >>>> >>>> >>>>> Hi devs, >>>>> >>>>> We have avoided this discussion but it's time to settle it. We need to decide if there are candidate macros that we should write as wiki macros in our default XE distribution. And if so what are the rule for deciding whether a macro should be written as a wiki macro or as a java macro. >>>>> >>>>> Some ideas: >>>>> - java macros are much easier to test >>>>> - java macros are easier to develop since you have a full-fledged IDE (debugging, syntax coloring, code validation, etc) >>>>> - java macros can obey styling rule, such as checkstyle passing >>>>> - wiki macros can be removed so users can't be sure the wiki macro will always be there since it's only provided with the default XAR >>>>> >>>>> Proposal >>>>> ======= >>>>> >>>>> - If the macro is a generic macro then it should be written as a Java macro >>>>> - If the macro is application-specific (for ex a macro specific to the Blog application) then it can be written as a Wiki macro >>>>> >>>>> WDYT? >>>>> >>>>> >>>> ok, I've been convinced that there's no simple solution and thus that we need to decide whether a macro should be implemented in java or as a wiki page on a case by case basis. >>>> >>>> Thus I propose that when a macro is implemented as a wiki macro, we put in SVN in platform/applications as an application by itself (ie a XAR). In the same manner as java macros are a JAR by themselves. >>>> >>>> >>> We should avoid having one application per macro, otherwise it's going to be a mess. >>> >> In what sense? >> >> JIRA-wise? Release-wise? >> >> > It's going to be way to segmented in SVN, JIRA and in terms of multiple XARs > I think we should see it as a package of Macros more than a package of each macro Actually I agree that it's better to have a single application for wiki macros. We release all java macros as one so we can also do the same for wiki macros. We can put these wiki macros in a separate application or inside the wiki-macro-bridge application since they depend on it. I'm more for the latter. Thanks -Vincent > Ludovic > >>> I think we should categorize the wiki macros so that we have one application by big category. >>> >> Also we'll soon have the ability to download and install them from the internet, making it easy to install extensions. Providing superpackages is possible with the new extension manager, simply by having an extension that has dependencies on individual artifacts. >> >> But yes I agree we need to think about macro explosion and how we handle this, whether we want a single JIRA module for macros for exemple and release them all together. JIRA + release are the only issues I can think of since we're talking about macros bundled by default. >> >> Note: We also need to agree on a space where to put them. >> >> Thanks >> -Vincent

15 years, 3 months

1
0
0 0

Re: [xwiki-devs] [Proposal] Wiki Macros vs Java Macros in the default XE distribution

by Vincent Massol

On Jun 3, 2010, at 12:20 PM, Ludovic Dubost wrote: > Le 03/06/10 11:33, Vincent Massol a écrit : >> On Jun 3, 2010, at 10:31 AM, Vincent Massol wrote: >> >> >>> Hi devs, >>> >>> We have avoided this discussion but it's time to settle it. We need to decide if there are candidate macros that we should write as wiki macros in our default XE distribution. And if so what are the rule for deciding whether a macro should be written as a wiki macro or as a java macro. >>> >>> Some ideas: >>> - java macros are much easier to test >>> - java macros are easier to develop since you have a full-fledged IDE (debugging, syntax coloring, code validation, etc) >>> - java macros can obey styling rule, such as checkstyle passing >>> - wiki macros can be removed so users can't be sure the wiki macro will always be there since it's only provided with the default XAR >>> >>> Proposal >>> ======= >>> >>> - If the macro is a generic macro then it should be written as a Java macro >>> - If the macro is application-specific (for ex a macro specific to the Blog application) then it can be written as a Wiki macro >>> >>> WDYT? >>> >> ok, I've been convinced that there's no simple solution and thus that we need to decide whether a macro should be implemented in java or as a wiki page on a case by case basis. >> >> Thus I propose that when a macro is implemented as a wiki macro, we put in SVN in platform/applications as an application by itself (ie a XAR). In the same manner as java macros are a JAR by themselves. >> > We should avoid having one application per macro, otherwise it's going to be a mess. In what sense? JIRA-wise? Release-wise? > I think we should categorize the wiki macros so that we have one application by big category. Also we'll soon have the ability to download and install them from the internet, making it easy to install extensions. Providing superpackages is possible with the new extension manager, simply by having an extension that has dependencies on individual artifacts. But yes I agree we need to think about macro explosion and how we handle this, whether we want a single JIRA module for macros for exemple and release them all together. JIRA + release are the only issues I can think of since we're talking about macros bundled by default. Note: We also need to agree on a space where to put them. Thanks -Vincent

15 years, 3 months

2
1
0 0

[xwiki-devs] [Proposal] Wiki Macros vs Java Macros in the default XE distribution

by Vincent Massol

Hi devs, We have avoided this discussion but it's time to settle it. We need to decide if there are candidate macros that we should write as wiki macros in our default XE distribution. And if so what are the rule for deciding whether a macro should be written as a wiki macro or as a java macro. Some ideas: - java macros are much easier to test - java macros are easier to develop since you have a full-fledged IDE (debugging, syntax coloring, code validation, etc) - java macros can obey styling rule, such as checkstyle passing - wiki macros can be removed so users can't be sure the wiki macro will always be there since it's only provided with the default XAR Proposal ======= - If the macro is a generic macro then it should be written as a Java macro - If the macro is application-specific (for ex a macro specific to the Blog application) then it can be written as a Wiki macro WDYT? Thanks -Vincent

15 years, 3 months

3
4
0 0

Re: [xwiki-devs] [Proposal] Wiki Macros vs Java Macros in the default XE distribution

by Vincent Massol

On Jun 3, 2010, at 10:37 AM, Ludovic Dubost wrote: > Le 03/06/10 10:31, Vincent Massol a écrit : >> Hi devs, >> >> We have avoided this discussion but it's time to settle it. We need to decide if there are candidate macros that we should write as wiki macros in our default XE distribution. And if so what are the rule for deciding whether a macro should be written as a wiki macro or as a java macro. >> >> Some ideas: >> - java macros are much easier to test >> - java macros are easier to develop since you have a full-fledged IDE (debugging, syntax coloring, code validation, etc) >> - java macros can obey styling rule, such as checkstyle passing >> - wiki macros can be removed so users can't be sure the wiki macro will always be there since it's only provided with the default XAR >> >> Proposal >> ======= >> >> - If the macro is a generic macro then it should be written as a Java macro >> - If the macro is application-specific (for ex a macro specific to the Blog application) then it can be written as a Wiki macro >> >> WDYT? >> > > I believe there is some other cases where it should be a wiki macro, it's when the macro is highly presentational and when there is a good chance the advanced user would like to be able to change the macro to add parameters or modify it's presentation. > In this case it's very important to make the macro easily modifiable and that's what Wiki macros allow. Indeed anything related to presentation/style (colors, fonts, texts, etc) should be modifiable by the user so that part needs to be externalized from the java macro somehow. One idea is to have these macros provide a cssLocation/jsLocation parameter pointing to place where to put custom css/js. When not specified the macro would use default css/js. Ideally we would have a full-fledged IDE in the wiki and we would write everything as wiki macros but this is not the case and we're a few years away from this so I'm not sure it's a good idea to do so right now. BTW this is a bit similar to the discussion as to whether the Blog application should have a Java module that implements its code logic and only keep the presentation part in wiki page vs what we have right now, i.e. the whole application in wiki pages. > For testing, I believe we should make a simple testing framework that allows to test a simple wiki macro (which does not use jsx or other stuff). Making a wiki macro testing framework that works without a running XE is probably quite a lot of work. Need to think more about it. Thanks -Vincent

15 years, 3 months

2
1
0 0

[xwiki-devs] Wanted Macros

by Vincent Massol

Hi XWiki lovers, If you're interested in seeing some macros developed and available for your wiki, please edit this page and add macros you'd like to see: http://dev.xwiki.org/xwiki/bin/view/Design/NewMacros Thanks -Vincent

15 years, 3 months

1
0
0 0

[xwiki-devs] Introducing Sorin Burjan

by Sorin Burjan

Hello. My name is Sorin Burjan, and I started working at XWiki two days ago. I came to XWiki as a software tester, technical writer, but as the time goes by, I'd like to get involved in dev too. For the moment, I'm working with Silvia on updating the documentation on the web site, and creating a set of rules/standards on how to write and maintain the documentation. The document will be posted on the comunity site, so you can give me your feedback. Regards, Sorin B.

15 years, 3 months

2
1
0 0

[xwiki-devs] [ANN] XWiki Enterprise 2.4 Milestone 1 Released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.4 Milestone 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is first milestone of the XWiki Enterprise 2.4 version. Main changes from 2.3.1: * New Search application and administration UI * New Rendering cache * WYSIWYG improvements * New Code macro configuration * Security improvements * Performance improvements * Chart macro improvements * Lots of bugs fixes For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise24M1 Thanks - The XWiki dev team

15 years, 3 months

1
0
0 0

Re: [xwiki-devs] [Issue] Updated: (XWIKI-5227) Introduce a temp resource action

by Asiri Rathnayake

Hi Thomas, The commit for this fix was included in 2.4M1, I forgot to close the JIRA issue :( I hope it's ok to do it now. - Asiri On Wed, Jun 2, 2010 at 10:22 PM, Thomas Mortagne (JIRA) <jira(a)xwiki.org>wrote: > > [ > http://jira.xwiki.org/jira/browse/XWIKI-5227?page=com.atlassian.jira.plugin…] > > Thomas Mortagne updated XWIKI-5227: > ----------------------------------- > > Fix Version/s: 2.4 M2 > (was: 2.4 M1) > > > Introduce a temp resource action > > -------------------------------- > > > > Key: XWIKI-5227 > > URL: http://jira.xwiki.org/jira/browse/XWIKI-5227 > > Project: XWiki Core > > Issue Type: Improvement > > Components: Core > > Affects Versions: 2.3, 2.2.6 > > Reporter: Asiri Rathnayake > > Assignee: Asiri Rathnayake > > Fix For: 2.4 M2 > > > > Attachments: temp.resource.action.v1.patch, > temp.resource.action.v2.patch > > > > > > Refer discussion: > http://xwiki.475771.n2.nabble.com/Introduce-new-tempresource-action-td41252… > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://jira.xwiki.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > >

15 years, 3 months

2
1
0 0

[xwiki-devs] Passing values in HTML

by Sales, G. (Grant)

> _____________________________________________ > From: Sales, G. (Grant) > Sent: Friday, May 28, 2010 01:43 PM > To: 'devs(a)xwiki.org' > Subject: Passing values in HTML > > I need to create a form simmilar to what a FAQ does but with more > values. > I've built my form in HTML but I can't seem to figure out how to pass > the values within my table to a newly created page under a specific > parent with all the values filled in and saved (users need to still be > able to edit). > > The table is simmilar to this. But I've cut out business related > information and made the form/table smaller (less fields) > > > <html> > <form> > > <table border = "1"> > <tr><th>Number:</th><td><input type = "text" name = "inNum"></td></tr> > <tr><th>Name:</th><td><input type = "text" name = "inName"></td></tr> > </table> > > <table border = "1"> > <TR><TH rowspan = "6">Requirments</th></tr> > <td>Business Driver / Need (Description of problem or > opportunity)</td> > <td><input type = "text" name = "inDecript"> > </td> > </tr> > <tr> > <td>Driving Organization</td> > <td><select name="selOrg" > > <option value= "1">Not Applicable</option> > > </select> > </td> > </tr> > <tr> > <td> Regulations </td> > <td> <select name="selReg"> > <option value= "1">Not Applicable</option> > </select> > </td> > </tr> > <tr> > <td>Policies </td> > <td> <select name="selPol"> > <option value= "1">Not Applicable</option> > </select> > </td> > </tr> > <tr> > <td>Category </td> > <td><input type="text" name="inCat"> > </td> > </tr> > </table> > </from> > > > Any help would be great, this Xwiki syntax, forms, tables, templates > and classes have been driving me nuts, there has to be an easy little > section of code that can let me pass the values off to a new page and > create the page with table I just made, (copy entire contents of page > besides the "make new page button" with the fields filled in and > selected) > > Grant Sales > Security Operations Analyst > ING > 20 Washington Ave South > Minneapolis, MN 55401 > Tel: 612.342.7889 > Fax: 612.342.3428 > Cell: 320.761.0966 > Email: grant.sales(a)us.ing.com > www.ing-usa.com > ING. Your future. Made easier. (r) > > --------------------------------------------------------- NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. ============================================================================================

15 years, 3 months

2
3
0 0

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.3.1 Released

by Jean-Vincent Drean

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.3.1. This is a bug fix release for the 2.3 branches. Improvements: * [XPLUCENE-4] - Index inside of zip files using Lucene * [XPLUCENE-13] - Ability to rebuild the indexes just for one virtual wiki * [XPLUCENE-47] - Add ability to index attachments in OpenXML format * [XPLUCENE-29] - Adding capability to refresh the index without cleaning it * [XPLUCENE-36] - Lucene search on property level Important Bugs fixed: * [XE-651] - RSS feed for search results doesn't work * [XE-670] - Deleted Documents and Deleted Attachments are not displayed anymore * [XE-673] - Cannot create a new space from the dashboard * [XE-675] - Recent Changes appears empty on user profiles when not logged as advanced user * [XWIKI-5166] - Guest user rights are not properly tested when tested from another wiki * [XWIKI-5133] - The caret jumps at the start of the page when pressing Enter at the end of a line * [XWIKI-5175] - NPE in XWikiLDAPUtils#isMemberOfGroup cause authentication to fail * [XPWATCHLIST-109] - WatchListClass page saved very often * [XAADMINISTRATION-125] - Editing a user/group from "XWiki Preferences > Users/Groups" doesn't work For more information see the Releases notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise231 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM231 Thanks -The XWiki dev team

15 years, 3 months

1
0
0 0

[xwiki-devs] [Proposal] A private security mailing list

by Alex Busenius

Hello devs, I propose to introduce a security mailing list (security(a)xwiki.org) to discuss details of security issues. This list should be private, with only committers and trusted contributors having read and write access. Anyone who proved his good intentions on the dev-list and bug tracker should be able to get access to security-list through the usual vote procedure. The purpose of this list is to give a safe place to discuss details open security issues without giving all script kiddies in the world examples to write exploits. The discussions should be kept on this private list until the corresponding fix is released. WDYT? Alex

15 years, 3 months

11
24
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