AW: AW: AW: kind of selection
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
Re: AW: AW: kind of selection
Wow. I've always used joins and outer joins to manage the data in the two
tables, using active links to push data to the underlying forms. This is
a simpler approach using a local field to help limit the values returned to
each table. Then you'd also be able to show the proposed changes without
already writing them to the database. And give the user a chance to click
a save/commit button. good tip guys!
On Tue, Nov 1, 2011 at 6:14 AM, Wagner, Christoph
christoph.wag...@ard-stern.de wrote:
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
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
AW: AW: kind of selection
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 accomplish. You might get better response from the list if you explain that to us. I suggest that you read more documentation on tables, and check how existing tables work, and possibly go on a training class that covers the topic in detail. 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. Dear listers, first of all thanks a lot for your answers but I still haven’t got it. I still have problems in understanding tables in remedy. If I want a table with one column und about 20 rows I need a new form [Form 1] with one character field [Char Field] and in that form 20 requests with different Char Field contents? I connect this form and the character field with the table. Then I have a table with fixed values. This would be ok for my left table. But how do I handle with the right table? My problem is that I want this kind of selection for my ticket-form. That means of course for each ticket different results in the right table. But I don’t know how to link the table with the request-ID of my ticket form. For that I need a three dimensional table, not only a two-one…I think it must be easier but I don’t how to do it. Please, can you help me? Thanks a lot! Regards Christoph Von: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] Im Auftrag von Remedy Gesendet: Montag, 24. Oktober 2011 15:54 An: arslist@ARSLIST.ORG Betreff: Re: kind of selection ** From the help files in developer studio, they have a step by step write up on how move data back and forth between two tables. I found it while searching for details on how to add rows to a table. Sent from my iPhone, so typo's or funky words can and do happen! On Oct 23, 2011, at 9:24 PM, Shafqat Ayaz shafq...@yahoo.com wrote: ** Hi Christoph you can achieve this with a simple flag on the form, say for example a field Show, which has two values, Show 1 and Show 2. The first table shows all entries with the flag set to 1, when you move the items from table one to two, just set the flag to Show 2 and reverse it back when the opposite happens. Set the qualification
Re: AW: AW: kind of selection
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
