Couldn't the table fields be hidden or even on a separate view and then
walked by AL Guides?  Or, another idea, create Join forms for the
Parent/Child, include assigned to and assignee group for both forms (4
fields) and the parent requestID.  Then join that to the task form, include
assigned to and assignee  group (2 fields).  Then when you press that button
do a set fields to lookup all 6 pieces of information from just the one
master join form and set a display-only field to that to be included in the
notify?  I think you would do a $assigned_to_parent$ + <carriage return>
$assignee_group_parent$ + <carriage return>....etc.

Brien

On Fri, Dec 19, 2008 at 4:19 AM, Frex Popo <[email protected]> wrote:

> ** Thanks Robert
> The incident form we have is overloded with tones of fileds, field tables,
> attachment tables and the rest of it, so I am trying to avoid using tables
> and instead was thinking about an additional form ... anyway, I will think a
> little bit about it and let you know if I manage to resolve it.
>
> Have a nice weekend
> frex
>
>
> --- En date de : *Jeu 18.12.08, Robert Halstead <[email protected]>* a
> écrit :
>
> De: Robert Halstead <[email protected]>
> Objet: Re: Group/User Notifications.
> À: [email protected]
> Date: Jeudi 18 Décembre 2008, 21h24
>
> ** This is just a thought, but you could build a table field on the
> incident form of all the child tickets for that parent, and another for all
> the tasks related.. I guess the problem would be getting all the tasks that
> were related to the children and parent..   Essentially, you could walk a
> table and build your recipients list that way.
>
> On Thu, Dec 18, 2008 at 7:49 AM, Frex Popo <[email protected]> wrote:
>
>> **   Hello everyone,
>>
>> I have a number of child Incidents linked to a parent Incident. Each child
>> Incident has a number of tasks.
>>
>> What I need is, when a user presses a button on the Incident form, a
>> notification is sent to the user whom THE PARENT INCIDENT has been assigned
>> to, (or the group in case the incident has not been assigned to anyone yet).
>>
>>
>> The notification should also be sent to the user to which THE CHILD
>> INCIDENT t has been assigned to (or the group in case the child incident has
>> not been assigned to anyone). The same for all the child Incidents of the
>> parent Incident.
>>
>> The notification should also be sent to the user to which THE TASK of the
>> child incident has been assigned to (or the group in case the task has not
>> been assigned to anyone). The same should apply to all the tasks of each
>> child Incident.
>>
>> What would the best way to approach this problem?
>>
>> Is it by creating a form and storing the ID of the parent incident, child
>> incidents, and taks, along with all the group and users and then use a
>> filter on submit to that form and send a notification?
>>
>> How about walking through the incident and taks form to find the relevant
>> IDs?
>>
>> Anyone did before and want to share their thoughts.
>>
>> Thanks in advance
>> frex.
>>
>> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>> html___
>
>
>
>
> --
> "A fool acts, regardless; knowing well that he is wrong. The ignoramus acts
> on only what he knows, but all that he knows.
> The ignoramus may be saved, but the fool knows that he is doomed."
>
> Robert Halstead
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
>
>
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to