|
Thanks. J We probably should. The app belongs to
the company and they tend to go to market with services, not software products,
but it is the kind of thing that could help sell consulting jobs.
Unfortunately, there tends to be a disconnect between the internal IT guys (me)
and the “go to market” guys, so I doubt anyone has even considered
it. The major issue with generalizing it is
that there are a bunch of pieces that are somewhat “naïve” and
would not work in other orgs without some thought. For example, we have a
single domain model (ok, empty parent, but it really doesn’t count), so
we get to make a lot of assumptions based on that. We also only create global
groups as that works fine in our model, so we don’t even offer the user
an option there and get to make lots of assumptions about how nesting can work. Still, it is a good idea. Joe K. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe JoeK... quite honestly, it almost sounds
like you could sell this beast. I am sure there are things very specific to
your business, but I expect you could tweak what you have into something others
could use. It sounds pretty cool to me. From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED] I could not agree more with Joe on this
point too. We have a bunch of business rules that work really well for
us, but they definitely aren’t for everyone. For example, most
organizations would not allow all users to create and delete groups willy-nilly
like we do. I can actually change that quite easily via config to
restrict that to a particular group or groups, but the business users want it
the other way. End user maintenance of groups for line of business apps
is very important to the model. The other piece I never mentioned was that
we have a separate app for creating query-based groups as well.
Essentially, the main website for groups is for “ad hoc”
membership. The other app is essentially a batch process that generates
groups based on LDAP queries. Anything that can be built and maintained
based on schema is done that way. We also have about 75 user account
schema additions for pushing in all sorts of data from the HR system to make it
easy to create these groups. We do this with a custom app so that we can
get security and DL groups (the current query-based groups are for DLs only
unless you are talking about the AzMan query groups which isn’t enough
for us) and so we can do custom nesting to accommodate syncing the group
structure to Domino which has bigger limits on group sizes. Joe K. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe I think you need to solve your business
issues before your technical issues. The technology is certainly readily
available to handle this type of work if you want to build it. However, you
need to be able to feed rules into the system to follow or else the systems no matter
how complex will be as worthless as not having anything and not help you as you
stand right now. You must find owners for all groups and
those owners need to be responsible for the membership. Doing this at a
centralized manned level will kill you and be a good way for mistakes to come
in and people get access to things they shouldn't as you indicate. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
This
message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the email by you is prohibited. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. |
