Cireson Partners, Customers and Community members share your customizations and examples here to help benefit the community as a whole to earn Kudos and badges.

DISCLAIMER

All files and projects located here are provided and come "as-is" and without any warranty or support. Use at your own risk. Your use of Community Uploads is subject to our Terms of Use.

Cireson does not and will not support or maintain these enhancements, extensions, and scripts.

For Team Cireson uploads click here.

Custom Apply (save form) when comment is added

Martin_BlomgrenMartin_Blomgren Customer Ninja IT Monkey ✭✭✭✭
edited January 19 in Community Uploads
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

Comments

  • Martin_BlomgrenMartin_Blomgren Customer Ninja IT Monkey ✭✭✭✭
    edited January 23
    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:
    app.custom.formTasks.add('ServiceRequest', null, function (formObj, viewModel) {
        formObj.boundReady(function () {
            CustomActionLogHandler(viewModel.AppliesToWorkItem); // <= WRONG FUNCTION!!
            
        });
    });app.custom.formTasks.add('ChangeRequest', null, function (formObj, viewModel) {
        formObj.boundReady(function () {
            CustomActionLogHandler(viewModel.AppliesToWorkItem); // <= WRONG FUNCTION!!
            
        });
    });

    To the correct function:
    app.custom.formTasks.add('ServiceRequest', null, function (formObj, viewModel) {
        formObj.boundReady(function () {
            CustomSaveFormHandler(viewModel.AppliesToWorkItem); // CORRECT FUNCTION!
           
        });
    });app.custom.formTasks.add('ChangeRequest', null, function (formObj, viewModel) {
        formObj.boundReady(function () {
            CustomSaveFormHandler(viewModel.AppliesToWorkItem); // CORRECT FUNCTION!
           
        });
    });


    Edit: missed the attachment!
  • David_DarlingDavid_Darling Customer IT Monkey ✭

    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_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    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_BlomgrenMartin_Blomgren Customer Ninja IT Monkey ✭✭✭✭
    @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_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    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
    at init.save (wiMain.js?v=799:700)
    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_BlomgrenMartin_Blomgren Customer Ninja IT Monkey ✭✭✭✭
    @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_BlomgrenMartin_Blomgren Customer Ninja IT Monkey ✭✭✭✭
    @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_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    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_BlomgrenMartin_Blomgren Customer Ninja IT Monkey ✭✭✭✭
    @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 :smile:
  • Tom_HendricksTom_Hendricks Customer Ninja IT Monkey ✭✭✭✭
    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-BoKonstantin_Slavin-Bo Customer Advanced IT Monkey ✭✭✭
    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-BoKonstantin_Slavin-Bo Customer Advanced IT Monkey ✭✭✭
    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_BlomgrenMartin_Blomgren Customer Ninja IT Monkey ✭✭✭✭
    @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 :smile:
  • Konstantin_Slavin-BoKonstantin_Slavin-Bo Customer Advanced IT Monkey ✭✭✭
    @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).
Sign In or Register to comment.