[xwiki-users] Page Administration: Rights: Page & Children

[Thomas Froehlich]

Hello,

I have a problem to set up the right page permissions  (or may be I have a 
understanding problem ... ) using XWIKI 9.3

I want to set up access permissions to a certain page and to all children of 
this page. 

- A group "XWikiAdminDocumentation" was created. 
- A page "Administration" was created to be filled with documentation for 
administrators only.
- Only members of group "XWikiAdminDocumentation" should have access to page 
"Administration" 
   (and all coming child pages of "Administration").
- At page "Administration", menu "Administer Page - Users and Groups - Rights: 
Page & Children" 
  I set up the following permissions:
--- ALL rights to groups "XWikiAdminDocumentation" and "XWikiAdminGroup".
--- NO rights to groups like "XWikiAllGroup" and "XWikiGuests".
--- Please, have a look at the attached screenshot (sorry fort he "German 
screenshot" but the screenshot should be self-explaining I hope).

- The problems are:
--- First thing: As an administrator I can't forbid the  right "Admin". Yes, I 
can disable this right. But if I open the menu 
 "Page Administration: Rights: Page & Children" a second time the former 
set right "is lost" (see screenshot).
--- Second thing: Despite oft he defined page permission rights a user of the 
group "XWikiAllGroup" kann read and edit 
 the page "Administration". Much worse, this user can also open the 
"Administer Page" menu and he can change the permissions.

I found no corresponding exceptions in the xwiki.log, therefore, from a 
technical point of view every thing seems to be okay.

Now, I have no more ideas what elso to do :(

Kind regards, Thomas

Re: [xwiki-users] News panel wizard

[Hamster]

We have an "Announcement Page" which is included in the dashboard which
everybody is using.

So when someboy logs in, they will see the latest announcements directly.

No extensions required :-)



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/News-panel-wizard-tp7603705p7603736.html
Sent from the XWiki- Users mailing list archive at Nabble.com.

[xwiki-users] [myxwiki] new wiki request

[Alice Li]

Description: The College Transition Collaborative is a non-profit organization 
based out of Stanford University that conducts research to improve well-being 
and achievement for college students. We’d like to create an internal wiki for 
team operations and knowledge sharing. Thank you!

Owner Name: xali

Wiki Name: ctc

Re: [xwiki-users] [myxwiki] new wiki request

[Thomas Mortagne]

You can access your new wiki on http://ctc.xwiki.org

Enjoy !

On Wed, May 3, 2017 at 4:22 PM, Alice Li  wrote:

> Description: The College Transition Collaborative is a non-profit
> organization based out of Stanford University that conducts research to
> improve well-being and achievement for college students. We’d like to
> create an internal wiki for team operations and knowledge sharing. Thank
> you!
>
> Owner Name: xali
>
> Wiki Name: ctc
>



-- 
Thomas Mortagne

Re: [xwiki-users] Question to skins and inheriting files

[Interaktionsweise]

Thank you very much for your explanation!
I did not understand this behavior correctly from the documentation.

Regards,
sthag
Am 02.05.2017 17:31:29 schrieb Thomas Mortagne :
On Tue, May 2, 2017 at 5:30 PM, Thomas Mortagne
wrote:

> On Tue, May 2, 2017 at 5:16 PM, Interaktionsweise <>
> ne...@interaktionsweise.de> wrote:
>
>> I can file a bug report.
>> Just wanted to add something I forgot to mention and make sure it is
>> still a bug.
>>
>> If I leave the field "parent" within skin.properties empty the error
>> occurs.
>> If I explicitly add flamingo "parent=flamingo" the error does not occur.
>>
>> From the description in the documentation I assumed it is not necessary
>> to add the parent because it is defined in "xwiki.defaultbaseskin" within
>> "xwiki.cfg".
>>
>> Is it a bug or a feature?
>>
>
> A feature. When you set parent to empty string you explicitly indicate you
> don't want to inherit any skin (i.e. you disable xwiki.defaultbaseskin).
> This is actually important for a skin made from scratch (like flamingo
> which do exactly that) which would be broken if the default base skin is
> changed.
>

If you want to inherit xwiki.defaultbaseskin then don't put any
skin.properties or an empty one.


>
>
>>
>> Regards,
>> sthag
>> Am 02.05.2017 15:20:52 schrieb Thomas Mortagne
>> >:
>> Looks like a bug to me. Would be great if you could create an issue on
>> http://jira.xwiki.org and detail the steps to reproduce it.
>>
>> On Tue, May 2, 2017 at 2:50 PM, Interaktionsweise
>> wrote:
>> > Hi,
>> >
>> > I tried two skins with the same edits.
>> > I only changed the file companylogo.vm and added a file
>> logo-company.png.
>> > The skin.properties file points to flamingo as parent.
>> >
>> > In one skin folder I copied all of the flamingo files and edited as
>> described.
>> > If I change the skin for the wiki everything is as expected and the
>> changes show up with the newly set skin.
>> >
>> > The other skin folder only has the edited files
>> > _ companylogo.vm
>> > _ logo-company.png
>> > _ skin.properties
>> >
>> > If I switch to this skin, tested changing it only for one page, I see
>> an error "You are not allowed to view this page or perform this action"
>> after pressing save.
>> > If I try to switch to the changed page from the wiki frontend, I only
>> see a blank page.
>> >
>> > Is there something I'm doing wrong? Why is there no inheritance?
>> >
>> > Regards,
>> > sthag
>> >
>> >
>> > Interaktionsweise [https://interaktionsweise.de] ·
>> ne...@interaktionsweise.de [mailto:ne...@interaktionsweise.de]
>> > Am 02.05.2017 10:32:23 schrieb Thomas Mortagne :
>> > On Tue, May 2, 2017 at 9:55 AM, Interaktionsweise
>> > wrote:
>> >> Hi,
>> >>
>> >> I'm trying to create a new skin. I followed the section Skins within
>> the Developer's Guide and also Platform Features / Skins.
>> >> The article "How to create a new skin" says to copy the whole colibri
>> (should be flamingo by now) skin folder and make an example change. Then
>> there is a part about skin.properties. The property "parent" indicates a
>> skin to inherit from. It says that it always has a value, even if I don't
>> explicitly enter one for myself it will inherit from WAR or whatever is
>> configured in "xwiki.defaultbaseskin".
>> >
>> >> Does that mean I don't have to copy the whole flamingo folder if I
>> reference flamingo as "parent"? This way I could only create a custom named
>> folder within the xwiki/skins folder with the skin.properties file and for
>> example a logo.png file which would replace the flamingo logo.png file.
>> >
>> > Yes you can inherit from Flamingo, no need to duplicate it if you just
>> > want to customize some templates only.
>> >
>> >> I don't understand the behavior and the functionality of this
>> inheriting and parent child relation of skins from the articles in the
>> documentation. Why have a parent if I copy the whole skin folder anyways?
>> >>
>> >> Regards,
>> >> sthag
>> >
>> >
>> >
>> > --
>> > Thomas Mortagne
>>
>>
>>
>> --
>> Thomas Mortagne
>>
>
>
>
> --
> Thomas Mortagne
>



--
Thomas Mortagne

Re: [xwiki-users] Question to skins and inheriting files

[Vincent Massol]

> On 3 May 2017, at 09:20, Interaktionsweise  wrote:
> 
> Thank you very much for your explanation!
> I did not understand this behavior correctly from the documentation.

Would be awesome if someone (you? :)) could update the documentation to make it 
more clear! 

Thanks!
-Vincent

> Regards,
> sthag
> Am 02.05.2017 17:31:29 schrieb Thomas Mortagne :
> On Tue, May 2, 2017 at 5:30 PM, Thomas Mortagne
> wrote:
> 
>> On Tue, May 2, 2017 at 5:16 PM, Interaktionsweise <>
>> ne...@interaktionsweise.de> wrote:
>> 
>>> I can file a bug report.
>>> Just wanted to add something I forgot to mention and make sure it is
>>> still a bug.
>>> 
>>> If I leave the field "parent" within skin.properties empty the error
>>> occurs.
>>> If I explicitly add flamingo "parent=flamingo" the error does not occur.
>>> 
>>> From the description in the documentation I assumed it is not necessary
>>> to add the parent because it is defined in "xwiki.defaultbaseskin" within
>>> "xwiki.cfg".
>>> 
>>> Is it a bug or a feature?
>>> 
>> 
>> A feature. When you set parent to empty string you explicitly indicate you
>> don't want to inherit any skin (i.e. you disable xwiki.defaultbaseskin).
>> This is actually important for a skin made from scratch (like flamingo
>> which do exactly that) which would be broken if the default base skin is
>> changed.
>> 
> 
> If you want to inherit xwiki.defaultbaseskin then don't put any
> skin.properties or an empty one.
> 
> 
>> 
>> 
>>> 
>>> Regards,
>>> sthag
>>> Am 02.05.2017 15:20:52 schrieb Thomas Mortagne
 :
>>> Looks like a bug to me. Would be great if you could create an issue on
>>> http://jira.xwiki.org and detail the steps to reproduce it.
>>> 
>>> On Tue, May 2, 2017 at 2:50 PM, Interaktionsweise
>>> wrote:
 Hi,
 
 I tried two skins with the same edits.
 I only changed the file companylogo.vm and added a file
>>> logo-company.png.
 The skin.properties file points to flamingo as parent.
 
 In one skin folder I copied all of the flamingo files and edited as
>>> described.
 If I change the skin for the wiki everything is as expected and the
>>> changes show up with the newly set skin.
 
 The other skin folder only has the edited files
 _ companylogo.vm
 _ logo-company.png
 _ skin.properties
 
 If I switch to this skin, tested changing it only for one page, I see
>>> an error "You are not allowed to view this page or perform this action"
>>> after pressing save.
 If I try to switch to the changed page from the wiki frontend, I only
>>> see a blank page.
 
 Is there something I'm doing wrong? Why is there no inheritance?
 
 Regards,
 sthag
 
 
 Interaktionsweise [https://interaktionsweise.de] ·
>>> ne...@interaktionsweise.de [mailto:ne...@interaktionsweise.de]
 Am 02.05.2017 10:32:23 schrieb Thomas Mortagne :
 On Tue, May 2, 2017 at 9:55 AM, Interaktionsweise
 wrote:
> Hi,
> 
> I'm trying to create a new skin. I followed the section Skins within
>>> the Developer's Guide and also Platform Features / Skins.
> The article "How to create a new skin" says to copy the whole colibri
>>> (should be flamingo by now) skin folder and make an example change. Then
>>> there is a part about skin.properties. The property "parent" indicates a
>>> skin to inherit from. It says that it always has a value, even if I don't
>>> explicitly enter one for myself it will inherit from WAR or whatever is
>>> configured in "xwiki.defaultbaseskin".
 
> Does that mean I don't have to copy the whole flamingo folder if I
>>> reference flamingo as "parent"? This way I could only create a custom named
>>> folder within the xwiki/skins folder with the skin.properties file and for
>>> example a logo.png file which would replace the flamingo logo.png file.
 
 Yes you can inherit from Flamingo, no need to duplicate it if you just
 want to customize some templates only.
 
> I don't understand the behavior and the functionality of this
>>> inheriting and parent child relation of skins from the articles in the
>>> documentation. Why have a parent if I copy the whole skin folder anyways?
> 
> Regards,
> sthag
 
 
 
 --
 Thomas Mortagne
>>> 
>>> 
>>> 
>>> --
>>> Thomas Mortagne
>>> 
>> 
>> 
>> 
>> --
>> Thomas Mortagne
>> 
> 
> 
> 
> --
> Thomas Mortagne

Re: [xwiki-users] [myxwiki] new wiki request

[Hamster]

When we tested XWiki for the first time, we tested the "ZIP Package". It's
easy to use and you can install Extensions, play with programming, etc.

Long Term Support 8.4.5
http://www.xwiki.org/xwiki/bin/view/Download/DownloadVersion/?projectVersion=8.4.5

Stable 9.3.1
http://www.xwiki.org/xwiki/bin/view/Download/DownloadVersion/?projectVersion=9.3.1



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/myxwiki-new-wiki-request-tp7603702p7603729.html
Sent from the XWiki- Users mailing list archive at Nabble.com.

Re: [xwiki-users] User renamed space - now inaccessible

[D R]

Hi again,

does nobody have an idea?

The other guys in the wiki team lose faith because a simple rename can have
such a huge impact on the contents and the restore feature does not work.

Regs, Dennis

2017-04-28 11:31 GMT+02:00 D R :

> Hi everybody,
>
> I have a huge issue here with our XWiki 7.4.4 instance running on CentOS 7
> / Tomcat 8.0.33.
>
> We had a document space "Customer Docs" in a sub wiki "Customers" with
> several nested docs (customers with more nested docs).
>
> A user managed to break the whole document space by renaming it to "@Spain
> Wiki". When accessing the page now the browser throws a "This page does not
> work,  has redirected too often" (translated from German).
>
> I see the pages with the old names in Page Index under deleted documents
> but when I click the actions icon (which says it can't be restored because
> it already has been recreated?!) I get the same browser error.
>
> Is there any way I can restore the old document space?
>
> (Restoring a database backup will not work because too many other things
> have been changed in other parts of the wiki, the renaming was done on
> April 20th but discovered today)
>
> Regs,
> Dennis
>

[xwiki-users] Question about activating css source maps and cache cleaning

[Interaktionsweise]

Hi,

I've been wondering if there is something else do to to get the source maps for 
css enabled.
I followed the instructions on the Extension page of the "LESS Module".
I edited and un-commented the property "lesscss.generateInlineSourceMaps = 
true" within "xwiki.properties".
Afterwards I restarted the server service.
I also switched color themes to clean the cache.
But I cannot see a change in the developer views of Chromium or Firefox. Every 
style still refers to style.css.

At this point I also want to ask about the usage of the manual cleaning method 
for the cache.
The documentation says that I can use the LESS CSS script service and provides 
a snippet

{{velocity}}
 $service.lesscss.clearCache()
{{velocity}}

But where should I put this?
The section "Script Service" on the LESS Module page only has a link to the 
source code on GitHub. I'm still digging into the XWiki world so maybe it is 
just a matter of time if can figure it out. The whole velocity less scripting 
thing is a huge topic though.

Regards,
sthag

Re: [xwiki-users] Question about activating css source maps and cache cleaning

[Ecaterina Moraru (Valica)]

To be honest I don't know about the properties you are asking about so I'm
not sure if this will solve your problem, but when I want the LESS parser
to activate I usually go in a Flamingo Theme and I re-save it (not sure if
I need to be in the "Advanced" section or if the theme needs to be active).

On Wed, May 3, 2017 at 10:49 AM, Interaktionsweise <
ne...@interaktionsweise.de> wrote:

> Hi,
>
> I've been wondering if there is something else do to to get the source
> maps for css enabled.
> I followed the instructions on the Extension page of the "LESS Module".
> I edited and un-commented the property "lesscss.generateInlineSourceMaps
> = true" within "xwiki.properties".
> Afterwards I restarted the server service.
> I also switched color themes to clean the cache.
> But I cannot see a change in the developer views of Chromium or Firefox.
> Every style still refers to style.css.
>
> At this point I also want to ask about the usage of the manual cleaning
> method for the cache.
> The documentation says that I can use the LESS CSS script service and
> provides a snippet
>
> {{velocity}}
>  $service.lesscss.clearCache()
> {{velocity}}
>

In theory this can be put inside any page, save and view. Make sure you
properly close the {{/velocity}} macro (although might work as well).

Thanks,
Caty


> But where should I put this?
> The section "Script Service" on the LESS Module page only has a link to
> the source code on GitHub. I'm still digging into the XWiki world so maybe
> it is just a matter of time if can figure it out. The whole velocity less
> scripting thing is a huge topic though.
>
> Regards,
> sthag
>
>

Re: [xwiki-users] User renamed space - now inaccessible

[D R]

Hi again,

meanwhile I found out that the restore process doesn't ignore the redirect
object on the renamed pages.

So am I right that I need to do the following:
1. Delete all pages that have the redirect object
2. Use recycle bin to restore the complete document space

If I'm wrong please let me know, otherwise please tell me how to achieve
the above without going throuth each document. Via database?

Thanks and regards,
Dennis

2017-05-03 9:53 GMT+02:00 D R :

> Hi again,
>
> does nobody have an idea?
>
> The other guys in the wiki team lose faith because a simple rename can
> have such a huge impact on the contents and the restore feature does not
> work.
>
> Regs, Dennis
>
> 2017-04-28 11:31 GMT+02:00 D R :
>
>> Hi everybody,
>>
>> I have a huge issue here with our XWiki 7.4.4 instance running on CentOS
>> 7 / Tomcat 8.0.33.
>>
>> We had a document space "Customer Docs" in a sub wiki "Customers" with
>> several nested docs (customers with more nested docs).
>>
>> A user managed to break the whole document space by renaming it to
>> "@Spain Wiki". When accessing the page now the browser throws a "This page
>> does not work,  has redirected too often" (translated from
>> German).
>>
>> I see the pages with the old names in Page Index under deleted documents
>> but when I click the actions icon (which says it can't be restored because
>> it already has been recreated?!) I get the same browser error.
>>
>> Is there any way I can restore the old document space?
>>
>> (Restoring a database backup will not work because too many other things
>> have been changed in other parts of the wiki, the renaming was done on
>> April 20th but discovered today)
>>
>> Regs,
>> Dennis
>>
>
>