Re: RANT: Diary fields in a dialog box..
I'd rather stick with the dialog and not a new create/modify window for the simple reason, when a dialog is opened, the user cannot really access any fields through a gain focus (mouse click) until the dialog is closed so that gives you more control on the user.. Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. - Original Message From: Carey Matthew Black [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Thursday, February 8, 2007 1:14:09 PM Subject: Re: RANT: Diary fields in a dialog box Hum... Resize could be done via views designed for specific desktop sizes... (with window open/close events to switch views.) Not as any sized as the original, but very close. Writing the field contents to a file... Sounds like a Report to file to me. Reading a files contents into the field sounds like a $PROCESS$ more|less|type call to me. (likely not working on the Web however.) And I think you could even make it a non-dialog window too. (If your first window was not a dialog.) and let you keep multiple of those windows open at a time. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 2/8/07, Joe DeSouza [EMAIL PROTECTED] wrote: ** Strange but thats exactly what me and a colleague of mine designed.. I've decided to hide the expansion box of the diary field and build another dialog having 2 fields for the edit and non edit part and 2 buttons OK and Cancel and emulate the diary field functionality using a small button near the actual diary field that brings up this second dialog.. Only functions that users wont be able to do is resize the dialog and have these 2 fields resize automatically, and the option of saving the contents of a diary field to a file or writing from a file to the diary field.. you cant really get it all and yet make it look like the original field.. I could add the edit boxes for those 2 fields but the look and feel will differ distintively.. Rgds Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: RANT: Diary fields in a dialog box....
You hit the nail on the head Axton.. That's exactly the root of my problems whenever I use diary fields on dialog boxes.. If an original bit of workflow used matching Id's to set values into it, the moment a diary field is added and has to be a part of that dialog (which was my case here) booom... I have to make changes to workflow that sets fields etc.. What I'm thinking of doing is almost close to your suggestion but I don't quite like that idea of creating 2 display only fields, one read only for setting the history part, the other display only for adding new stuff.. Workable but not screen smart on the aesthetic point of view when you are using more real estate to do what could have been done OTB if reading and writing data to and from both the editable and history part of the worklog fields was a little smarter.. As Shyam Attavar, suggested I wonder if this would be useful to have as a RFE as I really think this would save a lot of us a lot of sweat plus have our dialog boxes containing diaries a function better without the need for creating those unnecessary display fields... Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. - Original Message From: Axton [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 10:33:10 PM Subject: Re: RANT: Diary fields in a dialog box ** Just don't use diary fields. In the case of the packaged apps, create a display only character field and allow updates to that field. Unfortunate side effect is that you can not use matching id's in one of 2 actions (on open/set or save/push). Axton On 2/7/07, Shyam Attavar [EMAIL PROTECTED] wrote: ** Joe, In my opinion this would go into the RFE bucket. Maybe worth a shot, since BMC/Remedy uses diary fields in their OOB applications. -- Shyam - Original Message - From: Joe DeSouza Newsgroups: gmane.comp.crm.arsystem.general To: arslist@ARSLIST.ORG Sent: Wednesday, February 07, 2007 4:51 PM Subject: Re: RANT: Diary fields in a dialog box ** Agreed, but it does tend to be a bit of a pain if you are doing something like viewing a record in a dialog box, and that record has diary fields, and you need to edit that diary field from the dialog box... What then without any workarounds such as setting the historical part into a read only field and having a display only field editable to push the new content... Maybe I didn't really word my original post properly.. When this dialog box is opened, it would be nice if the set field happens like it does for any other field, I'm not contesting that.. But diary fields in the dialog should have been able to recognize the historical part and open it in a histry box below the editable part just like it does when you open the record in a Modify mode... Joe - Original Message From: Grooms, Frederick W [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 7:36:23 PM Subject: Re: RANT: Diary fields in a dialog box ** I believe that is the correct workflow for the system to do. You are doing a Set Fields to the diary field. That always puts that data into the editable portion. Why should it work differently on a Dialog than it would on a regular form? How would the system know if you were wanting the data to be the historical data or just pre-populating data for the user to add to? Personally if I am doing something like that I put the historical data into a display only (read only) character field. Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza Sent: Wednesday, February 07, 2007 5:38 PM To: arslist@ARSLIST.ORG Subject: RANT: Diary fields in a dialog box ** Wonder why is it Remedy has never addressed to the issue that if you open up a dialog box that contains a diary field, and there is a set field action that brings in values from a record on open of the dialog, the Diary field doesn't behave like its should have behaved. There is no uneditable historical part for the field and an editable one. Everything from history gets set to the editable part so if you want to edit its contents it adds all this plus what you add during the transaction, to the diary for each transaction Any idea as to whether or not this issue will ever be addressed to?? Joe Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: RANT: Diary fields in a dialog box....
If you do submit an RFE, do the legwork before submitting it. Detail how you want the app to act and respond to as many scenarios as you can think of. Axton Grams On 2/8/07, Joe DeSouza [EMAIL PROTECTED] wrote: ** You hit the nail on the head Axton.. That's exactly the root of my problems whenever I use diary fields on dialog boxes.. If an original bit of workflow used matching Id's to set values into it, the moment a diary field is added and has to be a part of that dialog (which was my case here) booom... I have to make changes to workflow that sets fields etc.. What I'm thinking of doing is almost close to your suggestion but I don't quite like that idea of creating 2 display only fields, one read only for setting the history part, the other display only for adding new stuff.. Workable but not screen smart on the aesthetic point of view when you are using more real estate to do what could have been done OTB if reading and writing data to and from both the editable and history part of the worklog fields was a little smarter.. As Shyam Attavar, suggested I wonder if this would be useful to have as a RFE as I really think this would save a lot of us a lot of sweat plus have our dialog boxes containing diaries a function better without the need for creating those unnecessary display fields... Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. - Original Message From: Axton [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 10:33:10 PM Subject: Re: RANT: Diary fields in a dialog box ** Just don't use diary fields. In the case of the packaged apps, create a display only character field and allow updates to that field. Unfortunate side effect is that you can not use matching id's in one of 2 actions (on open/set or save/push). Axton On 2/7/07, Shyam Attavar [EMAIL PROTECTED] wrote: ** Joe, In my opinion this would go into the RFE bucket. Maybe worth a shot, since BMC/Remedy uses diary fields in their OOB applications. -- Shyam - Original Message - *From:* Joe DeSouza [EMAIL PROTECTED] *Newsgroups:* gmane.comp.crm.arsystem.general *To:* arslist@ARSLIST.ORG *Sent:* Wednesday, February 07, 2007 4:51 PM *Subject:* Re: RANT: Diary fields in a dialog box ** Agreed, but it does tend to be a bit of a pain if you are doing something like viewing a record in a dialog box, and that record has diary fields, and you need to edit that diary field from the dialog box... What then without any workarounds such as setting the historical part into a read only field and having a display only field editable to push the new content... Maybe I didn't really word my original post properly.. When this dialog box is opened, it would be nice if the set field happens like it does for any other field, I'm not contesting that.. But diary fields in the dialog should have been able to recognize the historical part and open it in a histry box below the editable part just like it does when you open the record in a Modify mode... Joe - Original Message From: Grooms, Frederick W [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 7:36:23 PM Subject: Re: RANT: Diary fields in a dialog box ** I believe that is the correct workflow for the system to do. You are doing a Set Fields to the diary field. That always puts that data into the editable portion. Why should it work differently on a Dialog than it would on a regular form? How would the system know if you were wanting the data to be the historical data or just pre-populating data for the user to add to? Personally if I am doing something like that I put the historical data into a display only (read only) character field. Fred *From:* Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] *On Behalf Of *Joe DeSouza *Sent:* Wednesday, February 07, 2007 5:38 PM *To:* arslist@ARSLIST.ORG *Subject:* RANT: Diary fields in a dialog box ** Wonder why is it Remedy has never addressed to the issue that if you open up a dialog box that contains a diary field, and there is a set field action that brings in values from a record on open of the dialog, the Diary field doesn't behave like its should have behaved. There is no uneditable historical part for the field and an editable one. Everything from history gets set to the editable part so if you want to edit its contents it adds all this plus what you add during the transaction, to the diary for each transaction Any idea as to whether or not this issue will ever be addressed to?? Joe -- Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where
Re: RANT: Diary fields in a dialog box....
I just designed what I think is a sleek workaround, that would not require building any display only fields on the current form :-) Here's what I thought I'll do... On the diary fields properties I'll hide the Expand Box, and create a small square button with the same icon as the diary field on that expand box so as far as the users are concerned it will look like a diary field on the front end... On hitting the button, I'll launch another dialog that contains 2 fields with labels Diary History: and Diary Editor: and place the fields in such a way on a gray color form that it would look just like a Diary field when expanded. Only things the users would miss is the ability to view files etc from the menus and the ability to resize the dialog box with the fields resizing proportionatly... Datawise, things should be seamless as long as workflow to push and set the info in the right place is in order... Cheers Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. - Original Message From: Axton [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Thursday, February 8, 2007 9:57:46 AM Subject: Re: RANT: Diary fields in a dialog box ** If you do submit an RFE, do the legwork before submitting it. Detail how you want the app to act and respond to as many scenarios as you can think of. Axton Grams On 2/8/07, Joe DeSouza [EMAIL PROTECTED] wrote: ** You hit the nail on the head Axton.. That's exactly the root of my problems whenever I use diary fields on dialog boxes.. If an original bit of workflow used matching Id's to set values into it, the moment a diary field is added and has to be a part of that dialog (which was my case here) booom... I have to make changes to workflow that sets fields etc.. What I'm thinking of doing is almost close to your suggestion but I don't quite like that idea of creating 2 display only fields, one read only for setting the history part, the other display only for adding new stuff.. Workable but not screen smart on the aesthetic point of view when you are using more real estate to do what could have been done OTB if reading and writing data to and from both the editable and history part of the worklog fields was a little smarter.. As Shyam Attavar, suggested I wonder if this would be useful to have as a RFE as I really think this would save a lot of us a lot of sweat plus have our dialog boxes containing diaries a function better without the need for creating those unnecessary display fields... Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. - Original Message From: Axton [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 10:33:10 PM Subject: Re: RANT: Diary fields in a dialog box ** Just don't use diary fields. In the case of the packaged apps, create a display only character field and allow updates to that field. Unfortunate side effect is that you can not use matching id's in one of 2 actions (on open/set or save/push). Axton On 2/7/07, Shyam Attavar [EMAIL PROTECTED] wrote: ** Joe, In my opinion this would go into the RFE bucket. Maybe worth a shot, since BMC/Remedy uses diary fields in their OOB applications. -- Shyam - Original Message - From: Joe DeSouza Newsgroups: gmane.comp.crm.arsystem.general To: arslist@ARSLIST.ORG Sent: Wednesday, February 07, 2007 4:51 PM Subject: Re: RANT: Diary fields in a dialog box ** Agreed, but it does tend to be a bit of a pain if you are doing something like viewing a record in a dialog box, and that record has diary fields, and you need to edit that diary field from the dialog box... What then without any workarounds such as setting the historical part into a read only field and having a display only field editable to push the new content... Maybe I didn't really word my original post properly.. When this dialog box is opened, it would be nice if the set field happens like it does for any other field, I'm not contesting that.. But diary fields in the dialog should have been able to recognize the historical part and open it in a histry box below the editable part just like it does when you open the record in a Modify mode... Joe - Original Message From: Grooms, Frederick W [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 7:36:23 PM Subject: Re: RANT: Diary fields in a dialog box ** I believe that is the correct workflow for the system to do. You are doing a Set Fields to the diary field. That always puts that data into the editable portion. Why should it work differently on a Dialog than it would on a regular form? How would the system know if you were wanting the data to be the historical data or just pre-populating data for the user to add to? Personally if I am doing something like that I put the historical data into a display only (read only) character field . Fred From: Action
Re: RANT: Diary fields in a dialog box....
Joe, I do not think you need to take up more screen space. Keep the history stuff in a hidden field. (This can use the fieldID from the source form) Show the edit portion of the diary field. (This should use a value for the dialog UI.) Add a button that opens a dialog window that shows the hidden (read only) part and the current value of the edit portion too. When the dialog closes map the value of the edit portion back to the Edit field. When you leave the dialog. Clear the Hidden part of the diary, and set it with the contents of the Edit field. (And I think your on close mappings can still work by ID.) In fact I think that design patterns only adds: 1) One Generic UI for Diary like window 2) a standard close dialog button (could be hidden) to tie workflow to move data around before/after the apply action action in Active links. 3) Per diary on the dialog. Orginal diary field (by ID) New edit field for the diary. New button for open/close map into Generic UI for Diary One active link for above button. One active link on close button to clear/set Original diary field (by ID) before return of values And the only thing that I think you will loose is the hover over ability to show the last entry of the diary in the edit portion of the UI. But besides all of that Why use a Diary field at all? There are better parent child models that allow entry level access controls that would be generally better anyway. (And with Push actions now in the tool, these are very easy to build/maintain.) And if you look at the new v7 ITSM... you might be hard pressed to find a Diary field. :) Yes they are there.. but they are few in number. (193 forms out of 1033 for Incident and Problem have at least one diary field on them. But I have no easy way to count if the users see them or if they are there for just backend logs.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 2/8/07, Joe DeSouza [EMAIL PROTECTED] wrote: ** You hit the nail on the head Axton.. That's exactly the root of my problems whenever I use diary fields on dialog boxes.. If an original bit of workflow used matching Id's to set values into it, the moment a diary field is added and has to be a part of that dialog (which was my case here) booom... I have to make changes to workflow that sets fields etc.. What I'm thinking of doing is almost close to your suggestion but I don't quite like that idea of creating 2 display only fields, one read only for setting the history part, the other display only for adding new stuff.. Workable but not screen smart on the aesthetic point of view when you are using more real estate to do what could have been done OTB if reading and writing data to and from both the editable and history part of the worklog fields was a little smarter.. As Shyam Attavar, suggested I wonder if this would be useful to have as a RFE as I really think this would save a lot of us a lot of sweat plus have our dialog boxes containing diaries a function better without the need for creating those unnecessary display fields... Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. - Original Message From: Axton [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 10:33:10 PM Subject: Re: RANT: Diary fields in a dialog box ** Just don't use diary fields. In the case of the packaged apps, create a display only character field and allow updates to that field. Unfortunate side effect is that you can not use matching id's in one of 2 actions (on open/set or save/push). Axton ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: RANT: Diary fields in a dialog box....
Strange but thats exactly what me and a colleague of mine designed.. I've decided to hide the expansion box of the diary field and build another dialog having 2 fields for the edit and non edit part and 2 buttons OK and Cancel and emulate the diary field functionality using a small button near the actual diary field that brings up this second dialog.. Only functions that users wont be able to do is resize the dialog and have these 2 fields resize automatically, and the option of saving the contents of a diary field to a file or writing from a file to the diary field.. you cant really get it all and yet make it look like the original field.. I could add the edit boxes for those 2 fields but the look and feel will differ distintively.. Rgds Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. - Original Message From: Carey Matthew Black [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Thursday, February 8, 2007 11:24:22 AM Subject: Re: RANT: Diary fields in a dialog box Joe, I do not think you need to take up more screen space. Keep the history stuff in a hidden field. (This can use the fieldID from the source form) Show the edit portion of the diary field. (This should use a value for the dialog UI.) Add a button that opens a dialog window that shows the hidden (read only) part and the current value of the edit portion too. When the dialog closes map the value of the edit portion back to the Edit field. When you leave the dialog. Clear the Hidden part of the diary, and set it with the contents of the Edit field. (And I think your on close mappings can still work by ID.) In fact I think that design patterns only adds: 1) One Generic UI for Diary like window 2) a standard close dialog button (could be hidden) to tie workflow to move data around before/after the apply action action in Active links. 3) Per diary on the dialog. Orginal diary field (by ID) New edit field for the diary. New button for open/close map into Generic UI for Diary One active link for above button. One active link on close button to clear/set Original diary field (by ID) before return of values And the only thing that I think you will loose is the hover over ability to show the last entry of the diary in the edit portion of the UI. But besides all of that Why use a Diary field at all? There are better parent child models that allow entry level access controls that would be generally better anyway. (And with Push actions now in the tool, these are very easy to build/maintain.) And if you look at the new v7 ITSM... you might be hard pressed to find a Diary field. :) Yes they are there.. but they are few in number. (193 forms out of 1033 for Incident and Problem have at least one diary field on them. But I have no easy way to count if the users see them or if they are there for just backend logs.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 2/8/07, Joe DeSouza [EMAIL PROTECTED] wrote: ** You hit the nail on the head Axton.. That's exactly the root of my problems whenever I use diary fields on dialog boxes.. If an original bit of workflow used matching Id's to set values into it, the moment a diary field is added and has to be a part of that dialog (which was my case here) booom... I have to make changes to workflow that sets fields etc.. What I'm thinking of doing is almost close to your suggestion but I don't quite like that idea of creating 2 display only fields, one read only for setting the history part, the other display only for adding new stuff.. Workable but not screen smart on the aesthetic point of view when you are using more real estate to do what could have been done OTB if reading and writing data to and from both the editable and history part of the worklog fields was a little smarter.. As Shyam Attavar, suggested I wonder if this would be useful to have as a RFE as I really think this would save a lot of us a lot of sweat plus have our dialog boxes containing diaries a function better without the need for creating those unnecessary display fields... Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. - Original Message From: Axton [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 10:33:10 PM Subject: Re: RANT: Diary fields in a dialog box ** Just don't use diary fields. In the case of the packaged apps, create a display only character field and allow updates to that field. Unfortunate side effect is that you can not use matching id's in one of 2 actions (on open/set or save/push). Axton Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http
Re: RANT: Diary fields in a dialog box....
Hum... Resize could be done via views designed for specific desktop sizes... (with window open/close events to switch views.) Not as any sized as the original, but very close. Writing the field contents to a file... Sounds like a Report to file to me. Reading a files contents into the field sounds like a $PROCESS$ more|less|type call to me. (likely not working on the Web however.) And I think you could even make it a non-dialog window too. (If your first window was not a dialog.) and let you keep multiple of those windows open at a time. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 2/8/07, Joe DeSouza [EMAIL PROTECTED] wrote: ** Strange but thats exactly what me and a colleague of mine designed.. I've decided to hide the expansion box of the diary field and build another dialog having 2 fields for the edit and non edit part and 2 buttons OK and Cancel and emulate the diary field functionality using a small button near the actual diary field that brings up this second dialog.. Only functions that users wont be able to do is resize the dialog and have these 2 fields resize automatically, and the option of saving the contents of a diary field to a file or writing from a file to the diary field.. you cant really get it all and yet make it look like the original field.. I could add the edit boxes for those 2 fields but the look and feel will differ distintively.. Rgds Joe D'Souza Remedy Developer / Consultant, BearingPoint, Virginia. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: RANT: Diary fields in a dialog box....
I believe that is the correct workflow for the system to do. You are doing a Set Fields to the diary field. That always puts that data into the editable portion. Why should it work differently on a Dialog than it would on a regular form? How would the system know if you were wanting the data to be the historical data or just pre-populating data for the user to add to? Personally if I am doing something like that I put the historical data into a display only (read only) character field. Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza Sent: Wednesday, February 07, 2007 5:38 PM To: arslist@ARSLIST.ORG Subject: RANT: Diary fields in a dialog box ** Wonder why is it Remedy has never addressed to the issue that if you open up a dialog box that contains a diary field, and there is a set field action that brings in values from a record on open of the dialog, the Diary field doesn't behave like its should have behaved. There is no uneditable historical part for the field and an editable one. Everything from history gets set to the editable part so if you want to edit its contents it adds all this plus what you add during the transaction, to the diary for each transaction Any idea as to whether or not this issue will ever be addressed to?? Joe ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: RANT: Diary fields in a dialog box....
Agreed, but it does tend to be a bit of a pain if you are doing something like viewing a record in a dialog box, and that record has diary fields, and you need to edit that diary field from the dialog box... What then without any workarounds such as setting the historical part into a read only field and having a display only field editable to push the new content... Maybe I didn't really word my original post properly.. When this dialog box is opened, it would be nice if the set field happens like it does for any other field, I'm not contesting that.. But diary fields in the dialog should have been able to recognize the historical part and open it in a histry box below the editable part just like it does when you open the record in a Modify mode... Joe - Original Message From: Grooms, Frederick W [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 7:36:23 PM Subject: Re: RANT: Diary fields in a dialog box ** I believe that is the correct workflow for the system to do. You are doing a Set Fields to the diary field. That always puts that data into the editable portion. Why should it work differently on a Dialog than it would on a regular form? How would the system know if you were wanting the data to be the historical data or just pre-populating data for the user to add to? Personally if I am doing something like that I put the historical data into a display only (read only) character field. Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza Sent: Wednesday, February 07, 2007 5:38 PM To: arslist@ARSLIST.ORG Subject: RANT: Diary fields in a dialog box ** Wonder why is it Remedy has never addressed to the issue that if you open up a dialog box that contains a diary field, and there is a set field action that brings in values from a record on open of the dialog, the Diary field doesn't behave like its should have behaved. There is no uneditable historical part for the field and an editable one. Everything from history gets set to the editable part so if you want to edit its contents it adds all this plus what you add during the transaction, to the diary for each transaction Any idea as to whether or not this issue will ever be addressed to?? Joe TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. http://tv.yahoo.com/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: RANT: Diary fields in a dialog box....
Joe, In my opinion this would go into the RFE bucket. Maybe worth a shot, since BMC/Remedy uses diary fields in their OOB applications. -- Shyam - Original Message - From: Joe DeSouza Newsgroups: gmane.comp.crm.arsystem.general To: arslist@ARSLIST.ORG Sent: Wednesday, February 07, 2007 4:51 PM Subject: Re: RANT: Diary fields in a dialog box ** Agreed, but it does tend to be a bit of a pain if you are doing something like viewing a record in a dialog box, and that record has diary fields, and you need to edit that diary field from the dialog box... What then without any workarounds such as setting the historical part into a read only field and having a display only field editable to push the new content... Maybe I didn't really word my original post properly.. When this dialog box is opened, it would be nice if the set field happens like it does for any other field, I'm not contesting that.. But diary fields in the dialog should have been able to recognize the historical part and open it in a histry box below the editable part just like it does when you open the record in a Modify mode... Joe - Original Message From: Grooms, Frederick W [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 7:36:23 PM Subject: Re: RANT: Diary fields in a dialog box ** I believe that is the correct workflow for the system to do. You are doing a Set Fields to the diary field. That always puts that data into the editable portion. Why should it work differently on a Dialog than it would on a regular form? How would the system know if you were wanting the data to be the historical data or just pre-populating data for the user to add to? Personally if I am doing something like that I put the historical data into a display only (read only) character field. Fred -- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza Sent: Wednesday, February 07, 2007 5:38 PM To: arslist@ARSLIST.ORG Subject: RANT: Diary fields in a dialog box ** Wonder why is it Remedy has never addressed to the issue that if you open up a dialog box that contains a diary field, and there is a set field action that brings in values from a record on open of the dialog, the Diary field doesn't behave like its should have behaved. There is no uneditable historical part for the field and an editable one. Everything from history gets set to the editable part so if you want to edit its contents it adds all this plus what you add during the transaction, to the diary for each transaction Any idea as to whether or not this issue will ever be addressed to?? Joe -- Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: RANT: Diary fields in a dialog box....
Just don't use diary fields. In the case of the packaged apps, create a display only character field and allow updates to that field. Unfortunate side effect is that you can not use matching id's in one of 2 actions (on open/set or save/push). Axton On 2/7/07, Shyam Attavar [EMAIL PROTECTED] wrote: ** Joe, In my opinion this would go into the RFE bucket. Maybe worth a shot, since BMC/Remedy uses diary fields in their OOB applications. -- Shyam - Original Message - *From:* Joe DeSouza [EMAIL PROTECTED] *Newsgroups:* gmane.comp.crm.arsystem.general *To:* arslist@ARSLIST.ORG *Sent:* Wednesday, February 07, 2007 4:51 PM *Subject:* Re: RANT: Diary fields in a dialog box ** Agreed, but it does tend to be a bit of a pain if you are doing something like viewing a record in a dialog box, and that record has diary fields, and you need to edit that diary field from the dialog box... What then without any workarounds such as setting the historical part into a read only field and having a display only field editable to push the new content... Maybe I didn't really word my original post properly.. When this dialog box is opened, it would be nice if the set field happens like it does for any other field, I'm not contesting that.. But diary fields in the dialog should have been able to recognize the historical part and open it in a histry box below the editable part just like it does when you open the record in a Modify mode... Joe - Original Message From: Grooms, Frederick W [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, February 7, 2007 7:36:23 PM Subject: Re: RANT: Diary fields in a dialog box ** I believe that is the correct workflow for the system to do. You are doing a Set Fields to the diary field. That always puts that data into the editable portion. Why should it work differently on a Dialog than it would on a regular form? How would the system know if you were wanting the data to be the historical data or just pre-populating data for the user to add to? Personally if I am doing something like that I put the historical data into a display only (read only) character field. Fred -- *From:* Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] *On Behalf Of *Joe DeSouza *Sent:* Wednesday, February 07, 2007 5:38 PM *To:* arslist@ARSLIST.ORG *Subject:* RANT: Diary fields in a dialog box ** Wonder why is it Remedy has never addressed to the issue that if you open up a dialog box that contains a diary field, and there is a set field action that brings in values from a record on open of the dialog, the Diary field doesn't behave like its should have behaved. There is no uneditable historical part for the field and an editable one. Everything from history gets set to the editable part so if you want to edit its contents it adds all this plus what you add during the transaction, to the diary for each transaction Any idea as to whether or not this issue will ever be addressed to?? Joe -- Bored stiff? http://us.rd.yahoo.com/evt=49935/*http://games.yahoo.comLoosen up... Download and play hundreds of games for freehttp://us.rd.yahoo.com/evt=49935/*http://games.yahoo.comon Yahoo! Games. __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
