« Back
You are in :
Recent Topics »
SupportCenter Plus »Version 7 - Description >64k creates attachment?
Vinu, Support
It then creates RequestDescription.html within SupportCenter but doesn't get forwarded to the Support Rep, we have to go into SupportCenter tio read the response.
Why does it do this, I don't want it to create an attachment within SupportCenter, the other version didn't do this, and was hoping this would be fixed in the hotfix but its not.
If the support calls are long I'm just going to get a load of response emails and they are all going to read
"The size of the description being greater than 64K, the content has been moved to attachment RequestDescription.html"
Shortly, not much point is there.....
Again this is a real pain, as we also have some people who need the notifications and responses to their email on PDA's if they are away from their desks or out on site. If they have the call open and a customer responds they need to see the message.
This is now completely useless to us as the response is within SupportCenter, within an attachment, so they can't see the customers response and ask someone else to action in their absence.
Please advise as this wasn't actioned in the 7001 hotfix,
Regards
Rich
_______________________________________
From: Support
Sent: 18 March 2008 14:28
To:
Subject: RE: Support ID ##21058## - Email problems
Hemperly, Nancy has replied
The size of the description being greater than 64K, the content has been moved to attachment RequestDescription.html
It then creates RequestDescription.html within SupportCenter but doesn't get forwarded to the Support Rep, we have to go into SupportCenter tio read the response.
Why does it do this, I don't want it to create an attachment within SupportCenter, the other version didn't do this, and was hoping this would be fixed in the hotfix but its not.
If the support calls are long I'm just going to get a load of response emails and they are all going to read
"The size of the description being greater than 64K, the content has been moved to attachment RequestDescription.html"
Shortly, not much point is there.....
Again this is a real pain, as we also have some people who need the notifications and responses to their email on PDA's if they are away from their desks or out on site. If they have the call open and a customer responds they need to see the message.
This is now completely useless to us as the response is within SupportCenter, within an attachment, so they can't see the customers response and ask someone else to action in their absence.
Please advise as this wasn't actioned in the 7001 hotfix,
Regards
Rich
_______________________________________
From: Support
Sent: 18 March 2008 14:28
To:
Subject: RE: Support ID ##21058## - Email problems
Hemperly, Nancy has replied
The size of the description being greater than 64K, the content has been moved to attachment RequestDescription.html
Hi Rich,
Moving large emails as attachments is by design because they get truncated when stored in the database. We are working on finding an alternative solution to this problem, but cannot commit a time frame as of now.
Regards,
Vinu Sreedharan
Moving large emails as attachments is by design because they get truncated when stored in the database. We are working on finding an alternative solution to this problem, but cannot commit a time frame as of now.
Regards,
Vinu Sreedharan
Vinu,
This isn't a workable scenario for us, and a change of this magnitude is not acceptable as a "by design" implementation without advising anyone of this change.
I can't find anything in any of the release notes specifying this change.
As per my notes within this post, support representitives who are out of the office need to see these emails on their PDA's, HTML email attachments are not an option.
If the implementation of the suggestion I had where you chose a secondary support repensentive if the support rep doesn't sign in to the system so that someone else gets the emails this would have been a small help in this case.
This is totally useless to us.
Please explain further why this decision was made, it worked perfectly alright for us previously, and I didn't see this as an entry on the "Roadmap" for this "feature"
I want to be given the option to add these as attachments or not, and I would guess that a number of people won't want this.
I need some feedback on this please Vinu, I need to make my staff aware of the situation and how long this is going to take to resolve. Even if you have to implement the code from 6500 into a version of 7001 so that people have a choice I feel this needs to be looked at.
You need to give me some sort of workaround or resolve time on this, it's distrupting our team badly.
As I have now had 7000 and 7001 in place I can't roll back to 6500 as I am going to loose weeks worth of work. If you have an alternative into how I get new records rolled back this maybe my best option,
Cheers
Rich
This isn't a workable scenario for us, and a change of this magnitude is not acceptable as a "by design" implementation without advising anyone of this change.
I can't find anything in any of the release notes specifying this change.
As per my notes within this post, support representitives who are out of the office need to see these emails on their PDA's, HTML email attachments are not an option.
If the implementation of the suggestion I had where you chose a secondary support repensentive if the support rep doesn't sign in to the system so that someone else gets the emails this would have been a small help in this case.
This is totally useless to us.
Please explain further why this decision was made, it worked perfectly alright for us previously, and I didn't see this as an entry on the "Roadmap" for this "feature"
I want to be given the option to add these as attachments or not, and I would guess that a number of people won't want this.
I need some feedback on this please Vinu, I need to make my staff aware of the situation and how long this is going to take to resolve. Even if you have to implement the code from 6500 into a version of 7001 so that people have a choice I feel this needs to be looked at.
You need to give me some sort of workaround or resolve time on this, it's distrupting our team badly.
As I have now had 7000 and 7001 in place I can't roll back to 6500 as I am going to loose weeks worth of work. If you have an alternative into how I get new records rolled back this maybe my best option,
Cheers
Rich
We are having the same issue. Since we use ServiceDesk for compliance tracking, they need to be searchable. When the attachment is added, it cannot be searched through the web interface.
hello?
Vinu,
Whilst I'm sure that your team had everyone's best intentions at heart when this change was implemented I must say that I agree with Rich when it comes down to not consulting the very people who it effects - us, your end users. This is not the only change which has been made since version 6500 which either wasn't documented, wasn't discussed, or simply didn't need to be made.
I can see that the problem of truncated emails is one which needed a fix, but completely disagree with the method you've gone about fixing it. At very least a change of this magnitude should have been provided with a switch facility so that we could have chosen whether or not to use it - it should not have been a mandatory 'fix' which has, as I'm sure you're now aware, caused more problems.
One solution may have been to allow the truncation to continue but to save the full email response into a file - effectively the best of both worlds. This would have allowed everyone to view the latest response via support centre and the update emails, whilst also reviewing the entire email history via the attachment if necessary.
Thank you for the continued efforts of yourself and your team to make this product better, but can I please ask that in future all planned changes are discussed with a select user-group before they're implemented and released, I think it would save everyone a lot of time and money - not to mention possible revenue losses for your company as people loose faith in the ability to provide a stable platform.
Regards,
Andy
Whilst I'm sure that your team had everyone's best intentions at heart when this change was implemented I must say that I agree with Rich when it comes down to not consulting the very people who it effects - us, your end users. This is not the only change which has been made since version 6500 which either wasn't documented, wasn't discussed, or simply didn't need to be made.
I can see that the problem of truncated emails is one which needed a fix, but completely disagree with the method you've gone about fixing it. At very least a change of this magnitude should have been provided with a switch facility so that we could have chosen whether or not to use it - it should not have been a mandatory 'fix' which has, as I'm sure you're now aware, caused more problems.
One solution may have been to allow the truncation to continue but to save the full email response into a file - effectively the best of both worlds. This would have allowed everyone to view the latest response via support centre and the update emails, whilst also reviewing the entire email history via the attachment if necessary.
Thank you for the continued efforts of yourself and your team to make this product better, but can I please ask that in future all planned changes are discussed with a select user-group before they're implemented and released, I think it would save everyone a lot of time and money - not to mention possible revenue losses for your company as people loose faith in the ability to provide a stable platform.
Regards,
Andy
Andy & Others,
Thanks for writing to us & letting us know your concerns.
We have been contemplating a permanent solution for this. We are planning to move the email description to files which will not have this restriction. But it will take some time for us to implement that.
Meanwhile, we will provide the workaround as suggested by you. This will be available before the end of next week. The workaround will work this way : Emails larger than the 64k limit will get truncated when stored in the database. So, apart from storing the email description in the database (which will be truncated), we will also add the description as an attachment to the request.
Regards,
Vinu Sreedharan
Thanks for writing to us & letting us know your concerns.
We have been contemplating a permanent solution for this. We are planning to move the email description to files which will not have this restriction. But it will take some time for us to implement that.
Meanwhile, we will provide the workaround as suggested by you. This will be available before the end of next week. The workaround will work this way : Emails larger than the 64k limit will get truncated when stored in the database. So, apart from storing the email description in the database (which will be truncated), we will also add the description as an attachment to the request.
Regards,
Vinu Sreedharan
Thanks for the update and fix confirmation Vinu.
For the record, I am still happy with the software as a whole, just a little surprised by the latest release. If you guys are able to learn from the mistakes of 7000 and provide a more robust release, coupled with some improved communications, I think everyone's going to be happy and you're going to have a lot less work on your hands ;)
For the record, I am still happy with the software as a whole, just a little surprised by the latest release. If you guys are able to learn from the mistakes of 7000 and provide a more robust release, coupled with some improved communications, I think everyone's going to be happy and you're going to have a lot less work on your hands ;)
Is there a fix for this yet?
When the messages are truncated all the special Swedish signs are becoming unreadable.
Looking forward to getting this fixed.
When the messages are truncated all the special Swedish signs are becoming unreadable.
Looking forward to getting this fixed.
Post Actions
Corp