-
"The module access permissions at the user properties are just an extra
convenient way of adding users to the module permissions."
Agreed. This is a nice-to-have. And the User Settings panel is also where the bug exists. Remove the unexpected granting of individual (vs. inherited) permissions based on group membership and the problem is solved.
If I never open up the User Settings panel...
2009-03-06 22:56:46 UTC in Group-Office groupware
-
"The module access permissions at the user properties are just an extra
convenient way of adding users to the module permissions."
Agreed. This is a nice-to-have. And the User Settings panel is also where the bug exists. Remove the unexpected granting of individual (vs. inherited) permissions based on group membership and the problem is solved.
If I never open up the User Settings panel...
2009-03-06 22:56:22 UTC in Group-Office groupware
-
I am sorry to hear that you think valid access control is a minor issue. If we can't trust the site to accurately protect our users' and project's content, then we cannot use it.
2009-03-04 23:07:21 UTC in Group-Office groupware
-
I am sorry to hear that you think valid access control is a minor issue. If we can't trust the site to accurately protect our users' and project's content, then we cannot use it.
2009-03-04 23:06:43 UTC in Group-Office groupware
-
The cause of the problem seems related to the User management panel. Adding a user as member of a group populates the appropriate Module Access check-boxes. However, those check-boxes are solid rather than faded-out, indicating that the permissions are first-order rather than inherited. Removing the user from a group correctly leaves the individually-granted permissions unchanged.
As a result,
2009-03-03 19:07:04 UTC in Group-Office groupware
-
My config.php contains:
$config['register_user_groups']="Registered";
If I import users using csv file, the users are correctly added only to the Registered group without redundantly assigning each user the same permissions as the group.
However, when using the web interface to add an account, the user is added to the group and also individually granted the same permissions as the group...
2009-03-03 02:53:58 UTC in Group-Office groupware
-
When creating a new user account, the Internal group is always granted write access to the calendar.
During installation, in the 'Default user groups' panel, un-selecting "Visible" for Everyone and Internal has no effect.
Write access to all calendars should only be a admin privilege.
2009-03-03 02:37:20 UTC in Group-Office groupware
-
1) Adding a user to a group redundantly adds the individual user to the same read/write access areas as the group.
2) Subsequent removal of user from a privileged-access group does NOT remove the individually-granted permissions. This is the expected behavior, but only if the redundant permissions were granted MANUALLY by the admin.
Adding a user to a group SHOULD NOT redundantly grant...
2009-03-03 02:23:17 UTC in Group-Office groupware
-
Hi Support Crew,
We're just getting started migrating our project -
biospice - to sourceforge. We have an existing Mantis
bug tracker for our project and would like to import,
in some form or another, the data into the SF tracker.
Can you provide us with some pointers on how to
accomplish this? Do you have a script for this, or can
you provide us with the SF tracker db schema?...
2005-11-01 23:40:12 UTC in SourceForge.net
