Custom Apply (save form) when comment is added

Martin_Blomgren

As several other have noted most end users don't get the concept of saving or applying after they added a comment. I think this is due to the fact that the comment visually is appended to the action log in the page form and because something happened it must have been saved.

I know there is a feature request for this and I think it should be a admin setting so each admin can choose their preferred behavior but in the meanwhile here's a custom solution to this problem where the form will be saved and the page reloaded as per the initial design of the portal.

Tested with IE11, Chrome 55, Firefox 45 & Edge but not all work item types!

I've attached the files needed in a zip archive. To install just drop the files in CustomSpace (merge custom.js if you have other stuff there already!)

This code could easily be integrated into my Custom Action Log

Martin_Blomgren

As it turns our there where a copy paste error on the original version which bundled with custom_ActionLog duplicated all service request and change request entries instead och actually apply the form when adding a comment.

I've attached a fixed version but if you like to edit the file yourself change the following:

<div>app.custom.formTasks.add('ServiceRequest', null, function (formObj, viewModel) {<br>&nbsp;&nbsp;&nbsp; formObj.boundReady(function () {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CustomActionLogHandler(viewModel.AppliesToWorkItem); // <= WRONG FUNCTION!!<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>&nbsp;&nbsp;&nbsp; });<br>});</div><div>app.custom.formTasks.add('ChangeRequest', null, function (formObj, viewModel) {<br>&nbsp;&nbsp;&nbsp; formObj.boundReady(function () {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CustomActionLogHandler(viewModel.AppliesToWorkItem); // <= WRONG FUNCTION!!<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>&nbsp;&nbsp;&nbsp; });<br>});</div>

To the correct function:

<div>app.custom.formTasks.add('ServiceRequest', null, function (formObj, viewModel) {<br>&nbsp;&nbsp;&nbsp; formObj.boundReady(function () {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CustomSaveFormHandler(viewModel.AppliesToWorkItem); // CORRECT FUNCTION!<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; });<br>});</div><div>app.custom.formTasks.add('ChangeRequest', null, function (formObj, viewModel) {<br>&nbsp;&nbsp;&nbsp; formObj.boundReady(function () {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CustomSaveFormHandler(viewModel.AppliesToWorkItem); // CORRECT FUNCTION!<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; });<br>});</div>

Edit: missed the attachment!

David_Darling

This is great, you know what we're really struggling with though is Approvers of RA's within SR's who click Approve, then either do or not not enter comments, but then do not Save...

Can this code be altered at all to account for this situation?

Tom_Hendricks

Bear in mind that I have not ruled out yet whether it is due to my environment or this script, however on save the screen gets overlaid with the three dots and never completes.

I have commented this out for now, but am excited to get it working.  Will update as I discover more about the cause.  (Portal 7.2, SCSM 2016)

Martin_Blomgren

@David_Darling
Should be possible applying the same logic binding a change to pageForm.viewModel.Activity[index].Reviewer.Decision where index is your Review Activity.

@Tom_Hendricks
Do you have any error in the console in developer tools (F12) when trying to add a comment? If you refresh the window is the comment actually saved? Saw this behavior during development where I suspect that the validation between unmodified form and actual form isn't fast enough. You can try to add some time to the timeout at the end, change the zero to for eaxple 200 (milliseconds). When testing just adding the timeout without delay where enough. Will upgrade to portal 7.2, already using SCSM 2016, to verify as well.

Tom_Hendricks

There is no error in the console (tested Chrome and IE), and the comment was not saved.  Now I am testing again with 200ms on the timeout and it is working on existing work items.

However, I attempted it on a new, unsaved ticket, and noticed that it hangs forever if there is a required field left blank.  The required field turns red, but the overlay prevents any interaction with the form, and the ticket is not saved.  An error is generated in the console, as well:

wiMain.js?v=799:700 Uncaught TypeError: failure is not a function<br>    at init.save (wiMain.js?v=799:700)<br>    at eval (eval at <anonymous> (jquery.min.js?v=799:3), <anonymous>:46:13)

Since this whole use case of auto-saving a log entry on an unsaved ticket might be the real issue, perhaps the answer is simply to test pageForm.newWI and not run the function if true.

Martin_Blomgren

@Tom_Hendricks
Until we have a better way to determine when the form I validated you will have to test the minimum accepted timeout. Tested with a new incident adding the comment as first step and get the same error. This is good as now I have something to work with. Hang out for a updated version!

Martin_Blomgren

@Tom_Hendricks
Think it makes most sense to disable this feature when creating a new work item so whenever pageForm.newWI == true the binding that kicks off form save will not run. Also wrapped all code in an anonymous function to make sure that there wont be any naming conflicts in global space!

Everyone, please download the attached updated version.

Tom_Hendricks

The new logic is working as expected.  After working with your new version, I had a thought about clearing the overlay if there is a validation error elsewhere on the form:

At the end of the pageForm.save() (line 52?), replace the "failure" with

function (failure) { app.lib.mask.remove(); }

The good news: In my testing, it solves the overlay problem and allows the user to correct any issues.

The bad news: the log entry has still been added to the action log, but the form has not been saved due to the validation error.  Therefore, the user thinks that they have saved their action log entry, but it is lost when they leave the page.  I have been looking at this between meetings and I just did the easy part here.    There may even be a better way to accomplish this.

Martin_Blomgren

@Tom_Hendricks
Tried to empty the description field and got the same behavior. Changing the second save() parameter to an anonymous function: function(failure){} actually makes us being able to do something about the validation error. The question though is how we should handle this? We could always remove the comment from the action log (pageForm) and display the error message from failure object "Please correct the errors on the form" utilizing app.lib.message. Would that suffice?

It's currently in the middle of the night here so while I do have the time my brain probably isn't at full capacity

Tom_Hendricks

It seems as though you're thinking clearly enough.  That's the same point where I stopped to think about it, too. 

I like the idea of removing the log entry, except that it would then have to be re-typed.  Therefore, I think leaving it in there, but presenting the user with app.lib.message that says something similar to the following might be a happy medium:

"Please correct the errors on the form and then click Save or Apply."

My hesitation is that it should probably be obvious that one needs to save at this point, but maybe not.  To be a little more verbose:

"Please correct the errors on the form.  Your action log entry will not be saved until errors are corrected and the form is saved."

Other thoughts and opinions are welcome here.

Konstantin_Slavin-Bo

How about just not committing the comment to the action log (i.e. remove it) and leaving the text in the comment-box? They would get the default "Please correct the errors on the form" error and the text is still in the comment box, so it's clear, that it's not added yet.

Konstantin_Slavin-Bo

I don't know if anybody is still using it, or whether anybody else has solved the issues discussed, by here's my take on it:

First of all, I've limited the auto save to only apply when the added action log is an Analyst Comment or an End User Comment, as it would auto save on some of the task too. If you don't want this, simply change line 47 to look like this (or remove it completely):

if(true) {

I've also removed all of the mask.apply's, as the portal (at least v8.1.1) is already applying the mask on save().

Then I added a function(failure), which will, on form errors, remove the newest action log (as it should be the newly-added comment); insert the description of the removed log into the commentBox; check actionLogisPrivate based on whether the removed log was private or not. Apparently, we also need to simulate a keyup event, as some validation on the Add-button needs to be triggered, as there aren't any physical key presses. Lastly, a lib message is added and shown, and the window is scrolled to the top.

In my own implementation, I also changed the ChangesApplied message to a hardcoded "Your comment has been added.", but I've kept the localized "Changes have been applied." in the attached file.

Everything works on v8.1.1 and tested in IE, Chrome, FF and Edge.

Martin_Blomgren

@Konstantin_Slavin-Bo, nicely done! Many of the above shortcomings is the reason why we only implemented this for our end users perhaps it's time to rethink

Konstantin_Slavin-Bo

@Martin_Blomgren, thanks, I just picked up where you guys left off. Please let us know of any shortcomings or dysfunctions when you start testing. I'm still testing it too, before releasing it to both end users and analysts, but haven't run into any issues (yet).

Ezequiel_Osorio

Konstantin_Slavin-Bo said:

I don't know if anybody is still using it, or whether anybody else has solved the issues discussed, by here's my take on it:

First of all, I've limited the auto save to only apply when the added action log is an Analyst Comment or an End User Comment, as it would auto save on some of the task too. If you don't want this, simply change line 47 to look like this (or remove it completely):

if(true) {

I've also removed all of the mask.apply's, as the portal (at least v8.1.1) is already applying the mask on save().

Then I added a function(failure), which will, on form errors, remove the newest action log (as it should be the newly-added comment); insert the description of the removed log into the commentBox; check actionLogisPrivate based on whether the removed log was private or not. Apparently, we also need to simulate a keyup event, as some validation on the Add-button needs to be triggered, as there aren't any physical key presses. Lastly, a lib message is added and shown, and the window is scrolled to the top.

In my own implementation, I also changed the ChangesApplied message to a hardcoded "Your comment has been added.", but I've kept the localized "Changes have been applied." in the attached file.

Everything works on v8.1.1 and tested in IE, Chrome, FF and Edge.

Hi,

I cannot get it to work on IE11, nothing happens. Edge works as expected. Does it work on IE11 for you ??

IE 11 version is : 11.674.15063.0

Kind Regards,

Ezequiel

Konstantin_Slavin-Bo

Hey @Ezequiel_Osorio
Yeah, IE 11 works fine here, exactly same version as yours. Do you get any errors in the console? Please try opening devtools by pressing F12, selecting "Console", reload the page, and try to add an action log again. Do you get any errors here? Or just anything at all?

Nick_Flint

What I get via the console in both IE 11 and Chrome is "Unable to get property 'ActionType' of undefined or null reference" on line 47.

Current Portal Version: 8.2.2.2016 

Nick_Flint

I should also mention that the action log is being created both from the Acknowledge task and directly from the Action Log comment box.

Nick_Flint

I was able to get this working in portal version 8.2.2.2016. We want to use this with the Acknowledge task so I removed the check for whether it is an Analyst or End User. The code to remove the last action log wasn't working and wasn't something we needed so I removed that too. 

v0.5 Changes:

//  Removed check for ActionType to use with Acknowledge task 

//  No longer removed action log and adds it back in; if the form isn't fixed and saved it is lost anyway 

//  CustomSaveFormHandler needed reference to the viewModel via pageForm.viewModel

Konstantin_Slavin-Bo

@Nick_Flint
Nice catch! I see, that Cireson changed the actionlog comment box from a textarea to an iframe, probably to support the new @mention functionality.

I updated code of removing and adding back the comment, if there's an error on the form, to support the new iframe editor. It requires a small work-around to enable the Add-button after a form error, but it works in all browsers.

Also, shifting actionLog adds a dublicated entry to the HTML actionlog list (an only in HTML), so the code removes the two newest entries from DOM.

This version still includes the check on ActionType.

PS: It is not necessary to reference pageForm to access viewModel (only when debugging directly in the console), as viewModel is passed to the formTasks.add() function from the app.

Nick_Flint

@Konstantin_Slavin-Bo Thanks for posting that update. We were getting duplicate action log entries every time the Send Email task was used. Your latest code took care of that.