OK, 2 days later I came up with an idea that's better from both a user
interface and module development point of view.
Using Announce as an example, the old grouping concept would've forced the
user to make 2 extra desicions when creating an announcement - what category
to assign and what groups should be able to view the announcement. That
would mean extra listboxes on the page and more complexity in terms of
useability.
What if we implemented the group-based restrictions by category instead?
That way the user has one choice to make -- "what category(ies) does the
announcement belong to? " That way, they don't -have- to know that
announcements in "Financial Reports" can only be seen by users that are
members of the Accounting, Oversight, and Investors groups. The application
immediately becomes more idiot-proof!
I d/l'ed a CVS tarball yesterday and I'm in the process of modifying the
FatCat code to see if this'll work. Essentially I'm thinking that Group
Ownership would be managed in categoryForm(). Then all category-based
accesses would be filtered based on group membership. If modules need to
generate their own lists of stuff, they can use much the same method as
Idea#1. The table would just be managed via FatCat.
But don't wait 'til I'm finished, let me know what you think of this plan.
-Eloi-
|
