Re: A question on Remedy 6.3

[Rainer Volkmer]

Hi,

check the rowlevel-accces on SHR:People, should be given by AssigneeGroup 
(fieldid 112).

Kind regards
Rainer

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of John Atherly
Sent: Thursday, April 26, 2012 9:50 PM
To: arslist@ARSLIST.ORG
Subject: Re: A question on Remedy 6.3

**
The permission on QA and Prod matched.   But while closing the window on the 
SHR:People form production I click save by mistake even though I made no 
changes to the form or permission.   How it is working!I forgot about the 
trick of just opening and saving it.

Thanks everyone
_

John Atherly  |   APC by Schneider Electric   |  Information, Process & 
Organization (IPO)  |   Remedy Administrator / Developer
Phone: +305-266-5005 ext. 237  |
Email: john.athe...@apcc.com  |   Site: 
www.apc.com/  |   Address: 703 Waterford Way, Suit 850, 
Miami, FL 33126 USA
*** Please consider the environment before printing this e-mail


LJ LongWing mailto:lj.longw...@gmail.com>>
Sent by: "Action Request System discussion list(ARSList)" 
mailto:arslist@ARSLIST.ORG>>

04/26/2012 03:22 PM
Please respond to
arslist@ARSLIST.ORG


To

arslist@ARSLIST.ORG

cc

Subject

Re: A question on Remedy 6.3







**
John,
Check the permissions they have to the request ID on Prod…I would bet that they 
don’t have access to everyone elses record…so you likely have assignee in 
there…but not public, or something similar.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of John Atherly
Sent: Thursday, April 26, 2012 12:54 PM
To: arslist@ARSLIST.ORG
Subject: A question on Remedy 6.3

**
First off yes I still have a small group of users that are still on 6.3

I have been asked to look at an issue were users are not getting the list menu 
after they type in a name on a form

I have a form call let say Phone Numbers and on this form is a character field 
in which they can type in a partial name and then an active link fire to set it 
to all Caps.   Then the same active link takes the value in caps and does a 
look up to the SHR:People form to find LIKE matching Full Name and returns the 
needed information.

I have three environment  Dev QA and Production.   If I try it, it works on all 
three servers  but if a standard user tries it, it only works on Dev and QA.  
In the log file I can see it changing to caps and doing the look up but if no 
match is found it set the field to NULL.  If the standard user just types in 
any letter found in their Full Name it will only return their record.  So I 
think it is working it's just that they can not see others SHR:People records.  
  They have view access to the form and read access to Full Name.

I have removed all the workflow and replaced it with a new copy from QA

Both server have submitter lock on

Is there any other server setting that I can not think of since I think this is 
a permission issue on the server level.



Working in 6.3 Admin I really did miss the function of Dev Studio.
_

John Atherly  |   APC by Schneider Electric   |  Information, Process & 
Organization (IPO)  |   Remedy Administrator / Developer
Phone: +305-266-5005 ext. 237  |
Email: john.athe...@apcc.com  |   Site: 
www.apc.com/  |   Address: 703 Waterford Way, Suit 850, 
Miami, FL 33126 USA
*** Please consider the environment before printing this e-mail
_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers 
Are"_

__
This email has been scanned by the Symantec Email Security.cloud service.
__
_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers 
Are"_
_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers 
Are"_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

Re: Menu's open slowly on web (ARS 7.6.4)

[Rainer Volkmer]

Hi,

try to turn of the flash-rendering in midtier-settings:

arsystem.flash.enable_ui_rendering=false

in config.properties (Midtier/WEB-INF/classes)

Kind regards
Rainer

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Support
Sent: Monday, April 16, 2012 5:07 PM
To: arslist@ARSLIST.ORG
Subject: Re: Menu's open slowly on web (ARS 7.6.4)

**
Yes, mid-tier pre-loaded and uses persistant cache.
I don't know about the hot fixes.  I will ask the person who installed the 
servers.
They are using IE8.

But once again, it is not a general complain about performances.  It is 
especially the opening of menu's 

On 16/04/2012 17:02, strauss wrote:
**
Is it safe to assume that your mid-tiers are fully pre-loaded and using 
persistent cache?  Are they on at least service pack 1 with hotfixes, if not 
sp3?  Mid-tier caching on 7.6.04.x is essential to getting decent performance 
out of it, and several of the releases were not up to snuff (and noticeably 
slower than mid-tier 7.1 had been), especially against IE9.  BMC does have a 
fair amount of new documentation on mid-tier configuration and performance 
tuning that will help, but you may have to open an issue with them to get the 
correct hotfixes.

Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Support
Sent: Monday, April 16, 2012 9:49 AM
To: arslist@ARSLIST.ORG
Subject: Re: Menu's open slowly on web (ARS 7.6.4)

**
Thanks again .  Looks like we will have to find a work around here .

On 16/04/2012 16:47, Tauf Chowdhury wrote:
** 7.6.04 does use a bunch of flash objects on their pages now so it's probably 
slower than 7.0 anyway. Also, if your users are on older desktop hardware, the 
process overhead on the desktop may slow down their experience as well. For 
example, if the help desk user has an old p4 with 512mb RAM, the web experience 
will be affected negatively because the browser takes up more memory.
On Mon, Apr 16, 2012 at 10:15 AM, Support 
mailto:supp...@arsmarts.com>> wrote:
Thank you.

They were already using the web, so no difference there.
Indexes should be the same in both versions, but we will double-check.

In fact, it is   well how could I explain this  the "deployment" of the 
menu on the screen that takes a long time (1 to 2 seconds).  It looks like it 
is some kind of visual effect that has been put there on purpose, and we'd like 
to turn it off.

I don't know if I'm clear in what I say here 


On 16/04/2012 15:28, Tauf Chowdhury wrote:
Are they noticing the slowness because they are now using the web
instead of the user tool? If that is the case, that is something they
will need to get used to as web responses can be a bit more costly
than the WUT. If not, maybe take a look at the menus to see if any
indexes are different or missing in the new version. Perhaps there
were some fields that were indexed in your old implementation that
were not OOB.

Sent from my iPhone

On Apr 16, 2012, at 9:21 AM, 
Supportmailto:supp...@arsmarts.com>>  wrote:
Hello List,

In our migration from 7.0.1 to 7.6.4, we have an issue with the speed at
which menu's open (on the web) in 7.6.4.  Indeed, the menu's open really
slowly, and the Call Center people complain that it adds significant
time to call registration.

Anybody met this problem already?
Found a solution?

Thanks.

Kaïs

___
UNSUBSCRIBE or access ARSlist Archives at 
www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the 
Answers Are"
___
UNSUBSCRIBE or access ARSlist Archives at 
www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the 
Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at 
www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the 
Answers Are"



--
Tauf Chowdhury


_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers 
Are"_
_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers 
Are"_
_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers 
Are"_
_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers 
Are"_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"