IT Monkey:   


Formal Cireson Support (phone, email, and web) is not included with the free Self-Service Portal – Community app. For trouble shooting assistance, take advantage of the Cireson Community to find answers to your questions. However, if you’d like to purchase a Support Package to access more formal Cireson Support (phone, email, and web), please contact us today to learn more on the pricing options.

Parsing JSON Failed - when Adding File Attachments.

I don't recall this being an issues in previous testing of the portal, but I'm now getting a failure on all File Attachment attempts on existing request offerings. This is occurring on both a lab environment and our production environment. I've tried standard cycling actions (IIS, CacheBuilder, Server), removing the prompt from the request offering and adding it back, unpublish/republish, etc. 

If I create a new Request Offering with a File Attachment prompt, everything works just fine.

Is there any way I can fix these existing ones without having to recreate the whole offering again?

Answers

  • Davis_MathaiDavis_Mathai Cireson Solution Architect Adept IT Monkey ✭✭
    Hi,
    I've seen this before when the request offering is linked to a template for Incident or Service Request that is customised with an inherited class.  Is the case for your failing ones?  I expect that the new one you are creating is using the default SR/IR template?

    Unfortunately, the way the portal is coded, it is difficult to support an inherited class extension. The server code tries to determine the maximum file size permitted for the attachment based on the class name of the work item targeted by the template. It is hard-coded for the various work item class names and there is no fall back based on the parent class.  If this is the issue, there is a workaround but it involves editing a SQL stored procedure.  But this will likely get overwritten when the product is updated.

    Thanks,
    Davis
  • SpoonerSpooner Member IT Monkey ✭

    Thanks for the quick reply!

    That about sums up the issue.

    The two that are failing are based on inherited classes I've created (One for Server Requests and one for Project Requests), the 'test' one is just an empty Request tied to the Default Service Request class.

    This appears to have been working initially, possibly(likely) before I updated the portal to the newest version, I'm looking at an old request with an attachment using one of the same classes. There's a better than average chance I didn't test File Attachments after the upgrade, though I can't be 100% on that.

  • Davis_MathaiDavis_Mathai Cireson Solution Architect Adept IT Monkey ✭✭
    Hi again, its unlikely that it would have worked before the upgrade as the class name for the IR/SR was always hardcoded as far as I know.
    Sorry about this... but would you want to try the workaround in your test environment?

  • SpoonerSpooner Member IT Monkey ✭

    You are correct! I did a double check and that SR certainly appears to be one of the last SRs from the Microsoft portal.

    I certainly would like to try a work around for this, as it's a pretty desired part of our plan.

  • SpoonerSpooner Member IT Monkey ✭

    Hi Davis,

    I'd love to try a workaround when you have a minute, as this becomes a real show stopper for us on the portal implementation.

    Thanks!

  • Davis_MathaiDavis_Mathai Cireson Solution Architect Adept IT Monkey ✭✭
    Hi- really sorry for the slow response!
    Here is something I received from support for another customer and involves modifying the stored procedure spGet_RequestOfferingById.  The code is modifying the SP so that it returns the OOB SR class name instead of the extended one.  Again, this is provided without warranty so please try in a test environment and backup the SP as a minimum...

    Hope this helps!

    ALTER PROCEDURE [dbo].[spGet_RequestOfferingById]

           @Id uniqueidentifier

    AS

    BEGIN

           SET NOCOUNT ON;

          

           SELECT  so.Image AS SOImage

                 , so.Title AS SOTitle, so.CategoryId

                    , ro.Image AS ROImage

                    , ro.Title AS ROTitle

                    , ro.BriefDescription

                    , ro.Id AS ROId

                    , so.Id AS SOId

                 , CASE ro.TargetTemplateType

                        WHEN '<Extended Class Name>' THEN 'System.WorkItem.ServiceRequest'

                           ELSE ro.TargetTemplateType

                           END AS TargetTemplateType

                    , ro.LinkUrl

                    , ro.LinkUrlTargetType

                    , ro.PresentationMappingTemplate AS PresentationMappingTemplate

        FROM ServiceOffering so

        INNER JOIN Contains_ServiceOffering_RequestOffering soro ON so.Id = soro.ServiceOfferingId

        INNER JOIN RequestOffering ro ON soro.RequestOfferingId = ro.Id

        WHERE ro.Id = @id

    END


  • SpoonerSpooner Member IT Monkey ✭
    Sorry for the delay in testing this, unfortunately I'm still getting the same JSON error as before.
  • Michael_AidinovichMichael_Aidinovich Cireson Solution Architect Advanced IT Monkey ✭✭✭
    Hi Chris,

    I assume you are receiving the error message from the RO, if so, did you replace the '<Extended Class Name>' with your full class name? 
Sign In or Register to comment.