so our design should be where the customer data is AL:setfields the
submitter field with their specialized login id (which can get complicated)
for inside and outside customers. Prior to submission.
thanks..
On 11/30/06, Misi Mladoniczky <[EMAIL PROTECTED]> wrote:
Yes (and no...),
If I recall correctly, you can set it manually or with Active-Links. You
can, unfortunately, not set it using filters... It is considered a change,
even if the filter triggers on submit.
Best Regards - Misi, RRR AB, http://www.rrr.se
> So that actually answers a question I hadn't had time to test: With
> "Submitter-Mode-Locked" set, you can still set the value of the
submitter
> field on submit to whatever you want. Is that correct?
>
> I'm clear on not being able to modify it afterward, but since I usually
> use $USER$ as the default for submitter, the need to use a different
> submitter had never come up.
>
> Thad
> P.S. It must be an alliteration kind of day. ("submitter" and "user"
seem
> rampant in that email.)
>
>
>
>
> "Misi Mladoniczky" <[EMAIL PROTECTED]>
> Sent by: "Action Request System discussion list(ARSList)"
> <[email protected]>
> 11/30/2006 07:13 AM
> Please respond to
> [email protected]
>
>
> To
> [email protected]
> cc
>
> Subject
> Re: Question on license
>
>
>
>
>
>
> Hi,
>
> The "submitter" is not neccessarily the person submitting the ticket.
>
> At submit-time you can specify any login name in the submitter-field.
>
> So if you know the read-license-person who will want to update a ticket
at
> submit-time, you can enter his/hers login-name in the submitter-field.
>
> I usually try to put the "customer-login" in the submitter-field
> regardless if a person submits from the Web or if he calls the
> Service-Desk by phone.
>
> The limitations with submitter-mode-locked is just that you can not
change
> it after you have submitted the ticket.
>
> Best Regards - Misi, RRR AB, http://www.rrr.se
>
>> Yes that will work but some of the tickets are generated from the
> helpdesk
>> people. So the helpdesk person is the submitter and the logon* is just
> a
>> requestor with read only.
>>
>>
>> John Atherly
>> American Power Conversion
>> [EMAIL PROTECTED]
>> 401-789-5735 Ext. 2120
>> 1-800-788-2208 Ext. 2120
>>
>>
>>
>> patrick zandi
>> <[EMAIL PROTECTED]
>> COM> To
>> Sent by: "Action [email protected]
>> Request System cc
>> discussion
>> list(ARSList)" Subject
>> <[EMAIL PROTECTED] Re: Question on license
>> ORG>
>>
>>
>> 11/30/2006 09:59
>> AM
>>
>>
>> Please respond to
>> [EMAIL PROTECTED]
>> RG
>>
>>
>>
>>
>>
>>
>> ** Whoops.. did not even see michelle's answer.. Scarry..
>>
>> On 11/30/06, patrick zandi <[EMAIL PROTECTED]> wrote:
>> Just looking this over.. Submitter locked mode allows the submitter
to
>> update his ticket in Read license mode.
>> The approver already has a Fixed or Floating license.
>> So you could use a Diary field to log the conversation by inputs via
>> Email submission or API or Mid-tier.
>> Create a Question 400 character field, or 2000 for that matter. and
>> Create an Answer Field.
>> If the Question is placed in the field - push to diary, and send
email
>> to
>> customer with a URL or Email form.
>> Answer comes into the Answer field and gets pushed to the Diary.
>>
>> Does this fit the License scenario ?
>> They both have access to the Diary and Question and Answer field.
>> The submitter is able to update his information.
>> The approver is able to update the ticket.
>>
>> Just a thought.
>>
>>
>> On 11/30/06, John Atherly <[EMAIL PROTECTED] > wrote:
>> Yes we want to remain legal on this. What I have been task to
> create
>> is
>> away for an approver to ask a question to the requestor.
>>
>> What is happening a change request will come in for access to one of
>> the
>> network drives. In the justification field the end uses will type
in
>> answer such as "New Job" These answer do not help the approves in
>> deciding on granting access or denying access. Currently the
> approves
>> either deny the request or has to create an email to ask for more
>> reason
>> why they need access. Then a couple days later when they get a
>> response
>>
>> they have to find the request to either approve or deny. I was
>> looking
>> for a way to be able to start a two way communication between the
>> approver
>> and the requestor. So I would need a field that approvers can ask
a
>> question in and a field were the requestor can answer too and keep a
>> record
>> of the transactions (worklog)
>>
>>
>>
>>
>> John Atherly
>> American Power Conversion
>> [EMAIL PROTECTED]
>> 401-789-5735 Ext. 2120
>> 1-800-788-2208 Ext. 2120
>>
>>
>>
>> "Lucero, Michelle
>> - IST contractor"
>> <Michelle.Lucero@
>> To
>> MKCORP.COM> [email protected]
>> Sent by: "Action
>> cc
>> Request System
>> discussion
>> Subject
>> list(ARSList)" Re: Question on license
>> <[EMAIL PROTECTED]
>> ORG>
>>
>>
>> 11/29/2006 03:07
>> PM
>>
>>
>> Please respond to
>> [EMAIL PROTECTED]
>> RG
>>
>>
>>
>>
>>
>>
>> Hi, John:
>>
>> To modify an entry, one does need the ability to WRITE. If the
> system
>> is placed in Submitter Mode Locked, individuals assigned Read
> Licenses
>> can Search, Submit, Display and Modify entries that they have
>> submitted;
>>
>> as long as their login id is placed in field ID 2. And, Submitter
> has
>> WRITE access to each of the fields that needs to be updated.
>>
>> There are multiple ways to address. One can save thousands in
>> maintenance costs, while remaining legal. It all depends on your
>> company or client's needs. Obviously there may be some individuals
>> that
>> will still require a WRITE license.
>> =================================
>> From Remedy Admin 6.3 Help - License Types
>> Read
>> Enables users to search and display existing requests.
Administrators
>> can configure the AR System server to enable users to submit new
>> requests and modify or save data in existing requests. (See "Special
>> submitter mode".)
>>
>> Restricted Read
>> Allows users to search the AR System forms and submit new requests
> but
>> does not allow users to modify existing requests under any
> conditions.
>> It does, however, allow the same login account to access the AR
> System
>> from multiple IP addresses simultaneously, such as when browsing a
>> knowledge base or completing on-line surveys.
>>
>> Fixed Write
>> Includes all the capabilities of a Read license, and also enables
> users
>> to modify and save data for existing requests based on the groups to
>> which the user belongs. AR System administrators and
> subadministrators
>> must have a Fixed Write license. Other AR System users who
> consistently
>> need to modify requests must also have Fixed Write licenses.
>> A user cannot be assigned the same Fixed Write license more than
> three
>> times in one week. If this limitation is exceeded, the user must
wait
>> one week from the first assignment of the Fixed Write license before
> it
>> can be assigned again.
>>
>> Floating Write
>> Includes all the capabilities of a Read license, and also enables
> users
>> to modify and save data for existing requests based on the groups to
>> which the user belongs. Floating Write licenses can be used by
> multiple
>> users, one user at a time. This type of license is designed for
users
>> who occasionally need to modify and save data for existing requests.
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList)
>> [mailto:[EMAIL PROTECTED] On Behalf Of John Atherly
>> Sent: Wednesday, November 29, 2006 1:47 PM
>> To: [email protected]
>> Subject: Question on license
>>
>> If I create a total new application from scratch then the public
will
>> not
>> need a write license to modify a record! What I'm looking at doing
> is
>> a
>>
>>
>> record will be created by support and then will be updated by the
>> enduser. I thought that this was true but my partners in crime
>> different from me.
>>
>> Thanks
>> (No it's not a bet so I will not win or lose a beer)
>>
>>
________________________________________________________________________
>> _______
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> ARSlist:"Where
>> the Answers Are"
>>
>>
>
_______________________________________________________________________________
>>
>>
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> ARSlist:"Where
>> the Answers Are"
>>
>>
>
_______________________________________________________________________________
>>
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> ARSlist:"Where
>> the Answers Are"
>>
>>
>>
>> --
>> Patrick Zandi
>>
>>
>>
>> --
>> Patrick Zandi __20060125_______________________This posting was
> submitted
>> with HTML in it___
>>
>>
>
_______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.orgARSlist:"Where
>> the Answers Are"
>>
>
>
_______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
> the Answers Are"
>
>
>
> ***IMPORTANT NOTICE: This communication, including any attachment,
> contains information that may be confidential or privileged, and is
> intended solely for the entity or individual to whom it is
addressed. If
> you are not the intended recipient, you should delete this message and
are
> hereby notified that any disclosure, copying, or distribution of this
> message is strictly prohibited. Nothing in this email, including any
> attachment, is intended to be a legally binding signature.***
>
>
_______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
> the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
--
Patrick Zandi
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
