[Phpgroupware-developers] Email pagination patch and ACL Groups patch #434

[Shamim Islam (phpdocdeveloper)]

Having worked with groupware extensively over the past 15 years, one of the key
features missing from phpgroupware has been the ability to assign roles to users
that do not assign group membership. Where permissions are the only thing 
assigned
and the acutal membership of the group is opaque to the casual viewer.

Also, another thing that is missing from groupware, is the ability to view only
those members that share membership with you.

To this end, I hve submitted patch 434, based on RC4, which allows for the 
creation
of a separate type of group, called an ACL group which has opaque membership
traits, and is useful to assign permissions to a group of individuals. The 
original
groups are still intact.

No structural changes were required, but a new account_type of 'a' was added. In
addition, I needed to add a few translations to the langauge table.

group type
membership group
acl group

Also, I modified the default for adding a new account to have NO permissions on 
any
applications, since the suite kept assigning permissions for practically all
available applications for new users, which defeats the purpose of having 
groups to
assign permissions by anyway. It takes far too long to remove all those
permissions. I did not find anywhere where I could set the default permissions.
(And my default group had almost none to start with).

I also, added 2 new public functions to the ACL machinery to pull out complete
group information for a given user (all group attributes are pulled), and to
retrieve complete co-membership information (all users that one user has groups 
in
common with that are 'g' account type groups.). Said information is useful in 
the
HR application. I am in the process of making the HR visibility comply with
membership. I believe this would allow PhpGroupware to be more mature by 
allowing
membership in different domains to be invisible to each other.

I have also been thinking that this patch is incomplete as it stands, because
another thing that I have had the ability to use in groupware, is the ability to
deny permissions based on group membership. To this end, I am thinking of adding
a 'd' account type and modifying the necessary machinery to handle this.

These change I believe will bring PhpGroupware to the mainstream in terms of
corporate security and usability.

Please feel free to comment.

Finally, I have corrected a few pagination bugs in the email system which now
always correctly paginates to the correct start message, even when there are no
messages, both in the INBOX as well as any other. The old version would paginate
inconsistently if you jumped to the end and then moved to a previous screen; or 
if
you deleted a screen full of messages, it would come back with a screen of no
messages just to inform you that all those messages had been in fact deleted.

Feel free to comment on these as well.

I hope to see these changes in RC5 or the next version, especially since I 
believe
it does not detract from the current format of PhpGroupware but adds much needed
value to the ACL system.

The only thing missing in the ACL I think is groups being members of groups, 
but I
believe this is unnecessary complexity and can be readily avoided by proper
security structure.

Thanks for your time. Hope to hear back soon.
--
Shamim Islam
Systems Engineer
address@hidden