Dear Listers, ok ok ok...I got it :) the problem was that I didn't have knowledge of the "external()"-function to build the qualification within the table properties for each ticket-request!
Thank you very much for help! Regards Christoph -----Ursprüngliche Nachricht----- Von: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] Im Auftrag von Misi Mladoniczky Gesendet: Freitag, 28. Oktober 2011 09:48 An: arslist@ARSLIST.ORG Betreff: Re: AW: AW: kind of selection Hi Christoph, Did you get this to work? If you are sending a notification, this must be done from a filter. You could have a single Distribution List file with Email Addresses or Login Names: DistributionList = "miz christoph bla...@test.com blab...@test.com" And you can use my original suggestion, with a slight fix, to accomplish this: Left Table: (... AND NOT $DistrList$ LIKE "%" + 'Email' + "%") Right Table: (... AND $DistrList$ LIKE "%" + 'Email' + "%") ACTL: LeftToRight: ('Left Email' != $NULL$) Set-Fields: CURRENT DistrList = $DistrList$ + " " + $Left Email$ Change Field: Left Table << Refresh Change Field: Right Table << Refresh ACTL: RightToLeft ('Right Email' != $NULL$) Set-Fields: CURRENT Selected Ids = REPLACE($DistrList$, " " + $Right Email$, "") Change Field: Left Table << Refresh Change Field: Right Table << Refresh FLTR: Notify if ('DistrList' != $NULL$ AND ...) Notify: $DistrList$ Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > My original response for a solution is still the way to go. The help > guide in developer studio has already done most of the work for you, > telling you step by step what to do. > > Two table fields all pointing to what ever form your people > information sits in. > > Table 1 shows the list of users to pick from. > > Table 2 has its qualification set to 1=2 so that does not show any data. > > In table 1 the user selects a person and hits the add button. > > Workflow calls the add row process on table 2 and fills in the details > of what was selected in table 1. > > Repeat for each person added. > > A delete button can remove people from table 2. > > User can hit the send button which triggers workflow to walk table 2, > creating a notification for each person. > > This should take you about 15 - 20 minutes to build if you are > familiar with the development environment. > > This is the very implementation I used for one of our notification > systems. > > The help document notes in developer studio gives added pointers and > other features to use for this process. > > As Misi stated, this can be done with just the one form. > > Brent... > > Sent from my iPhone, so typo's or funky words can and do happen! > > > > > On Oct 25, 2011, at 2:08 PM, "Wagner, Christoph" > <christoph.wag...@ard-stern.de> wrote: > >> Hi listers, >> >> this is exactly what I want. >> >> I have a ticket form, where each request represents a failure in our >> company, of course (e.g. Server A is down, Server B is down and so on). >> For each request the user should select some out of 20 people which >> have to be notified. For this selection I want to use two tables and >> 2 buttons (add and remove). The left table should contain every >> people who could be notified (IS state). The right table should >> contain the people who finally will be notified (target state). >> >> Example: >> >> |whole distribution list| | choosed distribution list | >> | --------------------- | |----------------------------- >> | >> | people A | add | people A | >> | people B | remove | | >> | people C | | | >> | ... | | | >> >> >> Misi, you said that I can do the whole thing in one form, to be exact: >> in my ticket-form. As I read through the Form and Application Objects >> Guide, I found out that tables are created as follows: a column >> represents any field from my ticket-form and each row represents a >> request from that form. >> >> As you can see out of my example I need one column and at least 20 >> rows for the tables. For that I need one extra field in my >> ticket-form, perhaps a character field named "distribution list" and >> 20 new requests with the right Email-Address inside this field. >> >> And this is where I stuck, what I don't understand!!! >> >> I need the requests from the form for my failures (Server A is >> down...) and I need the requests from the form for the selection >> itself. But I have to store the information of a failure and the >> information of the two tables in one request. Am I right with this? >> Or do I forget anything? This is what I don’t understand - this can't work >> for me! >> >> Thank you very much for your help! >> >> Regards, >> >> Christoph >> >> >> >> >> >> -----Ursprüngliche Nachricht----- >> Von: Action Request System discussion list(ARSList) >> [mailto:arslist@ARSLIST.ORG] Im Auftrag von Misi Mladoniczky >> Gesendet: Dienstag, 25. Oktober 2011 08:56 >> An: arslist@ARSLIST.ORG >> Betreff: Re: AW: kind of selection >> >> Hi, >> >> If you go with my suggestion, you can have the same form underneath >> both tables. >> >> My idea was to MOVE things from left to right. >> >> How to do this much depends on what end results your are trying to >> accompli > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"