Christopher, Wow, you guys have done a lot of work on this. I can imagine the efforts that went into analyzing and documenting the details.
I quickly looked at a few things, and I can see you have a lot of useful info. Thank you for the link. The main issue I see (with BMC's documentation) is that a lot of the information (but not all) is there in bits and pieces all over the place. BMC never puts it together in a place for you to understand the big picture in full and to get an understanding of implications of various choices. I see that with great diagrams etc you have tried to accomplish exactly that. I will be going back to your site a lot. I am guessing that your advanced training (PhD) may have pushed you towards ripping this beast apart to understand it and fully utilize it, rather than confining yourself and your implementation to the limited understanding that BMC offers in its doc. :) Thanks again. I will share with you anything useful I may come across at my end. --- strauss <[EMAIL PROTECTED]> wrote: > You are welcome to study all of the multi-tenancy > docs that we have put > online so far, as we continue to refine our > customizations to IM to get > it to work the way we need it to. All of the > multi-tenancy docs and the > new permissions write-up I "finished" today are at > http://arsweb4.ars.unt.edu/index_prod.htm in the > section titled > "UNT-Specific Documentation for Multi-Tenancy in the > UNT BMC Remedy ITSM > 7.x system." We are still trying to beat some of the > cross-company > assignment problems into submission. There is even a > new explanation of > our initial implementation of SLM 7.1, which is > almost as much fun to > work with as multi-tenancy. In fact, it has to work > very differently in > a multi-tenancy environment, and we expect it to > evolve a lot over the > coming year as we learn more about it. > > Let me know if got any of the concepts wrong - they > are so well > documented (NOT), and some of my reverse-engineering > efforts have been > superficial due to lack of time/resources that were > instead spent fixing > bugs in the OOTB app that never should have left the > developers' > workstations. I must admit that we have had trouble > understanding some > of the implications of our multi-tenancy model until > real users started > trying to do real work, and found that they could > not. We didn't realize > just how shallow the multi-tenancy capabilities of > the OOTB app really > are until we got it into production. > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > > > -----Original Message----- > > From: Action Request System discussion > list(ARSList) > > [mailto:[EMAIL PROTECTED] On Behalf Of Rabi > Tripathi > > Sent: Monday, June 23, 2008 10:58 PM > > To: arslist@ARSLIST.ORG > > Subject: ITSM 7: Multitenancy, Permissions, Roles. > Need OOB info and > > customization ideas > > > > Hi folks, > > I am looking at extending the ITSM 7's scheme for > data > > and rules partitioning (in other words, > permissions) > > to satisfy a customer's requirements. > > > > I am looking for info on ITSM 7's OOB capabilities > as > > well ideas for modifications/enhancements. > > > > I need to enhance the per company scheme of > setting > > data access permissions to take it to business > units > > within companies. > > > > I also need to enhance specification and > maintenance > > of access rules for data to be more granular and > less > > onerous at the same time. > > > > The main gaps between what customer needs and > what's > > in ITSM 7 are: > > (1)multi-tenancy goes only so far. If a company is > > supporting many other companies, business units > within > > those companies can not be segregated for data > access > > etc. In the customer's world, per company is not > > specific enough. > > > > (2)if you use recommended solution of having > business > > units themselves defined as companies, it gets > > awkward, for the simple reason that this is a > > workaround, not a good solution. Bob Backline may > > need access to 10 BUs within a company and 20 in > > another. Who's going to maintain his and his > > colleagues access list. He can't see their tickets > > together in his console. > > Plenty of other issues, such as reports etc. It > will > > be harder to do anything to a company as a whole. > > > > (3)Company access can be specified at people > level, > > not group/organization level. > > > > (4)Documentation issue--whatever capabilities ITSM > has > > for data/rules partitioning is not explained in > full > > anywhere . (see my list as to what I have seen so > far) > > > > > > ****So, I am looking for anything that will help > me > > fully understand OOB capabilities*** And any ideas > on > > customization to further enhance how tenancy, > roles > > etc can better segregate data and allow better > control > > of access to system's features. Ok, I am being > rather > > vague here...but if not fresh ideas from your mind > > just for my purpose...I'm at least looking for > > anything that somebody has already done in these > > areas. > > > > To understand OOB, I have so far looked at: > > -the "guide to multitenancy" pdf doc from BMC > > -the docs from advanced ITSM 7 trainings for > partners, > > especially the "core" training, volume 2 > > -of course the regular pdf manuals, especially the > > config guide and user guide > > -ITSM 7 architecture pdf document > > > > ..and yes I still think the *full* picture of OOB > > capability does not emerge, especially how > tenancy, > > app permissions, roles etc intersect or work > > together...at least not in a way this mortal feels > > satisfied. Not if a way I can fully explain it to > my > > customer. > > > > I may have just gotten old compared to last year, > but > > I find it convenient to deny and ignore this > development. > > > > > > > > > > > _______________________________________________________________________ > > ________ > > UNSUBSCRIBE or access ARSlist Archives at > www.arslist.org > > Platinum Sponsor: www.rmsportal.com ARSlist: > "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at > www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where > the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
