Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On 05/27/2010 10:26 AM, Denis Gervalle wrote: On Thu, May 27, 2010 at 09:57, Ecaterina Valicavali...@gmail.com wrote: Hi, I want to talk a bit about: The inheritance is a little bit particular, since allowing a given right at lower level, will deny that same right for anybody else even if this right is allowed at a higher level. I want to know how hard this would be to be changed. Changing this is not hard, but it will increase complexity since we will need a backward compatibility mode for existing wikis. Another question is why this has been done in the first place? Can someone give a valid use case when this is more productive than other ways. I really do not know, and I am curious as well. It was done because the deny right is stronger than the allow right. How can I say that for space X only group A has view right, and nobody else? Attempt 1. Deny to Guest and All, allow to A. Oups, doesn't work, since everybody in A is also in All, and deny is stronger, so everyone is denied... Attempt 2. Hm, how could this be done? Denying to everybody is not an option... So, allow the view right to A, and automagically everybody else is denied. Great, XWiki really rocks! This is not a very valid use case, but more like a necessity. When designing the current rights mechanism, a lot of not-entirely-compatible use cases had to be balanced, and the outcome doesn't cleanly satisfy all use cases, but it tries to make each scenario possible one way or another. It is very confusing and users need to do additional steps in order to give the rights they want. I completely agree, this is poor. I think is a problem of how the Groups are perceived. Only as a rights mechanism or as a semantically grouping. We should not decide this, since groups maybe synchronized from external system (ie LDAP), imposing groups for rights is not correct. By the way, groups may contains groups, but I am almost sure that this will work properly in practice. If we use groups just to give rights than the current implementation is usable. But if you have groups, like Tech team, Design team, Marketing, Happy team ... etc in order to classify our users in other ways beside rights management, giving permission to a user is breaking all the inheritance from upper levels. Example: Group A(Managers) has View (default allowed) at wiki level - this means that they should be allowed to view all the pages in the wiki. Group B(Tech Team) has View (explicitly denied) at spaceX level - this means they shouldn't be allowed to view this space. But I have a person (the managerX) in Group B that is supposed to see the info in spaceX level. So the first logical move would be to give him allow at space level (having in mind that space rights are stronger that wiki rights and the view right has been overriden). But, if I give managerX view right, all the other groups (incluing Managers) will be denied for spaceX level. This means I need to know that and repair again all the rights I ALREADY set at the higher level. This behavior is not logical for me. It is not logical for me and I imagine many others ! A solution would be to take out managerX form Group B and leave it just in Managers group. Yes, this way my problem is solved, but this means Groups are only used for Rights purposes. Group B (Tech Team) is no longer semantically compact and I can't further give this group compact tasks, etc. Please tell if is a way to change this behavior and please have in mind XWiki 3.0, where Groups are going beyond rights management and they should be seen as collaboration mechanisms (which need to be semantical). IMO, XWiki 3.0 should have a complete rework of the right service implementation, and breaks with the past. Since this will cause many migration issue, I am not in favor of progressive changes, and I would prefer to see a big single change that fix this, and also the current discussion on script rights. +1. Denis Rights should be inherited from upper level and should affect only the user/group where a change is made, not make some complicated implications at other levels and groups. Thanks, Caty -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Wed, Jun 9, 2010 at 12:57, Sergiu Dumitriu ser...@xwiki.com wrote: On 05/27/2010 10:26 AM, Denis Gervalle wrote: On Thu, May 27, 2010 at 09:57, Ecaterina Valicavali...@gmail.com wrote: Hi, I want to talk a bit about: The inheritance is a little bit particular, since allowing a given right at lower level, will deny that same right for anybody else even if this right is allowed at a higher level. I want to know how hard this would be to be changed. Changing this is not hard, but it will increase complexity since we will need a backward compatibility mode for existing wikis. Another question is why this has been done in the first place? Can someone give a valid use case when this is more productive than other ways. I really do not know, and I am curious as well. It was done because the deny right is stronger than the allow right. How can I say that for space X only group A has view right, and nobody else? Attempt 1. Deny to Guest and All, allow to A. Oups, doesn't work, since everybody in A is also in All, and deny is stronger, so everyone is denied... IMO, RegisteredUsers is a special case. Imagine RegisteredUsers as a Wiki, and GroupA as a Space; and have the same level of appliance for groups (page-space-wiki, where space rights override wiki rights). So if I deny All and allow A, semantically A will have allow, because the tie will be broken by level. Just a thought. Caty Attempt 2. Hm, how could this be done? Denying to everybody is not an option... So, allow the view right to A, and automagically everybody else is denied. Great, XWiki really rocks! This is not a very valid use case, but more like a necessity. When designing the current rights mechanism, a lot of not-entirely-compatible use cases had to be balanced, and the outcome doesn't cleanly satisfy all use cases, but it tries to make each scenario possible one way or another. It is very confusing and users need to do additional steps in order to give the rights they want. I completely agree, this is poor. I think is a problem of how the Groups are perceived. Only as a rights mechanism or as a semantically grouping. We should not decide this, since groups maybe synchronized from external system (ie LDAP), imposing groups for rights is not correct. By the way, groups may contains groups, but I am almost sure that this will work properly in practice. If we use groups just to give rights than the current implementation is usable. But if you have groups, like Tech team, Design team, Marketing, Happy team ... etc in order to classify our users in other ways beside rights management, giving permission to a user is breaking all the inheritance from upper levels. Example: Group A(Managers) has View (default allowed) at wiki level - this means that they should be allowed to view all the pages in the wiki. Group B(Tech Team) has View (explicitly denied) at spaceX level - this means they shouldn't be allowed to view this space. But I have a person (the managerX) in Group B that is supposed to see the info in spaceX level. So the first logical move would be to give him allow at space level (having in mind that space rights are stronger that wiki rights and the view right has been overriden). But, if I give managerX view right, all the other groups (incluing Managers) will be denied for spaceX level. This means I need to know that and repair again all the rights I ALREADY set at the higher level. This behavior is not logical for me. It is not logical for me and I imagine many others ! A solution would be to take out managerX form Group B and leave it just in Managers group. Yes, this way my problem is solved, but this means Groups are only used for Rights purposes. Group B (Tech Team) is no longer semantically compact and I can't further give this group compact tasks, etc. Please tell if is a way to change this behavior and please have in mind XWiki 3.0, where Groups are going beyond rights management and they should be seen as collaboration mechanisms (which need to be semantical). IMO, XWiki 3.0 should have a complete rework of the right service implementation, and breaks with the past. Since this will cause many migration issue, I am not in favor of progressive changes, and I would prefer to see a big single change that fix this, and also the current discussion on script rights. +1. Denis Rights should be inherited from upper level and should affect only the user/group where a change is made, not make some complicated implications at other levels and groups. Thanks, Caty -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
It will if it display the inheritance source in a column. For right set at current level this column could even precise what inheritance has been overwritten, both in terms of allowance and origin. Denis. Hi Denis, Something like this: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space Yes, something like that. I would have expected a back to basic button in place of advanced, and the removal of the basic interface to avoid duplicating basic rights. Maybe the menu should be horizontal in the advanced interface, I do not know. Also add some hyperlinks to upper level in the column explaining inheritance. And put the highlight of changes over the rest of the row (includes name and inheritance) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space About: I would have expected a back to basic button in place of advanced, and the removal of the basic interface to avoid duplicating basic rights http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/rights52Space.png This removal of the basic interface will be set from the user profile's variables (if it has advanced type)? No, just removed when the advanced interface is shown using the advanced button, like you have done. I mean if the user is advanced, all the rows will be presented in advances? No, the only thing I proposed is that user that are not set Advanced user in their profile, will not be presented the advanced interface link, and will never see extended rights. I'm asking because I think the collapsed view is great to see changes up in the table, where you don't care the advanced status of those rights. I completely agree. Advanced interface is for understanding and fixing deep complex stuffs WDYT ? Is this interesting ? it's nice :P I would love to see some other opinions. Yes, could it be possible for you to fix the interactive version to hide the basics and also to have hover and click work as expected. I think it will helps in receiving more feed back with causing confusion. Raluca offered to help me fix the interaction. I found the result really well suited now. There is just some improvement in color contrast, icons aspect, and so on that should be applied if we get approval for this proposal. Once you have fixed the sample, I think that a summary page (resume of our reflexion, and containing only the final proposal) and than a vote thread could be appropriate to receive feedback from other committers, since the size of this thread could be pushing back. Yes, a summary+vote is needed. I made a version with pagination and filters added. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space PNG for the filters: collapsed: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filtersCollapsed.png expanded: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filtersExpanded.png What do you think? Could this filters be helpful? Are too powerful/complex/useless? Not sure we really need all these. What is important for me is: - local, global, all user type, with local by default - local, inherited, implied right - user/group name filtering See: Collapsed: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filters2collapsed.png Expanded: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filters2expanded.png The rest could be convenient, but it also takes unnecessary horizontal space, which is annoying IMO. From an implementation point of view, can a livetable have more than one filter per a column. No problem if we use only the .js without de livetable macro. Anyway this will be a custom livetable, because we also need to integrate the add user part and the save/reset buttons. Yes, it will probably be so. Also, from an implementation point of view, should we enable multiselect (ex. to select multiple rights)? I have made recent fixes for that in the livetable.js, so this is not a problem. Obs. Right - Sources - Implicit refer to the rights that come from the setting of another right (example: admin means implicit view+edit+delete+comment; creator means implicit delete). Would this filter option be useful or it is too much? Doesn't this also include implicit settings when no right has been set anywhere ? IMO, when no right has been set is a special case, the Default values. We could see it as implicit, but actually I think they are more like inherited (from the code
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On 06/03/2010 06:09 PM, Ecaterina Valica wrote: Hi Denis, 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. The proper icon for deny is not (X), but (-), bullet_delete.gif in Silk, or the larger delete.gif. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
Some more comments: - The last icon-labeled field (currently depicted by a key) could be Other rights, not Advanced - The key does not suggest other rights (nor advanced) to me. Maybe use a word instead of an icon (More.., Application rights)? - I'm not sure the folder with a user in it is a good representation for a group. Usually a labeled folder stands for a space with a certain purpose. Why not use the group.gif icon (two users)? - I propose to put an explanatory word next to each icon in the dropdown. There is enough room for it and I think it would help a lot. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On 06/09/2010 12:24 PM, Ecaterina Valica wrote: Another question is why this has been done in the first place? Can someone give a valid use case when this is more productive than other ways. I really do not know, and I am curious as well. It was done because the deny right is stronger than the allow right. How can I say that for space X only group A has view right, and nobody else? Attempt 1. Deny to Guest and All, allow to A. Oups, doesn't work, since everybody in A is also in All, and deny is stronger, so everyone is denied... IMO, RegisteredUsers is a special case. Imagine RegisteredUsers as a Wiki, and GroupA as a Space; and have the same level of appliance for groups (page-space-wiki, where space rights override wiki rights). True, but that's not the way it was implemented initially. XWikiAllGroup was just another group like all others. Now, it is a bit more special, since it can be completely virtual, it can implicitly contain all registered users, and it is referenced in the code as the default group for new users. So if I deny All and allow A, semantically A will have allow, because the tie will be broken by level. Just a thought. Caty Attempt 2. Hm, how could this be done? Denying to everybody is not an option... So, allow the view right to A, and automagically everybody else is denied. Great, XWiki really rocks! This is not a very valid use case, but more like a necessity. When designing the current rights mechanism, a lot of not-entirely-compatible use cases had to be balanced, and the outcome doesn't cleanly satisfy all use cases, but it tries to make each scenario possible one way or another. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Annotation not working
Hi, I try to configure annotations on cop-1.myxwiki.org without success The annotation menu doesn't appear on that wiki Can you help please. I've read somewhere in the forum that it is related to developer right on a space but I don't know how I can deal with that. Kind regards http://epist.bouygues-construction.com/images/structis.gifhttp://epist.bouygues-construction.com/images/structis.gif Eric JUIN Directeur Partage de la Connaissance - e|services STRUCTIS - Gie Informatique BOUYGUES CONSTRUCTION e.j...@bouygues-construction.com Tél: + 33 1 30 60 21 07 Mob: +33 6 60 35 21 07 http://epist.bouygues-construction.com/images/feuille.jpghttp://epist.bouygues-construction.com/images/feuille.jpg Respectons l'environnement, n'imprimez ce message que si nécessaire Please consider the environment before printing this mail -- Les donnees et renseignements contenus dans ce message sont personnels, confidentiels et secrets. Toute publication, utilisation ou diffusion, meme partielle, doit etre autorisee. Si vous n'etes pas le bon destinataire, nous vous demandons de ne pas lire, copier, utiliser ou divulguer cette communication. Nous vous prions de notifier cette erreur a l'expediteur et d'effacer immediatement cette communication de votre systeme. Any data and information contained in this electronic mail is personal, confidential and secret. Any total or partial publication, use or distribution must be authorized. If you are not the right addressee, we ask you not to read, copy, use or disclose this communication. Please notify this error to the sender and erase at once this communication from your system. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Annotation not working
Hi Eric, On 06/09/2010 03:17 PM, JUIN, Eric wrote: Hi, I try to configure annotations on cop-1.myxwiki.org without success The annotation menu doesn't appear on that wiki Can you help please. I've read somewhere in the forum that it is related to developer right on a space but I don't know how I can deal with that. You need to save a couple of documents on the wiki with programming rights in order for that to work (AnnotationCode.Script, AnnotationCode.Style, AnnotationCode.Settings and AnnotationCode.AnnotationConfigClass). You need to have a global user and programming rights on the whole myxwiki to be able to do that. I can handle it for you on that wiki if you prefer. Happy xwiki-ing, Anca Kind regards http://epist.bouygues-construction.com/images/structis.gifhttp://epist.bouygues-construction.com/images/structis.gif Eric JUIN Directeur Partage de la Connaissance - e|services STRUCTIS - Gie Informatique BOUYGUES CONSTRUCTION e.j...@bouygues-construction.com Tél: + 33 1 30 60 21 07 Mob: +33 6 60 35 21 07 http://epist.bouygues-construction.com/images/feuille.jpghttp://epist.bouygues-construction.com/images/feuille.jpg Respectons l'environnement, n'imprimez ce message que si nécessaire Please consider the environment before printing this mail -- Les donnees et renseignements contenus dans ce message sont personnels, confidentiels et secrets. Toute publication, utilisation ou diffusion, meme partielle, doit etre autorisee. Si vous n'etes pas le bon destinataire, nous vous demandons de ne pas lire, copier, utiliser ou divulguer cette communication. Nous vous prions de notifier cette erreur a l'expediteur et d'effacer immediatement cette communication de votre systeme. Any data and information contained in this electronic mail is personal, confidential and secret. Any total or partial publication, use or distribution must be authorized. If you are not the right addressee, we ask you not to read, copy, use or disclose this communication. Please notify this error to the sender and erase at once this communication from your system. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Problem to build XWiki-Manager (2.3.1) in Eclipse
Yes you are right, thanks for the advise. Probably the blog module is more what I need. Now how can I build it in eclipse? :) -- View this message in context: http://xwiki.475771.n2.nabble.com/Problem-to-build-XWiki-Manager-2-3-1-in-Eclipse-tp5156754p5158537.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Groovy JAR attach
Hi xwiki-users,
I seem to be having trouble including JARs in my Groovy classpath. I'm
trying the following:
{{groovy jars=attach:test-1.0.jar}}
try {
def x = Class.forName(com.test.TestMe)
out.println(x)
}
catch(e) {
out.println(FAILURE: + e)
}
{{/groovy}}
This ends up with the text FAILURE: ClassNotFoundException, but if I
change the first line to:
Class.forName(com.test.TestMe, false, this.getClass().getClassLoader())
it seems to work. But, when I try this instead:
{{groovy jars=attach:wiki:Sandbox.Test}}
try {
def x = Class.forName(com.test.TestMe, false,
this.getClass().getClassLoader())
out.println(x)
}
catch(e) {
out.println(FAILURE: + e)
}
{{/groovy}}
it red-boxes me with a NullPointerException at the end (at
com.xpn.xwiki.doc.DefaultDocumentAccessBridge.getAttachmentContent(DefaultDocumentAccessBridge.java:510)).
And, same issue if I try it without the ClassLoader.
Ultimately, I'm trying to wrap this in a WikiMacro, but none of these
options work if I put the code in a WikiMacro object. Anyone have luck with
JAR attachments? Thanks in advance!
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] [ANN] XWiki Office 1.2 M1 Released!
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 ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [myxwiki] new wiki request
Oh, sorry to waste your time. Somehow, I've gotten confused. I have now created the user account. thanks, /John On Wed, Jun 9, 2010 at 6:28 AM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Wed, Jun 9, 2010 at 12:28, Thomas Mortagne thomas.morta...@xwiki.com wrote: On Tue, Jun 8, 2010 at 23:31, John Morfit jmorf...@gmail.com wrote: Hi, I'd like to start a wiki for practitioners of Hapkido, a Korean martial art. We (a group of students of Hapkido) will use the wiki to store and share learned techniques. myxwiki username: jmorfit3 There is no such user name, see http://myxwiki.org/xwiki/bin/view/XWiki/jmorfit3 (you have to register yourself) desired wiki server name: hapkido.myxwiki.org alternate wiki server name: omaahkd.myxwiki.org Thanks, /John Morfit ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Thomas Mortagne -- Thomas Mortagne ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Tue, Jun 8, 2010 at 4:41 PM, Ecaterina Valica vali...@gmail.com wrote: On Tue, Jun 8, 2010 at 13:46, Denis Gervalle d...@softec.lu wrote: On Tue, Jun 8, 2010 at 11:19, Ecaterina Valica vali...@gmail.com wrote: On Tue, Jun 8, 2010 at 09:01, Denis Gervalle d...@softec.lu wrote: On Mon, Jun 7, 2010 at 17:00, Ecaterina Valica vali...@gmail.com wrote: It will if it display the inheritance source in a column. For right set at current level this column could even precise what inheritance has been overwritten, both in terms of allowance and origin. Denis. Hi Denis, Something like this: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space Yes, something like that. I would have expected a back to basic button in place of advanced, and the removal of the basic interface to avoid duplicating basic rights. Maybe the menu should be horizontal in the advanced interface, I do not know. Also add some hyperlinks to upper level in the column explaining inheritance. And put the highlight of changes over the rest of the row (includes name and inheritance) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space About: I would have expected a back to basic button in place of advanced, and the removal of the basic interface to avoid duplicating basic rights http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/rights52Space.png This removal of the basic interface will be set from the user profile's variables (if it has advanced type)? No, just removed when the advanced interface is shown using the advanced button, like you have done. I mean if the user is advanced, all the rows will be presented in advances? No, the only thing I proposed is that user that are not set Advanced user in their profile, will not be presented the advanced interface link, and will never see extended rights. I'm asking because I think the collapsed view is great to see changes up in the table, where you don't care the advanced status of those rights. I completely agree. Advanced interface is for understanding and fixing deep complex stuffs WDYT ? Is this interesting ? it's nice :P I would love to see some other opinions. Yes, could it be possible for you to fix the interactive version to hide the basics and also to have hover and click work as expected. I think it will helps in receiving more feed back with causing confusion. Raluca offered to help me fix the interaction. I fixed some interaction issues. There are more to do, but I think that this is enough for now. We will implement it right if this proposal will be accepted/voted. I tested the interaction only on FF 3.6.3. Raluca. I found the result really well suited now. There is just some improvement in color contrast, icons aspect, and so on that should be applied if we get approval for this proposal. Once you have fixed the sample, I think that a summary page (resume of our reflexion, and containing only the final proposal) and than a vote thread could be appropriate to receive feedback from other committers, since the size of this thread could be pushing back. Yes, a summary+vote is needed. I made a version with pagination and filters added. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space PNG for the filters: collapsed: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filtersCollapsed.png expanded: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filtersExpanded.png What do you think? Could this filters be helpful? Are too powerful/complex/useless? From an implementation point of view, can a livetable have more than one filter per a column. Anyway this will be a custom livetable, because we also need to integrate the add user part and the save/reset buttons. Also, from an implementation point of view, should we enable multiselect (ex. to select multiple rights)? Obs. Right - Sources - Implicit refer to the rights that come from the setting of another right (example: admin means implicit view+edit+delete+comment; creator means implicit delete). Would this filter option be useful or it is too much? Thanks, Caty WDYT ? Denis Thanks, Caty ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list d...@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list d...@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ users mailing list users@xwiki.org
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Wed, Jun 9, 2010 at 6:28 PM, Raluca Stavro raluca.moro...@xwiki.com wrote: On Tue, Jun 8, 2010 at 4:41 PM, Ecaterina Valica vali...@gmail.com wrote: On Tue, Jun 8, 2010 at 13:46, Denis Gervalle d...@softec.lu wrote: On Tue, Jun 8, 2010 at 11:19, Ecaterina Valica vali...@gmail.com wrote: On Tue, Jun 8, 2010 at 09:01, Denis Gervalle d...@softec.lu wrote: On Mon, Jun 7, 2010 at 17:00, Ecaterina Valica vali...@gmail.com wrote: It will if it display the inheritance source in a column. For right set at current level this column could even precise what inheritance has been overwritten, both in terms of allowance and origin. Denis. Hi Denis, Something like this: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space Yes, something like that. I would have expected a back to basic button in place of advanced, and the removal of the basic interface to avoid duplicating basic rights. Maybe the menu should be horizontal in the advanced interface, I do not know. Also add some hyperlinks to upper level in the column explaining inheritance. And put the highlight of changes over the rest of the row (includes name and inheritance) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space About: I would have expected a back to basic button in place of advanced, and the removal of the basic interface to avoid duplicating basic rights http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/rights52Space.png This removal of the basic interface will be set from the user profile's variables (if it has advanced type)? No, just removed when the advanced interface is shown using the advanced button, like you have done. I mean if the user is advanced, all the rows will be presented in advances? No, the only thing I proposed is that user that are not set Advanced user in their profile, will not be presented the advanced interface link, and will never see extended rights. I'm asking because I think the collapsed view is great to see changes up in the table, where you don't care the advanced status of those rights. I completely agree. Advanced interface is for understanding and fixing deep complex stuffs WDYT ? Is this interesting ? it's nice :P I would love to see some other opinions. Yes, could it be possible for you to fix the interactive version to hide the basics and also to have hover and click work as expected. I think it will helps in receiving more feed back with causing confusion. Raluca offered to help me fix the interaction. I fixed some interaction issues. There are more to do, but I think that this is enough for now. We will implement it right if this proposal will be accepted/voted. I tested the interaction only on FF 3.6.3. Raluca. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Spac Raluca. I found the result really well suited now. There is just some improvement in color contrast, icons aspect, and so on that should be applied if we get approval for this proposal. Once you have fixed the sample, I think that a summary page (resume of our reflexion, and containing only the final proposal) and than a vote thread could be appropriate to receive feedback from other committers, since the size of this thread could be pushing back. Yes, a summary+vote is needed. I made a version with pagination and filters added. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space PNG for the filters: collapsed: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filtersCollapsed.png expanded: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filtersExpanded.png What do you think? Could this filters be helpful? Are too powerful/complex/useless? From an implementation point of view, can a livetable have more than one filter per a column. Anyway this will be a custom livetable, because we also need to integrate the add user part and the save/reset buttons. Also, from an implementation point of view, should we enable multiselect (ex. to select multiple rights)? Obs. Right - Sources - Implicit refer to the rights that come from the setting of another right (example: admin means implicit view+edit+delete+comment; creator means implicit delete). Would this filter option be useful or it is too much? Thanks, Caty WDYT ? Denis Thanks, Caty ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list d...@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list d...@xwiki.org
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Wed, Jun 9, 2010 at 6:30 PM, Raluca Stavro raluca.moro...@xwiki.com wrote: On Wed, Jun 9, 2010 at 6:28 PM, Raluca Stavro raluca.moro...@xwiki.com wrote: On Tue, Jun 8, 2010 at 4:41 PM, Ecaterina Valica vali...@gmail.com wrote: On Tue, Jun 8, 2010 at 13:46, Denis Gervalle d...@softec.lu wrote: On Tue, Jun 8, 2010 at 11:19, Ecaterina Valica vali...@gmail.com wrote: On Tue, Jun 8, 2010 at 09:01, Denis Gervalle d...@softec.lu wrote: On Mon, Jun 7, 2010 at 17:00, Ecaterina Valica vali...@gmail.com wrote: It will if it display the inheritance source in a column. For right set at current level this column could even precise what inheritance has been overwritten, both in terms of allowance and origin. Denis. Hi Denis, Something like this: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space Yes, something like that. I would have expected a back to basic button in place of advanced, and the removal of the basic interface to avoid duplicating basic rights. Maybe the menu should be horizontal in the advanced interface, I do not know. Also add some hyperlinks to upper level in the column explaining inheritance. And put the highlight of changes over the rest of the row (includes name and inheritance) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space About: I would have expected a back to basic button in place of advanced, and the removal of the basic interface to avoid duplicating basic rights http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/rights52Space.png This removal of the basic interface will be set from the user profile's variables (if it has advanced type)? No, just removed when the advanced interface is shown using the advanced button, like you have done. I mean if the user is advanced, all the rows will be presented in advances? No, the only thing I proposed is that user that are not set Advanced user in their profile, will not be presented the advanced interface link, and will never see extended rights. I'm asking because I think the collapsed view is great to see changes up in the table, where you don't care the advanced status of those rights. I completely agree. Advanced interface is for understanding and fixing deep complex stuffs WDYT ? Is this interesting ? it's nice :P I would love to see some other opinions. Yes, could it be possible for you to fix the interactive version to hide the basics and also to have hover and click work as expected. I think it will helps in receiving more feed back with causing confusion. Raluca offered to help me fix the interaction. I fixed some interaction issues. There are more to do, but I think that this is enough for now. We will implement it right if this proposal will be accepted/voted. I tested the interaction only on FF 3.6.3. Raluca. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Spac (Wrong copy-paste) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space Raluca. Raluca. I found the result really well suited now. There is just some improvement in color contrast, icons aspect, and so on that should be applied if we get approval for this proposal. Once you have fixed the sample, I think that a summary page (resume of our reflexion, and containing only the final proposal) and than a vote thread could be appropriate to receive feedback from other committers, since the size of this thread could be pushing back. Yes, a summary+vote is needed. I made a version with pagination and filters added. http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space PNG for the filters: collapsed: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filtersCollapsed.png expanded: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filtersExpanded.png What do you think? Could this filters be helpful? Are too powerful/complex/useless? From an implementation point of view, can a livetable have more than one filter per a column. Anyway this will be a custom livetable, because we also need to integrate the add user part and the save/reset buttons. Also, from an implementation point of view, should we enable multiselect (ex. to select multiple rights)? Obs. Right - Sources - Implicit refer to the rights that come from the setting of another right (example: admin means implicit view+edit+delete+comment; creator means implicit delete). Would this filter option be useful or it is too much? Thanks, Caty WDYT ? Denis Thanks, Caty ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Re: [xwiki-users] Newline after include macro
On Wed, Jun 9, 2010 at 15:39, Lewis Denizen orang...@gmail.com wrote:
Hi xwiki-users,
I created a page called Sandbox.TestMacro with the following content:
* {{test /}}
The page also has a WikiMacro object defined:
{{include document=Sandbox.TestService context=current /}}{{groovy}}
import com.test.TestService
out.println( TestService.testMe() )
{{/groovy}}
Sandbox.TestService has the following content in it:
{{include document=Sandbox.TestService2 context=current /}}{{groovy
output=false}}
package com.test
class TestService {
def static testMe() {
return TEST
}
}
{{/groovy}}
When you do that you write a paragraph containing two macros (include
and groovy).
You should write
{{include document=Sandbox.TestService2 context=current /}}
{{groovy output=false}}
package com.test
class TestService {
def static testMe() {
return TEST
}
}
{{/groovy}}
instead.
Now, when I render the TestMacro page, I get a few extra p inserted before
the text TEST:
ullip/pTEST/li/ul
This makes the page look weird, since the bullet point text is on a new line
now.. I've also had to put the {{include}} and the {{groovy}} lines
together in the pages above; otherwise, there would just be more p's
inserted.. Is there any way around this? Appreciate any tips!
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Thomas Mortagne
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [myxwiki] new wiki request
On Wed, Jun 9, 2010 at 16:44, John Morfit jmorf...@gmail.com wrote: Oh, sorry to waste your time. Somehow, I've gotten confused. I have now created the user account. You can access your wiki on http://hapkido.myxwiki.org Enjoy ! thanks, /John On Wed, Jun 9, 2010 at 6:28 AM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Wed, Jun 9, 2010 at 12:28, Thomas Mortagne thomas.morta...@xwiki.com wrote: On Tue, Jun 8, 2010 at 23:31, John Morfit jmorf...@gmail.com wrote: Hi, I'd like to start a wiki for practitioners of Hapkido, a Korean martial art. We (a group of students of Hapkido) will use the wiki to store and share learned techniques. myxwiki username: jmorfit3 There is no such user name, see http://myxwiki.org/xwiki/bin/view/XWiki/jmorfit3 (you have to register yourself) desired wiki server name: hapkido.myxwiki.org alternate wiki server name: omaahkd.myxwiki.org Thanks, /John Morfit ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Thomas Mortagne -- Thomas Mortagne ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Thomas Mortagne ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Help with Live Table and Grid Component
On Tue, Jun 8, 2010 at 12:14 AM, Marius Dumitru Florea
mariusdumitru.flo...@xwiki.com wrote:
I don't know much about live table but the code below was already
filtering by space if the space name was present on the request (i.e. if
the page was called with space=SomeSpace in the query string). It looks
like you can specify query string parameters using the extraParams
live table option (
http://code.xwiki.org/xwiki/bin/view/Macros/LiveTableMacro ). So you
should try using the default data source (XWiki.LiveTableResults) with
extra query string parameters:
#set($options = { extraParams:space=Software,
translationPrefix : xe.index.,
rowCount: 15 })
(of course, this code should be place in the table page, before the call
to livetable macro)
Hope this helps,
Marius
I tried this, however it didn't quite work. I did end up looking
further at the live table parameters on the page you referenced and
found another way. I used the topFilters parameter to add my own
hidden input box to be used as a filter for the livetable:
#set($options = { topFilters:'input type=hidden title=Filter
Software Space size=${colprop.size} name=doc.space
id=xwiki-livetable-allsoftwaredocs-filter-5 value=Software /',
translationPrefix : xe.index.,
rowCount: 15 })
Thanks,
- James Cuzella
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space Thanks Raluca. Tomorrow I will send the mail with the proposal, after I make some changes Sergiu suggested. Caty ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Live Table Not showing items in _action column for space admin user
Hello, after playing around with the live table results macro, I found
that if a user does not have full wiki admin access, but only is an
admin of a Space, the links in the Actions column are not displayed.
I was hoping to create a Live Table page for a space so users could
see a space index with easy to use links for actions to perform on
each document in that space. (ie: links to: copy, delete, rename,
rights )
This is contrary to what I'd expect to happen. If I give the user
admin access to the entire wiki, then it displays correctly.
To reproduce:
1) Create a space index page with the following velocity code (replace
__SPACENAME__ with the name of the space):
--
{{velocity}}
#set($collist = [doc.name, doc.space,doc.date, doc.author, _actions])
#set($colprops = {
doc.name : { type : text , size : 30,
link : view},
doc.space : { type : text, link : space,
filterable : false },
doc.date : { type : date },
doc.author : { type : text, link : author},
_actions : {actions: [copy,delete,rename,rights]}
})
#set($options = { topFilters:'input type=hidden title=Filter On
Space size=${colprop.size} name=doc.space
id=xwiki-livetable-allsoftwaredocs-filter-5 value=__SPACENAME__
/',
translationPrefix : xe.index.,
rowCount: 15 })
#livetable(allsoftwaredocs $collist $colprops $options)
{{/velocity}}
--
2) Give a normal user Admin priveleges in that space
3) View page as the Wiki Admin user to see the links displayed in the
Actions column
4) View page as the user you just gave Admin within the space to see
the column show up, but no links in it!
Cheers,
- James Cuzella
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
