Hi Jignesh, I see, but I think is extremely easy to remove the "DyamicField_" prefix using a simple Regular Expression (for substitution), you can use it everywhere in your code even if the prefix is not there.
On the other hand, we have this prefix is some parts of the code in several files, because a Dynamic Field can be named as Priority, StateID, Owner, ResponsibleID, TicketNumber, etc. if you call TicketGet from the TicketObject and you don't have the "DynamicField_" Prefix in the Dynamic Fields it will be totally a mess. and it will be worst, if you for example update the ticket based on the results of a TicketGet (without the prefixes). So IMHO I don't see many complications in having the prefix, but a lot of problems if we don't. Please think about it. ((enjoy)) Carlos Rodríguez On Mar 20, 2013, at 9:21 AM, "Jignesh Kakka (jkakka)" <jka...@cisco.com> wrote: > Hi Michiel, > > Let’s say we add a dynamic field called ticket_source in OTRS. > Now while creating the ticket , there is no problem. > But while getting the ticket, I have to modify my application source code to > get/read this new Dynamic field from the response. > Had it been name-value pair, it would have got populated in my map > automatically. > > Thanks, > Jignesh > > From: dev-boun...@otrs.org [mailto:dev-boun...@otrs.org] On Behalf Of Michiel > Beijen > Sent: Wednesday, March 20, 2013 4:05 PM > To: Development community of OTRS > Subject: Re: [dev] Issues with Dynamic Fields > > Hi, > > On Wed, Mar 20, 2013 at 5:33 AM, Jignesh Kakka (jkakka) <jka...@cisco.com> > wrote: > While creating ticket, we pass Dynamic fields as name-value pair. But while > getting ticket we receive dynamicFields as DynamicField_FieldName. > Cant this behavior be changed to having Name Value pair even while getting > the ticket. > The reason wh I want in this way is , let’s say if we add or remove a dynamic > field from System, then it may not require code change if we maintain as > name-value pair > I was assuming that this may happen in OTRS 3.2 . But it also applies same > logic while getting tickets > > Can you explain the use case you have for this? What code would you now write > that can be different if OTRS behaviour would change? > > -- > Mike > > _______________________________________________ > OTRS mailing list: dev - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/dev > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev