[Date Prev] [Date Next] [Prev in Thread] [Next in Thread] [Date Index] [Thread Index]

Re: EXTERNAL: Re: Is it a good idea to eliminate the use of Diary Fields?



**

I’ve actually used something similar but still captured “work log” table entries into a diary field. A belt and suspenders approach.

The diary was for reporting but I’d like to get away from that.

On a side note; Are there any tutorials for sub-reports using BIRT and a .rptdesign file?

 

Thank you,

---
John J. Reiser
Building 760-J202
Remedy AR System Developer

Senior Software Development Analyst
Lockheed Martin - RMS Moorestown Region
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased by me

 

From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller
Sent: Friday, March 17, 2017 4:19 AM
To: arslist@ARSLIST.ORG
Subject: EXTERNAL: Re: Is it a good idea to eliminate the use of Diary Fields?

 

**

I think you an I are on the same page. We have the filtering and public features too :)

 


 

Good point about being able to interact with the records. We can send an email from the request (the envelope button) and the recipient can response via a URL which adds a work log entry. That response row is yellow until it is marked as being read.

 

Jason

 

On Thu, Mar 16, 2017 at 7:31 PM, Joe D'Souza <jdsouza@shyle.net> wrote:

**

One of the reasons I like the table idea better than the traditional diary field is the ability to classify each log entry – Requirements, Test Plan, etc.. For a viewer of the record, it becomes easy on the eye to go through the log entries if they are looking for something specific.

 

I also like the flexibility you have to keep entries internal or public, lock or keep it open for editing.. And the flexibility to select the time in case a user as not able to log the entry at the time he/she should have for whatever reasons.. I also like the advantage this method has by way of attachments for each log entry if needed.

 

Ever since BMC introduced this concept I personally have always opted to choose this approach for any custom apps I have built rather than using the traditional diary field..

 

It opens a world of other customization possibilities... For eg if you want to make this interactive with the users, you could add a “ratings” functionality to rate each entry in the log field on a scale of 1 to 5 or Like or Unlike it just like you would in a social feed.. OR was this entry useful to you Yes/No. Or you could customize it to suppress “white noise” type of entries if you wanted to if you did not want everything to show up in the default view..

 

Joe

 


From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller
Sent: Wednesday, March 15, 2017 5:51 PM
To: arslist@ARSLIST.ORG
Subject: Re: Is it a good idea to eliminate the use of Diary Fields?

 

**

When we build our new Change Management and Service Desk apps we went with the table option. We had the same requirement to allow people to pull a single record with Work Log into a spreadsheet via web reports, Crystal, etc. We don't differentiate between Work Log entries and Audit records except with a Record Type flag so they are all in the same form.  We were able to do this with a little SQL magic in a SQL view --> View form --> Join to SD/CM. Our SD and CM forms have their own Work Log form so we have a SQL view for CM and one for SD.

 

Basically our SQL view (MS SQL Server) selects a handful of columns from the CM or SD SQL view (the one created by Remedy) and then has a sub-select on the work log form SQL view (created by Remedy) that uses "STUFF" and "XML Path" to put all of the work log entries into a single record's column. We sprinkle in some replaces and a epoch to date/time function (that I originally got of the List) to make it look like a diary field entry. The only difference in looks from a diary field is the timestamp is in 24 hr format instead of 12 hr (we just would need to update our function to adjust it). 

 

Inline image 1

 

Jason

 

On Wed, Mar 15, 2017 at 1:13 PM, LJ LongWing <lj.longwing@gmail.com> wrote:

**

John,

BMC themselves went away from Diary fields for the most part (certainly in the work log process) many years ago....the down side, as you pointed out is storing the diary in individual records causes issues with reporting....this is easily worked around in a sufficiently advanced reporting tool allowing you to create sub-reports reporting all of the diary entries from a second table....the fact that they can't be pulled in the same entry is the only down side that I know of...with plenty of up sides.

 

On Wed, Mar 15, 2017 at 3:06 PM, Reiser, John J <john.j.reiser@lmco.com> wrote:

**

Hello Listers,

 

Is there a downside to replacing diary fields with a different method of capturing work activity?

Since diary fields don’t show up in Mid Tier Web reporting I was looking into a way to replace the diary field for reporting.

 

We actually have reports that get created in csv format for Excel that use the Diary.

Occasionally we have a diary so large it breaks the cell character limit in Excel.

 

I was contemplating using a table field to display records from a work activity form and then using either a join or some other temporary means to gather the activity into a report.

 

Can I use an unlimited Display Only field to dump the diary during the report process?

Is there a better mouse trap for collecting large amounts of data and reporting it?

 

As always, thanks in advance.

 

Thank you,

---
John J. Reiser
Building 760-J202
Remedy AR System Developer

Senior Software Development Analyst
Lockheed Martin - RMS Moorestown Region
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased by me

 

 

 

_ARSlist: "Where the Answers Are" and have been for 20 years_

 

_ARSlist: "Where the Answers Are" and have been for 20 years_

 

_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_

 

_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_