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: [email protected]
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"
