find, if the user have rights to WebHome page not for entire space.
WebPreferences has object global
rights and i think there you have to do some sql query to find out, if user
have rights or not.
Jan
On 12/17/07, *Bjørnar Libæk* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I
Sergiu Dumitriu wrote:
#if($whome.hasAccessLevel(view,$context.getUser()))
Ok, I tried this, but now the method returns true every time... Even
when explicitly adding an access rule denying view access for a specific
user, the method returns true.
Vincent Massol wrote:
(...)
I totally agree with Brandon. I actually gave up looking for the
documentation yesterday, thinking that it was probably not moved to
the
new site yet.
I'd like more details on this. What product were you looking
documentation for when you gave
Did you solve this?
I got the same problem when upgrading from 1.1 M4 to 1.1.2. When editing
global and space rights, the button add access right entry in the
GlobalRightsEditorWelcome panel was missing.
I found a workaround to this by opening the WebPreferences page for the
space a wanted to
://drift.nerdjeje.no/~libak/xwikiscreenshots/users_opera.png
Bjørnar
Bjørnar Libæk wrote:
I have seen som problems when using Firefox 3 (beta 5) for linux
(Ubuntu), together with xwiki 1.4 (toucan skin):
-Tables in e.g. user administration is not showing correctly
-When looking at a group page
their own fonts...' setting under 'Preferences'
'Content' 'Advanced'.
On Fri, Jun 6, 2008 at 10:59 AM, Bjørnar Libæk [EMAIL PROTECTED] wrote:
I have seen som problems when using Firefox 3 (beta 5) for linux
(Ubuntu), together with xwiki 1.4 (toucan skin):
-Tables in e.g. user
Guillaume Lerouge wrote:
(...)
I think that it's due to an issue in the CSS used to switch from the
standard Toucan skin to the coloured ones. I'd advise either of those
solutions :
1. Least recommended : switch back to the grey skin for now
2. Most recommended : use Firebug and / or
As a lead to anyone wanting to look into this, by eliminating the import
statements in style-blue.css, the problems disappear. I did:
shell cat style.css css/colors/blue.css style-blue-test.css
When selecting style-blue-test.css in the skin object, everything looks
fine. I guess this has
a simple css example to reproduce firefox'
removal of the and + operators, but had no success with that. So the
problem is likely more complex..
Bjørnar
Bjørnar Libæk wrote:
As a lead to anyone wanting to look into this, by eliminating the import
statements in style-blue.css, the problems
