Re: Salary range - Lead Remedy Solution Architect - Germany
It depends on the location and skills obviously. In Germany I have no idea as that information is not something that is shared. Based on some assumptions, I'd venture a guess between 30k and 70k â¬. Not sure how this helps with my question though :) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Strange behavior of the forms
Hi, everyone, We have a problem when we work with ITSM (ARSystem 7.6.04). From time to time some of controls move from one place to another on the form. which reason could be of this behavior? When we try to flush cache and it helps to solve problem for one group of movements but it causes another... Thanks in advance, Andrey. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Strange behavior of the forms
Andrey, I have done plenty of work within 7.6.04. With control fields you mean hidden fields on forms related to ITSM? I have never seen what you describe. The first thing that come to my mind is with larger developer teams could some of the other developers have moved a field or two? ~ Terje From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Andrey Blednykh Sent: Monday, December 09, 2013 10:13 AM To: arslist@ARSLIST.ORG Subject: Strange behavior of the forms ** Hi, everyone, We have a problem when we work with ITSM (ARSystem 7.6.04). From time to time some of controls move from one place to another on the form. which reason could be of this behavior? When we try to flush cache and it helps to solve problem for one group of movements but it causes another... Thanks in advance, Andrey. _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Strange behavior of the forms
If I am understanding what you are talking about, you might be seeing different views of the same form. That would be the most logical in my mind. HTH, Brian Goralczyk On Mon, Dec 9, 2013 at 5:53 AM, Terje Moglestue te...@mogle.com wrote: ** Andrey, I have done plenty of work within 7.6.04. With control fields you mean hidden fields on forms related to ITSM? I have never seen what you describe. The first thing that come to my mind is with larger developer teams could some of the other developers have moved a field or two? ~ Terje *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Andrey Blednykh *Sent:* Monday, December 09, 2013 10:13 AM *To:* arslist@ARSLIST.ORG *Subject:* Strange behavior of the forms ** Hi, everyone, We have a problem when we work with ITSM (ARSystem 7.6.04). From time to time some of controls move from one place to another on the form. which reason could be of this behavior? When we try to flush cache and it helps to solve problem for one group of movements but it causes another... Thanks in advance, Andrey. _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Strange behavior of the forms
We have 2 application servers and 2 web servers, all of them work with the same database. I want to show you 2 examples of this error/behavior. The same user opens the same incident, but on the different web servers: 1. https://dl.dropboxusercontent.com/u/6766330/Case1.png 2. https://dl.dropboxusercontent.com/u/6766330/Case2.png Понедельник, 9 декабря 2013, 6:12 -06:00 от Brian Goralczyk bgoralczyk.w...@gmail.com: ** If I am understanding what you are talking about, you might be seeing different views of the same form. That would be the most logical in my mind. HTH, Brian Goralczyk On Mon, Dec 9, 2013 at 5:53 AM, Terje Moglestue te...@mogle.com wrote: ** Andrey, I have done plenty of work within 7.6.04. With control fields you mean hidden fields on forms related to ITSM? I have never seen what you describe. The first thing that come to my mind is with larger developer teams could some of the other developers have moved a field or two? ~ Terje From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG ] On Behalf Of Andrey Blednykh Sent: Monday, December 09, 2013 10:13 AM To: arslist@ARSLIST.ORG Subject: Strange behavior of the forms ** Hi, everyone, We have a problem when we work with ITSM (ARSystem 7.6.04). From time to time some of controls move from one place to another on the form. which reason could be of this behavior? When we try to flush cache and it helps to solve problem for one group of movements but it causes another... Thanks in advance, Andrey. _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Adding fields to incident form causes scroll issues
I'm still stuck. It's probably a has it got gas in it problem, but I can't see it. Any help is appreciated. Thanks, Tim -Original Message- From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] Sent: Friday, December 06, 2013 11:17 AM To: 'arslist@ARSLIST.ORG' Subject: Adding fields to incident form causes scroll issues I searched this year's posting for this issue and not finding anything, I am posting my issue. Environment: ARS 7.6.04 SP4 ITSM 7.6.04 SP2 Mid-Tier 7.6.04 SP4 Description: I have a requirement to modify HPD:Help Desk to: Add a row to the Template and Summary fields (from 1 row to 2 rows of display). Add 3 fields to the Incident details area as well. Steps taken: I opened Dev Studio and one-by-one, enlarged (in height) the various panel holders and panels in the following order. z2PLH_ConsoleFlashBoards z2PL_Console z2PLH_Details z2PL_Main Body After each one, I flushed the cache, and tested the view. The maximized mid-tier screen looked good and the reduced sized screen allowed for proper scrolling that let me see all the fields in the view properly and the z2PH_FormControlHolder which contains all the buttons, floated properly to stay below all the visible fields as I tested various sized reduced screens. Next: I enlarged the z2PH_IncidentInformation panel and I added the rows to Template and Summary and added the 3 fields to that panel. I moved the z2PL_Assignment and z2PH_AdditionalIncidentInformation panels down to accommodate the new size of the z2PH_IncidentInformation panel. The relocated panels were within the resized panel holders and panels described in Steps taken. Saved form Flushed MT cache. Open in browser. Maximized window looks fine. BUT NOW if I reduce the screen down the scroll bars appears but it stops adjusting and blocks the last 3 fields in the z2PH_AdditionalIncidentInformation panel. This also occurs in search mode when there is a results list. So it appears that something is not allowing the z2PH_FormControlHolder to move below point x OR something is prohibiting on of the panels from expanding past that point. Anybody have a clue as to what I need to look for here? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Salary range - Lead Remedy Solution Architect - Germany
Hello Dragan, I'm not sure if this is comparable (taxes, benefits, life cost in general...) but here in Paris 100k€ is a lot higher than the salary I would aim for, as an RSA with 15 years of experience. On Mon, Dec 9, 2013 at 10:55 AM, Dragan Levic dragan.le...@dbschenker.comwrote: It depends on the location and skills obviously. In Germany I have no idea as that information is not something that is shared. Based on some assumptions, I'd venture a guess between 30k and 70k €. Not sure how this helps with my question though :) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Adding fields to incident form causes scroll issues
Is it possible that you need to change the size of the form? Have you tried verifying that it is big enough at least? With the form open in DS hit ctrl+alt+m or go to the Layout menu and choose Show Actual View Size and make sure that size is properly sized. I figure it can't hurt to check. HTH, Brian Goralczyk On Mon, Dec 9, 2013 at 8:27 AM, Timothy Powell timothy.pow...@pbs-consulting.com wrote: I'm still stuck. It's probably a has it got gas in it problem, but I can't see it. Any help is appreciated. Thanks, Tim -Original Message- From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] Sent: Friday, December 06, 2013 11:17 AM To: 'arslist@ARSLIST.ORG' Subject: Adding fields to incident form causes scroll issues I searched this year's posting for this issue and not finding anything, I am posting my issue. Environment: ARS 7.6.04 SP4 ITSM 7.6.04 SP2 Mid-Tier 7.6.04 SP4 Description: I have a requirement to modify HPD:Help Desk to: Add a row to the Template and Summary fields (from 1 row to 2 rows of display). Add 3 fields to the Incident details area as well. Steps taken: I opened Dev Studio and one-by-one, enlarged (in height) the various panel holders and panels in the following order. z2PLH_ConsoleFlashBoards z2PL_Console z2PLH_Details z2PL_Main Body After each one, I flushed the cache, and tested the view. The maximized mid-tier screen looked good and the reduced sized screen allowed for proper scrolling that let me see all the fields in the view properly and the z2PH_FormControlHolder which contains all the buttons, floated properly to stay below all the visible fields as I tested various sized reduced screens. Next: I enlarged the z2PH_IncidentInformation panel and I added the rows to Template and Summary and added the 3 fields to that panel. I moved the z2PL_Assignment and z2PH_AdditionalIncidentInformation panels down to accommodate the new size of the z2PH_IncidentInformation panel. The relocated panels were within the resized panel holders and panels described in Steps taken. Saved form Flushed MT cache. Open in browser. Maximized window looks fine. BUT NOW if I reduce the screen down the scroll bars appears but it stops adjusting and blocks the last 3 fields in the z2PH_AdditionalIncidentInformation panel. This also occurs in search mode when there is a results list. So it appears that something is not allowing the z2PH_FormControlHolder to move below point x OR something is prohibiting on of the panels from expanding past that point. Anybody have a clue as to what I need to look for here? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Adding fields to incident form causes scroll issues
I did check that. The form is sized ok. When I view it in Show Actual View Size mode, the 3 fields that get covered are visible and the buttons (z2PH_FormControlHolder) are below the fields. But thanks for the thought. Tim From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Monday, December 09, 2013 10:15 AM To: arslist@ARSLIST.ORG Subject: Re: Adding fields to incident form causes scroll issues ** Is it possible that you need to change the size of the form? Have you tried verifying that it is big enough at least? With the form open in DS hit ctrl+alt+m or go to the Layout menu and choose Show Actual View Size and make sure that size is properly sized. I figure it can't hurt to check. HTH, Brian Goralczyk On Mon, Dec 9, 2013 at 8:27 AM, Timothy Powell timothy.pow...@pbs-consulting.com wrote: I'm still stuck. It's probably a has it got gas in it problem, but I can't see it. Any help is appreciated. Thanks, Tim -Original Message- From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] Sent: Friday, December 06, 2013 11:17 AM To: 'arslist@ARSLIST.ORG' Subject: Adding fields to incident form causes scroll issues I searched this year's posting for this issue and not finding anything, I am posting my issue. Environment: ARS 7.6.04 SP4 ITSM 7.6.04 SP2 Mid-Tier 7.6.04 SP4 Description: I have a requirement to modify HPD:Help Desk to: Add a row to the Template and Summary fields (from 1 row to 2 rows of display). Add 3 fields to the Incident details area as well. Steps taken: I opened Dev Studio and one-by-one, enlarged (in height) the various panel holders and panels in the following order. z2PLH_ConsoleFlashBoards z2PL_Console z2PLH_Details z2PL_Main Body After each one, I flushed the cache, and tested the view. The maximized mid-tier screen looked good and the reduced sized screen allowed for proper scrolling that let me see all the fields in the view properly and the z2PH_FormControlHolder which contains all the buttons, floated properly to stay below all the visible fields as I tested various sized reduced screens. Next: I enlarged the z2PH_IncidentInformation panel and I added the rows to Template and Summary and added the 3 fields to that panel. I moved the z2PL_Assignment and z2PH_AdditionalIncidentInformation panels down to accommodate the new size of the z2PH_IncidentInformation panel. The relocated panels were within the resized panel holders and panels described in Steps taken. Saved form Flushed MT cache. Open in browser. Maximized window looks fine. BUT NOW if I reduce the screen down the scroll bars appears but it stops adjusting and blocks the last 3 fields in the z2PH_AdditionalIncidentInformation panel. This also occurs in search mode when there is a results list. So it appears that something is not allowing the z2PH_FormControlHolder to move below point x OR something is prohibiting on of the panels from expanding past that point. Anybody have a clue as to what I need to look for here? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: [EXTERNAL] Re: Strange behavior of the forms
Andrey: Do you normally have your users clear their local browser caches after you’ve flushed the mid-tier cache? Ideally, to get all of your users in sync with the server, you’d want to have all of them clear their browser caches after you flush the mid-tier cache (though getting them to do as you’ve asked is another problem altogether!) We have 7.6.04, and we find we get the best results when both caches get cleared. Natalie Stroud SAIC @ Sandia National Laboratories ARS-ITSM Reporting Specialist Albuquerque, NM USA nkst...@sandia.govmailto:nkst...@sandia.gov ITSM 7.6.04 SP2 – Windows 2003 – SQL Server 2008 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Andrey Blednykh Sent: Monday, December 09, 2013 5:37 AM To: arslist@ARSLIST.ORG Subject: [EXTERNAL] Re: Strange behavior of the forms ** We have 2 application servers and 2 web servers, all of them work with the same database. I want to show you 2 examples of this error/behavior. The same user opens the same incident, but on the different web servers: 1. https://dl.dropboxusercontent.com/u/6766330/Case1.png 2. https://dl.dropboxusercontent.com/u/6766330/Case2.png Понедельник, 9 декабря 2013, 6:12 -06:00 от Brian Goralczyk bgoralczyk.w...@gmail.commailto:bgoralczyk.w...@gmail.com: ** If I am understanding what you are talking about, you might be seeing different views of the same form. That would be the most logical in my mind. HTH, Brian Goralczyk On Mon, Dec 9, 2013 at 5:53 AM, Terje Moglestue te...@mogle.comsentmsg?mailto=mailto%3ate...@mogle.com wrote: ** Andrey, I have done plenty of work within 7.6.04. With control fields you mean hidden fields on forms related to ITSM? I have never seen what you describe. The first thing that come to my mind is with larger developer teams could some of the other developers have moved a field or two? ~ Terje From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORGsentmsg?mailto=mailto%3aarsl...@arslist.org] On Behalf Of Andrey Blednykh Sent: Monday, December 09, 2013 10:13 AM To: arslist@ARSLIST.ORGsentmsg?mailto=mailto%3aarsl...@arslist.org Subject: Strange behavior of the forms ** Hi, everyone, We have a problem when we work with ITSM (ARSystem 7.6.04). From time to time some of controls move from one place to another on the form. which reason could be of this behavior? When we try to flush cache and it helps to solve problem for one group of movements but it causes another... Thanks in advance, Andrey. _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: [EXTERNAL] Re: Strange behavior of the forms
Andrey, We are in a load balanced environment and a form change was only picked up by two of my three servers. So here we needed to run a arsignal -r servername, so the server could cache the form change. Hope this helps, Howard From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Stroud, Natalie K Sent: Monday, December 09, 2013 10:49 AM To: arslist@ARSLIST.ORG Subject: Re: [arslist] [EXTERNAL] Re: Strange behavior of the forms ** Andrey: Do you normally have your users clear their local browser caches after you’ve flushed the mid-tier cache? Ideally, to get all of your users in sync with the server, you’d want to have all of them clear their browser caches after you flush the mid-tier cache (though getting them to do as you’ve asked is another problem altogether!) We have 7.6.04, and we find we get the best results when both caches get cleared. Natalie Stroud SAIC @ Sandia National Laboratories ARS-ITSM Reporting Specialist Albuquerque, NM USA nkst...@sandia.govmailto:nkst...@sandia.gov ITSM 7.6.04 SP2 – Windows 2003 – SQL Server 2008 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Andrey Blednykh Sent: Monday, December 09, 2013 5:37 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: [EXTERNAL] Re: Strange behavior of the forms ** We have 2 application servers and 2 web servers, all of them work with the same database. I want to show you 2 examples of this error/behavior. The same user opens the same incident, but on the different web servers: 1. https://dl.dropboxusercontent.com/u/6766330/Case1.png 2. https://dl.dropboxusercontent.com/u/6766330/Case2.png Понедельник, 9 декабря 2013, 6:12 -06:00 от Brian Goralczyk bgoralczyk.w...@gmail.commailto:bgoralczyk.w...@gmail.com: ** If I am understanding what you are talking about, you might be seeing different views of the same form. That would be the most logical in my mind. HTH, Brian Goralczyk On Mon, Dec 9, 2013 at 5:53 AM, Terje Moglestue te...@mogle.comsentmsg?mailto=mailto%3ate...@mogle.com wrote: ** Andrey, I have done plenty of work within 7.6.04. With control fields you mean hidden fields on forms related to ITSM? I have never seen what you describe. The first thing that come to my mind is with larger developer teams could some of the other developers have moved a field or two? ~ Terje From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORGsentmsg?mailto=mailto%3aarsl...@arslist.org] On Behalf Of Andrey Blednykh Sent: Monday, December 09, 2013 10:13 AM To: arslist@ARSLIST.ORGsentmsg?mailto=mailto%3aarsl...@arslist.org Subject: Strange behavior of the forms ** Hi, everyone, We have a problem when we work with ITSM (ARSystem 7.6.04). From time to time some of controls move from one place to another on the form. which reason could be of this behavior? When we try to flush cache and it helps to solve problem for one group of movements but it causes another... Thanks in advance, Andrey. _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Adding fields to incident form causes scroll issues
BUT.. This did lead me down another branch of the path you started me on, where I think I have found the problem. It's not the size of the HPD:Help Desk form that's causing the issue. I think it's the size of the panel and related view field on the SHR:Landing Console. Playing with that now, but so far my experiments show me that's where the issue lies. Thanks! From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] Sent: Monday, December 09, 2013 10:32 AM To: 'arslist@ARSLIST.ORG' Subject: RE: Adding fields to incident form causes scroll issues I did check that. The form is sized ok. When I view it in Show Actual View Size mode, the 3 fields that get covered are visible and the buttons (z2PH_FormControlHolder) are below the fields. But thanks for the thought. Tim From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Monday, December 09, 2013 10:15 AM To: arslist@ARSLIST.ORG Subject: Re: Adding fields to incident form causes scroll issues ** Is it possible that you need to change the size of the form? Have you tried verifying that it is big enough at least? With the form open in DS hit ctrl+alt+m or go to the Layout menu and choose Show Actual View Size and make sure that size is properly sized. I figure it can't hurt to check. HTH, Brian Goralczyk On Mon, Dec 9, 2013 at 8:27 AM, Timothy Powell timothy.pow...@pbs-consulting.com wrote: I'm still stuck. It's probably a has it got gas in it problem, but I can't see it. Any help is appreciated. Thanks, Tim -Original Message- From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] Sent: Friday, December 06, 2013 11:17 AM To: 'arslist@ARSLIST.ORG' Subject: Adding fields to incident form causes scroll issues I searched this year's posting for this issue and not finding anything, I am posting my issue. Environment: ARS 7.6.04 SP4 ITSM 7.6.04 SP2 Mid-Tier 7.6.04 SP4 Description: I have a requirement to modify HPD:Help Desk to: Add a row to the Template and Summary fields (from 1 row to 2 rows of display). Add 3 fields to the Incident details area as well. Steps taken: I opened Dev Studio and one-by-one, enlarged (in height) the various panel holders and panels in the following order. z2PLH_ConsoleFlashBoards z2PL_Console z2PLH_Details z2PL_Main Body After each one, I flushed the cache, and tested the view. The maximized mid-tier screen looked good and the reduced sized screen allowed for proper scrolling that let me see all the fields in the view properly and the z2PH_FormControlHolder which contains all the buttons, floated properly to stay below all the visible fields as I tested various sized reduced screens. Next: I enlarged the z2PH_IncidentInformation panel and I added the rows to Template and Summary and added the 3 fields to that panel. I moved the z2PL_Assignment and z2PH_AdditionalIncidentInformation panels down to accommodate the new size of the z2PH_IncidentInformation panel. The relocated panels were within the resized panel holders and panels described in Steps taken. Saved form Flushed MT cache. Open in browser. Maximized window looks fine. BUT NOW if I reduce the screen down the scroll bars appears but it stops adjusting and blocks the last 3 fields in the z2PH_AdditionalIncidentInformation panel. This also occurs in search mode when there is a results list. So it appears that something is not allowing the z2PH_FormControlHolder to move below point x OR something is prohibiting on of the panels from expanding past that point. Anybody have a clue as to what I need to look for here? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Job Opening: Remedy Developer Position Opening Up Soon
You are correct, this is in Atlanta, GA USA (not remote). Full Time Employee position, I will respond with a link directly as soon as it is posted on our Turner.com website for applications. I just wanted to get it out there as soon as possible to receive feedback of interest. Thanks to you all, Amanda Pierce -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jase Brandon Sent: Thursday, December 05, 2013 7:34 PM To: arslist@ARSLIST.ORG Subject: Re: Job Opening: Remedy Developer Position Opening Up Soon TBS??? I bet one dollar it's in Atlanta and no remote. :-) Sent from my iPhone On Dec 5, 2013, at 4:22 PM, Misi Mladoniczky m...@rrr.se wrote: LJ, Don't forget that for some of us the actual country might also be of interest ;-) Best Regards - Misi, RRR AB, http://rrr.se Amanda, It might help people potentially interested in knowing where in the country the job is located, of if it's remote possible. On Thu, Dec 5, 2013 at 2:19 PM, Pierce, Amanda (TBS) amanda.pie...@turner.com wrote: ** I will have a Remedy Developer position opening up soon. Custom Development experience is necessary, ITSM knowledge is a plus. Please send me an email with your resume if you are interested or if you know anyone looking. Thank you, Amanda Pierce Turner Broadcasting System, Inc. amanda.pie...@turner.com _ARSlist: Where the Answers Are and have been for 20 years_ _ __ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years __ _ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Adding fields to incident form causes scroll issues
Tim, If memory serves me correct, there are multiple Panels there on top of each other. Kind of a pain. You have to move the top panel to get to the panel under it. Leverage the Outline + and - in Dev Studio. Work flow hides and unhides these panels. Dale Jones DCS Raleigh, NC 919-523-6034 From: Action Request System discussion list(ARSList) [arslist@ARSLIST.ORG] on behalf of Timothy Powell [timothy.pow...@pbs-consulting.com] Sent: Monday, December 09, 2013 11:44 AM To: arslist@ARSLIST.ORG Subject: Re: Adding fields to incident form causes scroll issues ** BUT…… This did lead me down another branch of the path you started me on, where I think I have found the problem. It’s not the size of the HPD:Help Desk form that’s causing the issue. I think it’s the size of the panel and related view field on the SHR:Landing Console. Playing with that now, but so far my experiments show me that’s where the issue lies. Thanks! From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] Sent: Monday, December 09, 2013 10:32 AM To: 'arslist@ARSLIST.ORG' Subject: RE: Adding fields to incident form causes scroll issues I did check that. The form is sized ok. When I view it in Show Actual View Size mode, the 3 fields that get covered are visible and the buttons (z2PH_FormControlHolder) are below the fields. But thanks for the thought. Tim From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Monday, December 09, 2013 10:15 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Re: Adding fields to incident form causes scroll issues ** Is it possible that you need to change the size of the form? Have you tried verifying that it is big enough at least? With the form open in DS hit ctrl+alt+m or go to the Layout menu and choose Show Actual View Size and make sure that size is properly sized. I figure it can't hurt to check. HTH, Brian Goralczyk On Mon, Dec 9, 2013 at 8:27 AM, Timothy Powell timothy.pow...@pbs-consulting.commailto:timothy.pow...@pbs-consulting.com wrote: I'm still stuck. It's probably a has it got gas in it problem, but I can't see it. Any help is appreciated. Thanks, Tim -Original Message- From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.commailto:timothy.pow...@pbs-consulting.com] Sent: Friday, December 06, 2013 11:17 AM To: 'arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG' Subject: Adding fields to incident form causes scroll issues I searched this year's posting for this issue and not finding anything, I am posting my issue. Environment: ARS 7.6.04 SP4 ITSM 7.6.04 SP2 Mid-Tier 7.6.04 SP4 Description: I have a requirement to modify HPD:Help Desk to: Add a row to the Template and Summary fields (from 1 row to 2 rows of display). Add 3 fields to the Incident details area as well. Steps taken: I opened Dev Studio and one-by-one, enlarged (in height) the various panel holders and panels in the following order. z2PLH_ConsoleFlashBoards z2PL_Console z2PLH_Details z2PL_Main Body After each one, I flushed the cache, and tested the view. The maximized mid-tier screen looked good and the reduced sized screen allowed for proper scrolling that let me see all the fields in the view properly and the z2PH_FormControlHolder which contains all the buttons, floated properly to stay below all the visible fields as I tested various sized reduced screens. Next: I enlarged the z2PH_IncidentInformation panel and I added the rows to Template and Summary and added the 3 fields to that panel. I moved the z2PL_Assignment and z2PH_AdditionalIncidentInformation panels down to accommodate the new size of the z2PH_IncidentInformation panel. The relocated panels were within the resized panel holders and panels described in Steps taken. Saved form Flushed MT cache. Open in browser. Maximized window looks fine. BUT NOW if I reduce the screen down the scroll bars appears but it stops adjusting and blocks the last 3 fields in the z2PH_AdditionalIncidentInformation panel. This also occurs in search mode when there is a results list. So it appears that something is not allowing the z2PH_FormControlHolder to move below point x OR something is prohibiting on of the panels from expanding past that point. Anybody have a clue as to what I need to look for here? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.orghttp://www.arslist.org Where the Answers Are, and have been for 20 years _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Adding fields to incident form causes scroll issues
So far enlarging the z2PLH_Main, z2PL_BodyPg and z2PLH_ConsoleSplitter fields will allow a single ticket (or new ticket) to be displayed properly. But still working on fixing the display when there is a search results list in the mix. But your tip is spot on ref Outline. If you didn't use the Outline feature you would be lost. Thanks, Tim From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dale Jones Sent: Monday, December 09, 2013 12:53 PM To: arslist@ARSLIST.ORG Subject: Re: Adding fields to incident form causes scroll issues ** Tim, If memory serves me correct, there are multiple Panels there on top of each other. Kind of a pain. You have to move the top panel to get to the panel under it. Leverage the Outline + and - in Dev Studio. Work flow hides and unhides these panels. Dale Jones DCS Raleigh, NC 919-523-6034 _ From: Action Request System discussion list(ARSList) [arslist@ARSLIST.ORG] on behalf of Timothy Powell [timothy.pow...@pbs-consulting.com] Sent: Monday, December 09, 2013 11:44 AM To: arslist@ARSLIST.ORG Subject: Re: Adding fields to incident form causes scroll issues ** BUT.. This did lead me down another branch of the path you started me on, where I think I have found the problem. It's not the size of the HPD:Help Desk form that's causing the issue. I think it's the size of the panel and related view field on the SHR:Landing Console. Playing with that now, but so far my experiments show me that's where the issue lies. Thanks! From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] Sent: Monday, December 09, 2013 10:32 AM To: 'arslist@ARSLIST.ORG' Subject: RE: Adding fields to incident form causes scroll issues I did check that. The form is sized ok. When I view it in Show Actual View Size mode, the 3 fields that get covered are visible and the buttons (z2PH_FormControlHolder) are below the fields. But thanks for the thought. Tim From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Monday, December 09, 2013 10:15 AM To: arslist@ARSLIST.ORG Subject: Re: Adding fields to incident form causes scroll issues ** Is it possible that you need to change the size of the form? Have you tried verifying that it is big enough at least? With the form open in DS hit ctrl+alt+m or go to the Layout menu and choose Show Actual View Size and make sure that size is properly sized. I figure it can't hurt to check. HTH, Brian Goralczyk On Mon, Dec 9, 2013 at 8:27 AM, Timothy Powell timothy.pow...@pbs-consulting.com wrote: I'm still stuck. It's probably a has it got gas in it problem, but I can't see it. Any help is appreciated. Thanks, Tim -Original Message- From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] Sent: Friday, December 06, 2013 11:17 AM To: 'arslist@ARSLIST.ORG' Subject: Adding fields to incident form causes scroll issues I searched this year's posting for this issue and not finding anything, I am posting my issue. Environment: ARS 7.6.04 SP4 ITSM 7.6.04 SP2 Mid-Tier 7.6.04 SP4 Description: I have a requirement to modify HPD:Help Desk to: Add a row to the Template and Summary fields (from 1 row to 2 rows of display). Add 3 fields to the Incident details area as well. Steps taken: I opened Dev Studio and one-by-one, enlarged (in height) the various panel holders and panels in the following order. z2PLH_ConsoleFlashBoards z2PL_Console z2PLH_Details z2PL_Main Body After each one, I flushed the cache, and tested the view. The maximized mid-tier screen looked good and the reduced sized screen allowed for proper scrolling that let me see all the fields in the view properly and the z2PH_FormControlHolder which contains all the buttons, floated properly to stay below all the visible fields as I tested various sized reduced screens. Next: I enlarged the z2PH_IncidentInformation panel and I added the rows to Template and Summary and added the 3 fields to that panel. I moved the z2PL_Assignment and z2PH_AdditionalIncidentInformation panels down to accommodate the new size of the z2PH_IncidentInformation panel. The relocated panels were within the resized panel holders and panels described in Steps taken. Saved form Flushed MT cache. Open in browser. Maximized window looks fine. BUT NOW if I reduce the screen down the scroll bars appears but it stops adjusting and blocks the last 3 fields in the z2PH_AdditionalIncidentInformation panel. This also occurs in search mode when there is a results list. So it appears that something is not allowing the z2PH_FormControlHolder to move below point x OR something is prohibiting on of the panels from expanding past that point. Anybody have a clue as to what I need to look for here? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Re: Adding fields to incident form causes scroll issues
I had submitted an idea to the communities page to make it easier to manage forms when there are multiple panels (fields in general) on top of each other. Vote it up if you think it'd be useful. https://communities.bmc.com/ideas/2455 Thad On Mon, Dec 9, 2013 at 9:52 AM, Dale Jones d...@dcshq.com wrote: ** Tim, If memory serves me correct, there are multiple Panels there on top of each other. Kind of a pain. You have to move the top panel to get to the panel under it. Leverage the Outline + and - in Dev Studio. Work flow hides and unhides these panels. Dale Jones DCS Raleigh, NC 919-523-6034 -- *From:* Action Request System discussion list(ARSList) [ arslist@ARSLIST.ORG] on behalf of Timothy Powell [ timothy.pow...@pbs-consulting.com] *Sent:* Monday, December 09, 2013 11:44 AM *To:* arslist@ARSLIST.ORG *Subject:* Re: Adding fields to incident form causes scroll issues ** BUT…… This did lead me down another branch of the path you started me on, where I think I have found the problem. It’s not the size of the HPD:Help Desk form that’s causing the issue. I think it’s the size of the panel and related view field on the SHR:Landing Console. Playing with that now, but so far my experiments show me that’s where the issue lies. Thanks! *From:* Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] *Sent:* Monday, December 09, 2013 10:32 AM *To:* 'arslist@ARSLIST.ORG' *Subject:* RE: Adding fields to incident form causes scroll issues I did check that. The form is sized ok. When I view it in Show Actual View Size mode, the 3 fields that get covered are visible and the buttons (z2PH_FormControlHolder) are below the fields. But thanks for the thought. Tim *From:* Action Request System discussion list(ARSList) [ mailto:arslist@ARSLIST.ORG arslist@ARSLIST.ORG] *On Behalf Of *Brian Goralczyk *Sent:* Monday, December 09, 2013 10:15 AM *To:* arslist@ARSLIST.ORG *Subject:* Re: Adding fields to incident form causes scroll issues ** Is it possible that you need to change the size of the form? Have you tried verifying that it is big enough at least? With the form open in DS hit ctrl+alt+m or go to the Layout menu and choose Show Actual View Size and make sure that size is properly sized. I figure it can't hurt to check. HTH, Brian Goralczyk On Mon, Dec 9, 2013 at 8:27 AM, Timothy Powell timothy.pow...@pbs-consulting.com wrote: I'm still stuck. It's probably a has it got gas in it problem, but I can't see it. Any help is appreciated. Thanks, Tim -Original Message- From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] Sent: Friday, December 06, 2013 11:17 AM To: 'arslist@ARSLIST.ORG' Subject: Adding fields to incident form causes scroll issues I searched this year's posting for this issue and not finding anything, I am posting my issue. Environment: ARS 7.6.04 SP4 ITSM 7.6.04 SP2 Mid-Tier 7.6.04 SP4 Description: I have a requirement to modify HPD:Help Desk to: Add a row to the Template and Summary fields (from 1 row to 2 rows of display). Add 3 fields to the Incident details area as well. Steps taken: I opened Dev Studio and one-by-one, enlarged (in height) the various panel holders and panels in the following order. z2PLH_ConsoleFlashBoards z2PL_Console z2PLH_Details z2PL_Main Body After each one, I flushed the cache, and tested the view. The maximized mid-tier screen looked good and the reduced sized screen allowed for proper scrolling that let me see all the fields in the view properly and the z2PH_FormControlHolder which contains all the buttons, floated properly to stay below all the visible fields as I tested various sized reduced screens. Next: I enlarged the z2PH_IncidentInformation panel and I added the rows to Template and Summary and added the 3 fields to that panel. I moved the z2PL_Assignment and z2PH_AdditionalIncidentInformation panels down to accommodate the new size of the z2PH_IncidentInformation panel. The relocated panels were within the resized panel holders and panels described in Steps taken. Saved form Flushed MT cache. Open in browser. Maximized window looks fine. BUT NOW if I reduce the screen down the scroll bars appears but it stops adjusting and blocks the last 3 fields in the z2PH_AdditionalIncidentInformation panel. This also occurs in search mode when there is a results list. So it appears that something is not allowing the z2PH_FormControlHolder to move below point x OR something is prohibiting on of the panels from expanding past that point. Anybody have a clue as to what I need to look for here? Thanks. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist:
TMS:Task disabled fields
I'm pretty well stumped by this. We have a situation where intermittently users will open a task via link in a notification, but it opens with all fields disabled. This looks for all the world like the Default Admin View - Read Only view but I have determined that it isn't. What I did was I made a simple display form with a task I'd field a button and a view field. I made an active link that does an open window action on the specified task I'd in the view field. The active link specifies the Default Admin View and BOOM! It opens with all the fields disabled! I put an active link in to echo $VUI$ in an alert and it IS definitely in the default admin view. So I figured there must be an active link misfiring. So I DISABLED EVERY ACTIVE LINK ON TMS:Task ... And it STILL opens the default admin view with every field locked!! Flushed my cache and watched the active link log ... Nothing fires except my link to load the task! What the heck is locking these fields?! How can this even happen? More to the point I strongly suspect whatever is going on here is also the cause of my users intermittently opening tasks from notifications with all locked fields. Anyone out there run into this before? For what it's worth the exact same thing happens on my 764 test box as my 81sp2 box. - Andy ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: TMS:Task disabled fields
We are seeing this too (8.0). One case where this has been a long-term issue for a particular user was just escalated to me late last week. I logged in with that account and opened a task that was reported as having the issue with no problem. I should be talking with him later today to see if we can get to the bottom of it. People are blaming it on his account but his account worked fine for me. I'll report back with what we find. Jason On Mon, Dec 9, 2013 at 10:24 AM, Andrew Hicox and...@hicox.com wrote: ** I'm pretty well stumped by this. We have a situation where intermittently users will open a task via link in a notification, but it opens with all fields disabled. This looks for all the world like the Default Admin View - Read Only view but I have determined that it isn't. What I did was I made a simple display form with a task I'd field a button and a view field. I made an active link that does an open window action on the specified task I'd in the view field. The active link specifies the Default Admin View and BOOM! It opens with all the fields disabled! I put an active link in to echo $VUI$ in an alert and it IS definitely in the default admin view. So I figured there must be an active link misfiring. So I DISABLED EVERY ACTIVE LINK ON TMS:Task ... And it STILL opens the default admin view with every field locked!! Flushed my cache and watched the active link log ... Nothing fires except my link to load the task! What the heck is locking these fields?! How can this even happen? More to the point I strongly suspect whatever is going on here is also the cause of my users intermittently opening tasks from notifications with all locked fields. Anyone out there run into this before? For what it's worth the exact same thing happens on my 764 test box as my 81sp2 box. - Andy _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Funny — Google Chrome thinks ARS is in Slovak
Opened a Remedy form in Chrome today - Chrome added a little message on top - it said “This page is in Slovak” Would you like to translate it. (Nope, Translate) -John -- *John Sundberg* Kinetic Data, Inc. Your Business. Your Process. Save the date! *KEG14* February 24-25, 2014 *For more information, click here * - KEGhttp://www.kineticdata.com/Events/KEG.html 651-556-0930 I john.sundb...@kineticdata.com www.kineticdata.com I community.kineticdata.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: TMS:Task disabled fields
I discovered a few things poking at this a little further ...
1) every visible field in the interface is locked. If you create an overlay
and add a completely new field with public write permissions in read/write
display mode, it gets locked on display as well ! Even with every single
active link on TMS:Task disabled (and watching the log to be sure)
2) this isn't a midtier or CSS bug, because if you load it up in windows
aruser it happens there too! (Ya rly)
Either I'm missing something incredibly obvious (hoping someone here will
point that out actually) or this bug goes deeper than the mind of Minolta.
Andy
On Monday, December 9, 2013, Jason Miller wrote:
**
We are seeing this too (8.0). One case where this has been a long-term
issue for a particular user was just escalated to me late last week. I
logged in with that account and opened a task that was reported as having
the issue with no problem. I should be talking with him later today to see
if we can get to the bottom of it. People are blaming it on his account
but his account worked fine for me. I'll report back with what we find.
Jason
On Mon, Dec 9, 2013 at 10:24 AM, Andrew Hicox
and...@hicox.comjavascript:_e({}, 'cvml', 'and...@hicox.com');
wrote:
** I'm pretty well stumped by this.
We have a situation where intermittently users will open a task via link
in a notification, but it opens with all fields disabled.
This looks for all the world like the Default Admin View - Read Only
view but I have determined that it isn't.
What I did was I made a simple display form with a task I'd field a
button and a view field. I made an active link that does an open window
action on the specified task I'd in the view field. The active link
specifies the Default Admin View and BOOM! It opens with all the fields
disabled!
I put an active link in to echo $VUI$ in an alert and it IS definitely in
the default admin view. So I figured there must be an active link
misfiring. So I DISABLED EVERY ACTIVE LINK ON TMS:Task ... And it STILL
opens the default admin view with every field locked!!
Flushed my cache and watched the active link log ... Nothing fires except
my link to load the task!
What the heck is locking these fields?! How can this even happen? More to
the point I strongly suspect whatever is going on here is also the cause of
my users intermittently opening tasks from notifications with all locked
fields.
Anyone out there run into this before? For what it's worth the exact same
thing happens on my 764 test box as my 81sp2 box.
- Andy
_ARSlist: Where the Answers Are and have been for 20 years_
_ARSlist: Where the Answers Are and have been for 20 years_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Where the Answers Are, and have been for 20 years
Re: TMS:Task disabled fields
Andrew, The workflow that is opening this form...is it opening it in 'Display' mode?...Display mode, by definition is every field read only On Mon, Dec 9, 2013 at 2:57 PM, Andrew Hicox and...@hicox.com wrote: ** I discovered a few things poking at this a little further ... 1) every visible field in the interface is locked. If you create an overlay and add a completely new field with public write permissions in read/write display mode, it gets locked on display as well ! Even with every single active link on TMS:Task disabled (and watching the log to be sure) 2) this isn't a midtier or CSS bug, because if you load it up in windows aruser it happens there too! (Ya rly) Either I'm missing something incredibly obvious (hoping someone here will point that out actually) or this bug goes deeper than the mind of Minolta. Andy On Monday, December 9, 2013, Jason Miller wrote: ** We are seeing this too (8.0). One case where this has been a long-term issue for a particular user was just escalated to me late last week. I logged in with that account and opened a task that was reported as having the issue with no problem. I should be talking with him later today to see if we can get to the bottom of it. People are blaming it on his account but his account worked fine for me. I'll report back with what we find. Jason On Mon, Dec 9, 2013 at 10:24 AM, Andrew Hicox and...@hicox.com wrote: ** I'm pretty well stumped by this. We have a situation where intermittently users will open a task via link in a notification, but it opens with all fields disabled. This looks for all the world like the Default Admin View - Read Only view but I have determined that it isn't. What I did was I made a simple display form with a task I'd field a button and a view field. I made an active link that does an open window action on the specified task I'd in the view field. The active link specifies the Default Admin View and BOOM! It opens with all the fields disabled! I put an active link in to echo $VUI$ in an alert and it IS definitely in the default admin view. So I figured there must be an active link misfiring. So I DISABLED EVERY ACTIVE LINK ON TMS:Task ... And it STILL opens the default admin view with every field locked!! Flushed my cache and watched the active link log ... Nothing fires except my link to load the task! What the heck is locking these fields?! How can this even happen? More to the point I strongly suspect whatever is going on here is also the cause of my users intermittently opening tasks from notifications with all locked fields. Anyone out there run into this before? For what it's worth the exact same thing happens on my 764 test box as my 81sp2 box. - Andy _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: TMS:Task disabled fields
And there it is. Lol
I knew it must have been something obvious and it was :)
Thanks!
Andy
On Monday, December 9, 2013, LJ LongWing wrote:
**
Andrew,
The workflow that is opening this form...is it opening it in 'Display'
mode?...Display mode, by definition is every field read only
On Mon, Dec 9, 2013 at 2:57 PM, Andrew Hicox
and...@hicox.comjavascript:_e({}, 'cvml', 'and...@hicox.com');
wrote:
**
I discovered a few things poking at this a little further ...
1) every visible field in the interface is locked. If you create an
overlay and add a completely new field with public write permissions in
read/write display mode, it gets locked on display as well ! Even with
every single active link on TMS:Task disabled (and watching the log to be
sure)
2) this isn't a midtier or CSS bug, because if you load it up in windows
aruser it happens there too! (Ya rly)
Either I'm missing something incredibly obvious (hoping someone here will
point that out actually) or this bug goes deeper than the mind of Minolta.
Andy
On Monday, December 9, 2013, Jason Miller wrote:
**
We are seeing this too (8.0). One case where this has been a long-term
issue for a particular user was just escalated to me late last week. I
logged in with that account and opened a task that was reported as having
the issue with no problem. I should be talking with him later today to see
if we can get to the bottom of it. People are blaming it on his account
but his account worked fine for me. I'll report back with what we find.
Jason
On Mon, Dec 9, 2013 at 10:24 AM, Andrew Hicox and...@hicox.com wrote:
** I'm pretty well stumped by this.
We have a situation where intermittently users will open a task via
link in a notification, but it opens with all fields disabled.
This looks for all the world like the Default Admin View - Read Only
view but I have determined that it isn't.
What I did was I made a simple display form with a task I'd field a
button and a view field. I made an active link that does an open window
action on the specified task I'd in the view field. The active link
specifies the Default Admin View and BOOM! It opens with all the fields
disabled!
I put an active link in to echo $VUI$ in an alert and it IS definitely
in the default admin view. So I figured there must be an active link
misfiring. So I DISABLED EVERY ACTIVE LINK ON TMS:Task ... And it STILL
opens the default admin view with every field locked!!
Flushed my cache and watched the active link log ... Nothing fires
except my link to load the task!
What the heck is locking these fields?! How can this even happen? More
to the point I strongly suspect whatever is going on here is also the cause
of my users intermittently opening tasks from notifications with all locked
fields.
Anyone out there run into this before? For what it's worth the exact
same thing happens on my 764 test box as my 81sp2 box.
- Andy
_ARSlist: Where the Answers Are and have been for 20 years_
_ARSlist: Where the Answers Are and have been for 20 years_
_ARSlist: Where the Answers Are and have been for 20 years_
_ARSlist: Where the Answers Are and have been for 20 years_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Where the Answers Are, and have been for 20 years
Stop Clock on Incident
Hi List, Can you please assist me again on below issue? Is there any process or mechanism on Incident, to stop the clock and reactivate it again? My purpose is to move the Incident into special Status Reason value. Till the time Incident is in that Status Reason, clock should be stopped for Incident, means this particular time should not get calculated in Incident open or working time? Has anyone worked on this secanrio, then can please assist me? Regards Neha Khandelwal ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
