Our company has discovered what may seem to very serious problems with XOOPS - these may or may not be core related.

A - Group Block Assignment:

First of all the group scheme is very confusing and is not adequate. The rational is that group blocks should be independent of other group blocks. I have found this to not be the case. Once you have created a group, that new group and the defualt group (Registered) are always linked with one another. For instance, you have just created a new group named Student:

- if you assigned a block to a Registered group, you have also assigned it to the Student group.

- if you have removed a block from Registered group, you have also removed it from the Webmaster and Student groups.

- If you remove Main Menu from the registered group, you have also removed from it from Registered group.

- If you change the block order (0,1,2,3) of the Main Menu block in the Registered group , you have also altered the Webmaster's block order.

The Registered group is the default and the first level. All subsequent groups must include the Registered group. This does not seem logical if you were to ask the average person. If you are the Webmaster group, you are not associated with Regestered but all other groups must include the Resgistered group. This could rack havoc with any sensible thinking person.


B - Notifications:

If you read the last post of a series of 10 post which the other 9 have not been read, you set the notification flag for that thread to "all read."

To fix this would seemingly be simple - but it will degrade the performance of the entire forum significantly.

I would like to be wrong on both counts -

Regards,

Rick

Rickb, you are wrong, but only in first position

Some philosophy:

Yes, permissions system in XOOPS and users groups in XOOPS are far from excellent... Groups are independent and haven't relations, inheritance of group righths also missing,righths list can be expanded on core-level

But you can understand some easy thing
- any default behaivors can be changed
- group membership uses cumulative model or rights, not inheritance with redefine, thus - you can define in addional user groups only extended rights over base group and have user in any amout of special groups (for specially added rights) and in common "registered users" or clone in every special group all rights from base group, add special and exclude member of these "fat" groups from base group.
It will solve you misinterpretation of user permissions... but, AFAIK, positioning (!) of blocks is global parameter and you can't get AB placement for one group and BA for another. It's one of (many more existing) weakenesses in XOOPS... But ordinary user can't understand even current "CMS for dummies", can we can more say about future really flexible system

Flame(){
XOOPS Core Team prefer to implement useless for real boys bells and whistles instead of converting XOOPS into power CMS (they even doesn't know. what in "Dublin Core")
}

The behaviour of custom groups (at least in 2.0.13) is independant. However, they are treated the same way as anonymous user group - when you install a new module, members of custom groups have no access rights. You have to go in and assign rights to them manually.

The weighting of a block (vertical position) is the same for all user groups, you can't have different weightings for different groups.

I'd kill to be able to set block positions according to a globally available list of categories, as well as on a per-module basis. Would solve my perpetual problem of department x, y and z each wanting their own layout.