Joe,
In some cases, the oversights of BMC in this release of ITSM are so huge
that you have no choice but to customize things to some degree. While
best practice is to avoid directly touching the OOTB forms, there are
some important customizations you have to make. For example, we had to
change pretty much all of the applications so that the Login Name field
would be available for entering Incidents/Problems/Changes. I have a 12
page Word document listing everything that had to be done to get the
Login Name field back.
The permissions are another major problem that has to be customized.
There is no way we can let our users have as much access as ITSM
currently gives them. However, rather than removing all permissions, I
prefer to set the groups of affected users to hidden rather than
removing their permission entirely. That way if the group they are in
somehow references data on those other forms they can still pull it, but
they can't access those forms directly.
Thanks,
Shawn Pierson
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Tuesday, June 05, 2007 6:59 PM
To: arslist@ARSLIST.ORG
Subject: Re: Design???? Feature??? Oversight?? Bug?
**
Roger,
I wouldn't change permissions as such. It looks like with every
patch, there are some very basic fundamental changes to the ITSM
application functionality. From the past fixes I have seen these changes
range from things like definition change on forms, to changes in
qualification on table fields etc.
If you modify the current existing OTB workflow, you are likely
to end up with additional work if you need to install any of the patches
that may be released in the future to address the same issue. You would
be better off reporting such issues and leaving them untouched unless
they render your system unusable if not touched.
Given that, I think Rick's idea is better than making a
structural change to the application even if it is alteration of
permissions. Rick's idea involves altering application data, which could
be easily rolled back later if a patch is released to fix the issue.
I am totally with Christopher.. I did question similar design
features with their frontline and got pretty vague responses on why its
been done that way. One such area is the fact that they have the
addition of site information unique to a company meaning that 2
companies can't really share the same site. The good news though is that
you can work around that and go to the site configuration and add
another company to that site. This could have been better designed to
have it work both ways to either add a site to 2 companies or to go to
that site and make 2 companies associated with that site.
At least at the incident and problem application level they
haven't enforced that restriction and kept it just at the data
configuration level.
In today's world do they really think its a good idea to
restrict a site to just one company?? That's hardly practical. Count the
number of companies that are merging where they operate as individual
companies but might have a common sales department.
We too have our test read users receiving a number of
notifications that they don't have access. I don't even want to raise a
issue regarding that as I'm pretty sure what their response would be..
Or maybe I should to be one of the many who might have already raised
this as an issue so that they do something about it..
Joe
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Roger Justice
Sent: Tuesday, June 05, 2007 7:10 PM
To: arslist@ARSLIST.ORG
Subject: Re: Design???? Feature??? Oversight?? Bug?
** I found the same thing and tried to use permission on
the applications to reduce the potential issue. The client decided they
wanted a large button in the middle of the home page that will take the
requesters to the Requester Console and this has eliminated any one
trying the other urls in the application list since most users just want
their problem fixed and they don't dig like us technology people.
-----Original Message-----
From: Joe D'Souza
To: arslist@ARSLIST.ORG
Sent: Tue, 5 Jun 2007 6:10 pm
Subject: Design???? Feature??? Oversight?? Bug?
First of all I am using ARS V7.0.1 Patch 002 and ITSM
apps (the whole
shebang) V7 patch 003.. We are on SQL server 2K5 SP2 and
on Windows 2K3 SP 2
as well.
If I log into the system using a read user who has
restricted access in the
system I see the Application Administration Console
link. I can click on
this link and that does take me to the next
administration page.. here off
course it restricts me from going further complaining
that I don't have
admin rights if I try to click on any of the Create or
View buttons/URL's.
Why are read users even allow to go so far though? Is it
by design that they
have allowed users to go that far? Is there some sort of
benefit that I am
overseeing?
Another area where users are able to intrude where they
should have not been
able to go to are certain parts of the Foundation
Elements.. These users can
click the Overview Console link of the Foundation
Elements, and see Other
Applications, pull down that menu and click on links
like Incident
Management and then get errors like "ARERR [353] You
have no access to form
: HPD:Incident Management Console"
They can even click on the CMDB link here and navigate
to most parts of the
CMDB consoles and get those no access errors there again
but some of the
consoles are open to these users..
Can any of you guys running these same applications,
reproduce this or is it
just me?
Joe
PS: Most of my users have been mass loaded using a
utility provided by
Remedy that I once discussed about about 3 weeks ago.
But even the users
that have been manually created as read users with
restricted access exhibit
the above...
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.7/830 - Release
Date: 6/3/2007
12:47 PM
__20060125_______________________This posting was submitted with
HTML in it___
The information in this e-mail, and any files transmitted with it, is intended
for the exclusive use of the recipient(s) to which it is addressed and may
contain confidential, proprietary or privileged information. If you are not an
intended recipient, you have received this transmission in error and any use,
review, dissemination, distribution, printing or copying of this information is
strictly prohibited. If you have received this e-mail in error, please notify
the sender immediately of the erroneous transmission by reply e-mail,
immediately delete this e-mail and all electronic copies of it from your system
and destroy any hard copies of it that you may have made. Thank you.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
