OK, let me see if I can be more clear in my objections.
Your management, for some unexplained reason, wants to know who is filling
out the surveys. You are trying to satisfy that requirement technically. I
am trying to address it from a business perspective, and that almost always
starts with the question "Why?".
The only reason I can guess for that is that they want to be sure that the
person filling it out is the person to whom it was directed. Let's look at
three factors in that.
- How valuable is knowing who actually filled out the survey, from a
practical standpoint? What will be done with those metrics, if anything?
- What are the chances of accidental misuse?
- Since the surveys are only sent to the person who is supposed to
have them, making it pretty difficult for User2 to even know
that a survey
is available for User1. It would be MORE work for someone to
try to answer
someone else's survey than to just do the ones they get sent, and most
people don't even fill THOSE out. So practically speaking, there is very
little chance of an accidental misuse of the survey.
- What is the likelihood of intentional misuse?
- Are they concerned that there will be an epidemic of people taking
surveys for other people? Do they think their people have so
little to do
that they will spend even free time spoofing other users to fill
out their
surveys? If so, they have a bigger problem than satisfying this
requirement
could possibly address. So the likelihood of intentional misuse is
again, effectively zero.
So my analysis is that what they *might* gain by the satisfaction of this
requirement seems insignificant compared to the work of satisfying it. I
fail to see ANY worthwhile business justification for this requirement, and
in the absence of same, as a developer, I would reject it for that reason
alone until it is better thought through by the business leaders.
Rick
On Wed, May 5, 2010 at 5:45 AM, Veeral Oza <[email protected]> wrote:
> **
> Hi Rick,
>
> The ticket data is available and the requester details are populated in the
> survey. However, there is also a requirement to capture windows login id of
> the user submitting the survey.
>
> Regards,
> Veeral
>
>
>
On Wed, May 5, 2010 at 6:10 PM, Rick Cook <[email protected]> wrote:
> How about prepopulating the userid from the ticket when the survey is
> created? If that data is unavailable, how would the survey be directed
> appropriately?
>
>
> Rick
> ------------------------------
> *From: *Veeral Oza <[email protected]>
> *Date: *Wed, 5 May 2010 18:07:31 +0530
> *To: *<[email protected]>
> *Subject: *Re: Windows UserID
>
> **
> Forgot to mention environment:
>
> ARS 7.0
> ITSM 7.0.3
> Midtier: 7 on Apache-Tomcat on a Windows machine.
> Oracle 11g database.
>
>
> On Wed, May 5, 2010 at 6:05 PM, Veeral Oza <[email protected]> wrote:
>
>
>> Hi,
>>
>> I am stuck at this requirement and was wondering if this is feasible to
>> implement:
>>
>> 1) When an Incident is resolved, an email goes to the customer to submit a
>> survey, with a survey link.
>> 2) The link opens the survey form in the brower without the user
>> authenticating in the midtier. A surver-user with a restricted read license
>> is created for this purpose which allows multiple people from multiple
>> locations to submit the survey.
>> 3) There is a submit button on this survey form.
>> 4) When the user clicks on submit button, it is required that, his Windows
>> User ID be captured in one of the fields.
>> _______________________________
>>
>> Solutions implemented that did not work:
>> 1)
>> Create a little Java function in a .jsp file and put it in your "shared"
>> folder on your Midtier:
>>
>> Name the file something like /arsys/shared/get_remote_user.jsp.
>>
>> get_remote_user.jsp contains:
>>
>> function env_ip_var()
>> {
>> var return_value = "<%=request.getRemoteUser()%>";
>> return (return_value)
>> }
>>
>> In the Web Header content of the form you want to capture this on,
>> add...
>>
>> <SCRIPT src="/arsys/shared/get_remote_user.jsp"
>> language="JavaScript"></SCRIPT>
>>
>> To set a field with the data from the JavaScript functions do the
>> following in an active link...
>>
>> Run Process Command Line:
>> javascript:window.F(XXXXXXXX).DoSet(env_hostname());
>>
>> Be sure to change XXXXXXXX with the field ID of the field you want to
>> set.
>>
>> This did not work, function env_ip_var returns null.
>>
>> ____________________________________________
>> Solution 2:
>>
>> A set fields actions in an active link:
>> $PROCESS$ CMD /C "set username"
>>
>> This worked only in user tool. However this functionality is required for
>> web.
>>
>> ___________________________________________
>>
>> If you have any other ideas, please do share.
>>
>> Regards,
>> Veeral Oza
>>
>>
>
> _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
_attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
