1 2 Previous Next 16 Replies Latest reply on Sep 27, 2014 9:49 AM by Andrew Hicox

    Feature Request: abililty to change attachment file name

    Andrew Hicox

      It is currently not possible to access the three components of an attachment (attachmentName, attachmentData, attachmentOrigSize) except through a set-fields via webservice action. It should be possible to address these three components from other set-fields actions as well.


      This has become an urgent issue for us since upgrading from 7.6.04 to 8.1.01.

      The reason is that prior to 8.1.01, if an attachment object had an 'attachmentName' attribute containing a trailing line or carriage return, the mid-tier would filter this when the user attempted to download or view the attachment. Since 8.1.01, this behavior has been changed. The carriage or line return is now replaced with an underscore ("_") character.


      This means an attachment name of: 'Readme.TXT' (with a line return tacked on the end) becomes 'Readme.TXT_'. This means when the user downloads or otherwise attempts to view the attachment, windows (or whatever OS they're using) will no longer recognize the MIME type and the user gets the "I don't know how to deal with this file type" error.


      So how do you even get attachments where 'attachmentName' contains a line return? Good question!


      It's happening for us via an external webservice integration (we call the webservice to retrieve attachments, and the external webservice returns a value with a trailing carriage return on the XML element that's mapped to attachmentName). For testing purposes, I've also found that it is possible to create such attachments explicitly via the API.


      What makes this absolutely infuriating is that there is absolutely no way to fix the problem (in workflow anyhow).

      It's easy enough to write some workflow to filter the carriage returns from the filename, but there is not any way to update the attachment file name. Likewise, if we were to simply take the 'attachmentName', 'attachmentData', and 'attachmentOrigSize' XML elements and write them into temp fields, we STILL can't create an attachment because you can't address those three components from a regular set-fields action.


      About the best I could do would be to set up my own webservice to set the attachment. Pull the three attachment components into tmp fields, then call my own webservice to update the attachment filename. For various reasons, I refuse to do that. Primarily because it is a completely asinine thing to do, which will undoubtedly cause still more problems.

      Actually, I take it back. That is not the most infuriating part of this.

      The most infuriating part of this is that BMC support sent me HERE to this forum to make an "enhancement request", after they BROKE existing functionality with no workaround.


      And so here's the "enhancement request" which I am absolutely certain will be completely ignored.

      Guess it's time for me to dig into the DB and see if I can find a way of brute-force changing the attachment filename on my own.

        • 1. Re: Feature Request: abililty to change attachment file name
          LJ LongWing


          first off, good article.....unfortunately, this is posted as a 'question', not an idea/enhancement request....you should go create it as an idea...I'll definitely vote for it once created.


          Second....it's easy enough to change at the DB level, which is where I would go to manage it...or via a filter api...plugin for example....:)

          • 2. Re: Feature Request: abililty to change attachment file name
            Andrew Hicox

            Thx LJ.

            Unfortunately there appears to be no option to change the categorization of this post ... ugh!

            one of those days I suppose.


            So being that this is stuck as a question ..

            "how does one change the filename attribute of an existing attachment at the DB level?"


            I suspect I could figure this out by digging around on my own, but from your comment above, I suspect you already know the answer and could save me (and others) some time.





            • 3. Re: Feature Request: abililty to change attachment file name
              Mohammad Rehman

              As LJ LongWing mentioned. you can change on DB Level.

              Here is an example I just tested.

              I have attached the Outage.tiff with second attachment field on helpdesk.

              It shows in DB when query.


              Run the SQL to update the name of the file. 2352 is the schemaid of the WorkLog form which has attachment fields.

              1000000352 field id of the attachment field file loaded.

              UPDATE B2352

              SET C1000000352 = 'Unavailability.tiff'

              WHERE C1='WLG000000462084'


              After commit and query again.

              • 4. Re: Re: Feature Request: abililty to change attachment file name
                Andrew Hicox

                Hmm ... attachments do not appear like that in our DB. We are using Oracle for what it's worth.

                For instance, I have a test form with an attachment on it (schemaid 3023)

                The attachment pool is field id: 536870917

                The attachment is field id: 536870918


                These two fields don't even appear in the T-table for this schema!

                SQL> desc aradmin.T3023

                Name                       Null?    Type

                ------------------------- --------  --------

                C1                        NOT NULL  VARCHAR2(15)

                C2                                  VARCHAR2(254)

                C3                        NOT NULL  NUMBER(15)

                C4                                  VARCHAR2(254)

                C5                        NOT NULL  VARCHAR2(254)

                C6                        NOT NULL  NUMBER(15)

                C7                        NOT NULL  NUMBER(15)

                C8                        NOT NULL  VARCHAR2(254)

                C536870913                          NUMBER(15)

                C536870914                          VARCHAR2(255)

                C536870916                          NUMBER(15)



                I can only presume they're being stored somewhere else in the DB.

                anyone have some hints

                • 5. Re: Re: Feature Request: abililty to change attachment file name
                  Mark Walters

                  They are indeed stored in separate tables - you can read about the structure in the docs here;





                  • 6. Re: Re: Feature Request: abililty to change attachment file name
                    LJ LongWing


                    As I'm sure the docs that Mark pointed out state, there are T, H, and B tables for each 'schema'.  If, as in your case, the schemaID is 3023, then looking in your DB you should find T3023, H3023, and B3023, then in the case of your attachment field, you will also find a B3023C536870918 table which contains the actual attachment...but, back to B3023.  This table will have 4 columns


                    C1 - The same 'id' that is the ID in your T record

                    C536870918 - This is going to be your file name

                    CO536870918 - This is the size (in bytes I believe) of the original file attached

                    CC536870918 - This is the compressed size of the file


                    So, with basic DB updates, you have the ability to modify C536870918 to be what you need without problems.


                    Additionally...I see the point of your need, so I'm considering writing a plugin that allows the getting and setting of the attachment through normal Remedy workflow, so you can do what you need without going to the DB to get it done....but not sure exactly when I'll have time to get this done

                    • 7. Re: Re: Feature Request: abililty to change attachment file name
                      Andrew Hicox

                      Much thanks guys!


                      didn't think to look in the H and B tables, but I haven't really had the opportunity to dig in and spend a lot of time on this either. I'd have eventually gotten there, but you guys saved me some time so thank you!


                      LJ, thanks for the offer to write a plugin, truthfully I could do the same, but I'm of the opinion that this is BMC's problem to fix. Especially, given the outrageous price of licenses and our support contract. As it is, this is hardly a charity. I don't mind releasing open/free remedy software that'll be useful to my fellow developers but fixing out and out bugs for BMC ... because their own support crew actually sent me to their forum for answers? No sir!


                      Now if BMC wanted to give us some sort of financial incentive for fixing their bugs ... that's a different story.

                      • 8. Re: Feature Request: abililty to change attachment file name
                        Mohammad Rehman


                        Best of Luck with BMC to accept it as defect. Product proven defect they don't accept it as defect, they will ask to submit RFE and in their review will shot it down. Over the period of time QA team become lazy and release the product without testing it well on each supported environment.

                        I salute the fellow developers and their contribution to community which saved me many likes me tones of times.

                        This forum is awesome and contributors are absolutely fine fellows and I am proud of them having such a genius gurus.




                        • 9. Re: Re: Feature Request: abililty to change attachment file name
                          LJ LongWing


                          BMC Sending you to the Communities was not a 'cop out'....Communities 'Ideas' are the new crowd sourced 'RFE' process....you didn't create an idea requesting an enhancement...you created a question asking for answers....


                          So, if you want to do what BMC told you to do, create an idea, and let people vote on the validity of the 'enhancement'.


                          Beyond that....I'm a developer that enjoys a challenge, and enjoys providing 'extension' to the Remedy product where BMC falls short....if BMC eventually includes this feature in a future release, then the plugin I would write wouldn't be needed anymore (on versions that support it, but still needed on ones that don't)....and I think that's great that you could create a plugin...what I have found in the past (and used to be one of them), not everyone is skilled in actual programming, and sometimes the thought of developing a plugin or something similar is way over their head and puts the solution out of their grasp....so...that's why I offered


                          I tend to personally think of this as an enhancement instead of a bug.  I look at a bug as something that is supposed to work one way, but doesn't....BMC has never provided the ability to 'set' the name an attachment, and the fact that your Web Service 'source' is providing a name that is not 'valid' is not really BMC's fault...it's a defect in THEIR code that's sending an invalid value...so I look at this as an enhancement to the BMC Remedy Server that allows you to control something that has never been controllable before....


                          Maybe Doug Mueller would have something insightful to say on the topic?

                          • 10. Re: Re: Feature Request: abililty to change attachment file name
                            Andrew Hicox

                            well I'd disagree with you on the idea that sending me to this forum was not a cop-out.


                            I didn't just call up some random dude and be like "why doesn't this work". I called BMC Support. Support that my employer is paying a hefty price for access to. Support at the very least should have said "well you know what, you could address the issue in the database by looking in the B-table associated with the schemaid, and in the mean time we'll file an RFE for you because you've found a valid gap in our functionality".


                            Instead I got a week-plus of trying to explain what I was talking about to support, and them not understanding. When I'd finally had enough and said "please just escalate this to someone who will at least bother to understand what we're talking about", I got "yeah I dunno, why don't you ask for an enhancement on the forum".


                            That is much worse than a cop out. It's damn near fraudulent, given how much a support contract costs.

                            Now I get that there's a new RFE process and I was a donkey and I didn't create this post with the correct categorization. That is my fault. I've not really ever used this forum before now, mostly I've stuck to the ars list or figuring things out on my own.


                            I too enjoy a programming challenge, and I'm no stranger to the API nor to writing plugins, and maybe I'm being a bit cranky because this is about the eleven-billion'th bug I've run into in the last few years where the answer from BMC has pretty much been "well you're on your own muchacho, because there's not enough money on Earth to make us give a hoot".


                            And maybe because of that, I chose an arbitrary place to draw a line in the sand. All things considered, this is a rather mild bug, especially compared to some of the hum-dingers I've been dealing with.


                            Yes. I would love to hear what Doug has to say on a topic like this.

                            I love Remedy. At this point I've spent nearly 20 years of my life specializing in writing programs against it and otherwise dorking around with it. I fondly remember a time when it was so solid ... I didn't even need a support contract except to scrub a license for new hardware. Give me solid releases and I won't care about how bad the support is. Either that or give me good support, y'know?

                            • 11. Re: Re: Feature Request: abililty to change attachment file name
                              LJ LongWing

                              I completely agree that support should be good, I can neither confirm nor deny any claims of support being bad as I haven't dealt directly with BMC on a support issue in MANY years, but I have heard plenty of anecdotal evidence on both sides of the discussion.  I don't think support should be pointing you here to 'get answers'...but certainly here to create the RFE...BMC Support should certainly have been able to provide you the same information that we provided...

                              • 12. Re: Re: Feature Request: abililty to change attachment file name
                                Doug Mueller

                                This is a several part topic:


                                1) To solve your problem, the answer is to take advantage of the direct SQL hook that the product provides as has been mentioned.  This will allow you to resolve your current situation using workflow and move on.  One option is to create an escalation with a bogus qualifier (say 1=0) and just have an ELSE branch that runs an SQL command that does a search on the "b" table in question (or all "b" tables if all attachments are in question) that has a where clause looking for the name column ending in space or return and if found uses a SQL substring or equivalent to set the filename to one character shorter.  I would look for a space, a tab, a carriage return, and a line feed and if any of these are present, to trim the name by 1.


                                It does allow you to move forward.


                                2) The change in functionality.  I am not sure what was being done before.  But, the challenge in this case is that the name of the file is the name that you have specified.  The system automatically trimming characters off the name is not right.  If the character was put there, it must be significant.  Now, some interface can define itself to say spaces are trimmed as that is the behavior of that client -- ON THE WAY IN.  On the way out, we have to deal with whatever data is there.  I am sure that the change was to come in line with the above and was likely in reaction to other customers pointing out the behavior of interpreting the data rather than returning it.  For better or worse, this was a case where the bug was in the previous version and the behavior just happened to be beneficial to you and you took advantage of a bug.


                                Use answer #1 to clean existing data and all new data arriving.


                                3) Support not being able to assist you with this situation.  This is unfortunate and is not the goal of the support team at BMC.  We may choose to not change things, but we should have been there to assist you with information about why the change and about how you could get around it (see #1 above).


                                4) The one thing that is right is the idea that you get directed to somewhere (communities) to enter enhancement requests.  I do see a reasonable enhancement request here.  Have a mechanism so that I can change the filename of an attachment through workflow.  Whether that is something like if I assign a character string to an attachment, it will be a rename of the filename (this matches that if I assign an attachment to a character string I get the filename -- and file sizes on the server as well).  This is an enhancment request and should use the ideas process for requesting new functionality.  I think it is a reasonable request myself.


                                So, I apologize for the customer support experience you had.  We always strive for good experience and at times have fallen down.  The goal is excellent experience at every turn.  Good progress has been made in this area and will continue.


                                I hope there is some value in the information about what has likely caused the change and why.


                                And, I hope there are some solid ideas about how you can clean existing filenames rather than relying on a behavior of the system to just blindly change data you are supplying.

                                • 13. Re: Feature Request: abililty to change attachment file name
                                  Andrew Hicox

                                  Doug, it is so very cool of you to wade into this thread. Thank you for that.


                                  I know I was coming off a bit disgruntled, and I was (I think for good reason), however after a solid night of sleep, I do see that at a technical level, I've sort of made a mountain out of a molehill. T'was the proverbial straw that broke my camel's back I suppose.


                                  Certainly it's easy enough to dig into the DB and change the filename there, and I will circle 'round and file a proper "idea" on the forum (with less ranting and griping, LOL).


                                  There is one interesting point you brought up that I'd like to respond to, and that is the idea that the change in functionality "broke" something that wasn't really "fixed" in the first place.

                                  We had no idea we were even getting attachments with fouled filenames because the mid-tier was essentially hiding this from us, and when it stopped doing that (well, to be completely accurate: stopped doing it one way and did it a different way), we interpreted it as a bug, when in fact it was a bug fix.

                                  The thing is, there's no way for us to control what comes back on an external webservice call, because we don't own it. Anything you get on a webservice call has to be considered "dirty", and there's not really any way to massage data from a webservice call in workflow before it's set as a field value.

                                  Perhaps this is another RFE, actually. But ... this wouldn't have been a problem if I could do something like insert a function call on the XML output mapping (so I could use TRIM, REPLACE, yadda yadda when mapping an XML element into a field on the form). This would allow us to massage data returned from an external source. I think that would be very useful beyond just problems like this.


                                  Anyhow, guess I'll file an Idea for that too.

                                  Thanks again for your time.

                                  • 14. Re: Feature Request: abililty to change attachment file name
                                    Doug Mueller

                                    If you are calling a web service, it sets values back in fields, and then you can use any workflow you want to analyze or modify or whatever you want to the values.


                                    Now we are back to the need for a feature to be able to play with the filename....


                                    You can actually test the filename for the characters, you just cannot change it (so we are 1/2 way there).  If the change ability was there, you would have the logic you need that is independent of HOW it got there -- from a web service or otherwise.



                                    On the front of you never knew it because the behavior hid it from you, all I can say to that is this is an example of an unfortunate situation where "fixing" a bug can have unintended consequences where someone was actually indirectly benefitting from the behavior with the bug.  This has happened on several occasions through the life of the product.


                                    I hope in this situation, there is at least a solution that can be put in place to get you moving forward and then we will have an idea request for giving you the ability to change the filename through workflow.

                                    We always appreciate you calling out where there are issues that can be improved so that they can actually be looked at for being improved (vs. us just not knowing about it).

                                    1 2 Previous Next