I see this is still marked [bug report] which I assume means 'no solution yet'.

How do those currently living with the problem learn of a solution when one is found?

scroll down and check next to where you see: "Notify me of new posts in the current thread."

Or

make it a habit to visit the BugTracker

Thanks for the advice sailjapan.

I had the notification set but as you can see there were no posts for a month so I was worried it may have been fixed and not reported here.

I didn't think of BugTracker but have just check and can't see anything there that relates to this issue.

Lastly I don't really know who sticks the [bugreport] label on the topic and which of the several issues covered here was classed as a bug! Of course I hoped it was mine but perhaps not.

This is making development very difficult and I'm running out of ideas of what to check and fix.

On my live site (hosted) when I try to change which groups can view/edit etc topics in the module admin areas for News 1.62 and AMS 2.51, or change which fields can be viewed etc in User Profile's (1.52) module admin area the 'permissions' page rejects the change saying 'Sorry you don't have permission ..' and bounces me to the site's front page. On checking both the module permission page and the database table the changes haven't been made.

On my local development setup (WAMP) which has a copy of the live site brought down regularly these same changes work properly. There must be something different between the live and local sites but I have checked and checked (php.ini, loaded extras, etc) and the few differences there are seem unlikely to cause such a fundamental difference in how XOOPS handles this permission change.

Having persuaded a sceptical client that XOOPS was the way to go they are now becoming concerned there may be hidden problems. I would value any suggestions.

Live (and local where different) site details:

Apache 1.3.41 (1.3.39)
----------------------
XOOPS Version - XOOPS 2.3.2
PHP Version - 5.2.6
MySQL Version - 4.1.22-standard (community-nt)
Server API Version - cgi (cgi-fcgi)
OS Version - Linux (WINNT)

safe_mode - Off
register_globals - Off
magic_quotes_gpc - On
allow_url_fopen - On
fsockopen - On
allow_call_time_pass_reference - Off
post_max_size - 12M (8M)
max_input_time - 60
output_buffering -
max_execution_time - 30
memory_limit - 64M
file_uploads - On
upload_max_filesize - 24M

Are you using extra user groups (above the three standard ones)?

Edit: topics merged to have problem together.

Yes I have 46 user groups

Are you as admin part of some of these groups?
I believe that XOOPS' permission system contains a flaw somewhere and that when belonging to several user groups, it depends on the order (not the consecutive id) in the database that some permissions become granted or not depending on if the selected group provides them or not.

In addition to the webmaster account, I have a 'site admin' account that has access to the permission changing areas in modules. These are 2 separate accounts and I log out and back in when changing from one to the other.

The webmaster account is only in Webmaster and Registered Users groups. The 'site admin' account is not in the Webmaster group but is in Registered Users and 9 others.

The problem shows up with either account.

Is it possible to test with the webmaster only in the webmaster group and removed from registered users?

Good idea!

Just tried it but the problem is still there. Keep the ideas coming, there must be something causing this. Probably something really simple!