Parsing JSON Failed - when Adding File Attachments.
Spooner
Member IT Monkey ✭
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?
0
Answers
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
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.
Sorry about this... but would you want to try the workaround in your test environment?
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.
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!
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
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?
We've just had this and it was a simple one, the disc space on the web server was zero, assuming the issue is that it cant then save to the temp folder.