Re: Group/User Notifications.
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 badbee...@gmail.com a écrit : De: Robert Halstead badbee...@gmail.com Objet: Re: Group/User Notifications. À: arslist@ARSLIST.ORG 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 frexp...@yahoo.fr 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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Group/User Notifications.
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 returnetc. Brien On Fri, Dec 19, 2008 at 4:19 AM, Frex Popo frexp...@yahoo.fr 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 badbee...@gmail.com* a écrit : De: Robert Halstead badbee...@gmail.com Objet: Re: Group/User Notifications. À: arslist@ARSLIST.ORG 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 frexp...@yahoo.fr 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
Re: Group/User Notifications.
I didn't think about that too long, obviously :-). You'll still have to walk a table (if joined) or tableS (not joined), in any case, right? Come to think of it, shouldn't the parent form already have a a table field with the child incidents displayed? And the Child incident probably already has a table field listing the related tasks, right? So, you just need two Filter guides, and also add assigned to and assignee group to both table fields (hidden?). The Filter guide on the child incident form walks the task table field and collects assigned_to and assignee group concatenated to two fields on that form (which are then added to the Child Incident table field on the Parent Incident form). Another filter guide does the same thing on the parent incident form, but also collects the two fields that are the list of tasks. The filter guides are triggered on modify and submit. The button that adds children and tasks can also run process set-change-flag 1 to ensure the modify filter runs every time something is added. I'm probably missing something but I think that is generally how I did something similar. Good luck! Brien On Fri, Dec 19, 2008 at 11:31 AM, Brien Dieterle brien.diete...@cgcmail.maricopa.edu wrote: 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 returnetc. Brien On Fri, Dec 19, 2008 at 4:19 AM, Frex Popo frexp...@yahoo.fr 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 badbee...@gmail.com* a écrit : De: Robert Halstead badbee...@gmail.com Objet: Re: Group/User Notifications. À: arslist@ARSLIST.ORG 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 frexp...@yahoo.fr 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
Group/User Notifications.
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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Group/User Notifications.
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 frexp...@yahoo.fr 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
