Changing labels in import dropdown

[aschaeffer]

Hello!

In Sugar OS 4.5.0f (and previous versions as well), when you want to import data in account or person for instance, you select the .csv (or other format) and then you need to assign the labels to the fields in your CRM. The issue I have is that the dropdown displays the field labels and not the field name. It happens that in some modules I have 4 times the same label. So I lose a good hour finding out which label corresponds to the fileds I need.
The question is: can I change the dropdown so it shows the field names, not the labels? or is there a file where to edit the labels shown in the dropdown without changing the labels in the interface?

Many thanks for your help!

Alan

[chrisky]

Alan,

This is about the moment where ya go "Oh, boy..." in frustration with Sugar...

You can not try to configure some setting(s) or modify things solely in order to get the proper corresponding labels to show in those dropdowns representing your custom fields.. The problem is actually an underlying core bug with Sugar's custom fields feature and ability. As a result of this bug [which ultimately results in the custom fields being broken] everyone complains about and blaims the manifestation of this bug and the location of where this manifestation makes itself apparent..

Which is most commonly in Studio.. While importing data to custom fields is much less common in comparison to Studio use, this is why you haven't found much mention if this particular manifestation has been mentioned previously by other forum members.

It's been what seems like at least a few months since I've even had to address or think about that stuff {generally referring to what I believe is the issue}.

Lemme guess!

The problem is with CUSTOM fields?
Those same fields do not work or have problems in Studio as well?
etc. etc.

So what I'm getting at is that you're looking for both the problem cause and possible solution or modification, in the wrong area..

I've shared a little handful of technical data and details centered on this whole topc & theme.
If you're real interested in making sugar your CRM solution, I'd suggest you read all those prior posts & pictures.

Ultimately, we chose to implement a policy in which custom fields are not to be used.
Originally, we developed a few smooth little trickts for taking those already created custom fields and converting them to regular fiellds in the module.

We had hundreds of custom fields per module back then (now we're upto tousands of fields), and manually mod'ing sugar core code in order to add such custom fields as regular module fields would have required too much labor and was out of the question.

If you've only got a couple/small handful of custom fields, gives you more flexibility in methods.

For the most part, I began to require that custom modules be developed and that is how we do it now..
It is just so much easier this way, plus makes it so much easier for integration across countless deployments and versions.

The only people that I am confident or aware of knowing Sugar inside and out in regards to all of this, are the Sugarteam themselves and Ken Brill.. I'm pretty sure that Ken is the best in the world [outside of the Sugarteam] and would be the man to hire [for those wanting this type of support]. I can say that all of Kens material helped us in the past and saved us alot of time figuring it out on our own, thus I'd highly reccomend you study it with a fine tooth comb as well..

I do have a couple ways to address this and eliminate custom fields from the picture; however, I'm not eager to spend the hours [and possibly days] trying to type up such; however, we can go over it via the phone sometime if you'd like.

Bottom line, my point is "don't use custom fields'..

[aschaeffer]

Hi Chrisky,
Confusing answer of yours... I don't have so many troubles with my custom fields (I've got about 200). And I can't imagine that there is not a way to change the display from showing labels to showing DB names.

Now I'm looking into how to calculate with dates: I want to do End of contract (date) - Start of contract (date) = contract duration in months.
In excel that's an easy one but with php...

btw my skype is alansurfer.

Cu!
Alan

[chrisky]

Ahh...

I'm the lost one..

So you are seeing the dropdowns the way they were designed, with their labels, but instead you want to see the db names...
That kinda doesn't make sense, but if that's what ya want..

There is a few spots this data is stored...

In the sql db inside the fields meta data table;
in the javascript ?language file, anyways it's in one of the cached js files;
and in the vardefs file..

You'd be better off reading my 'RapidPHP' thread/post(s).
As if you were to recursively search the files inside your sugar deployment [for the exact field label string you see displayed as the field label], you'd find both spots where that data is stored and can be edited.. Though please note, it is also stored for 'backup' purposes in the sql db, and some Sugar admin 'repair' functions will wipe (delete/overwrite) your modifications..

My point being, you must understand where everything is stored/located and it's corresponding purpose, otherwise you'll spend alot of time spinning your wheels and scratching your head, going wtf, it was working for the past day, or month, before discovering your changes have dissappeared.. lol

I just searched for it, here is that post of mine, and a pretty detailed one at it, of which is what you desire...

And I must be tired, because I just realized, your asking about dropdowns not custom fiels which is what I had in my mind..
The dropdowns are stored somewhere else, and I can't remember where, without spending 2 or 3 mins digging up notes on that, I'm ready to pass out and am heading out now, though tommorrow I'll can tell ya where, I'd rather you learn how to search in the manner I suggest! It's very beneficial to you, to say the least...

I'll try to figure out when this week, I have the hour or two to chat so we can talk..

[good]Night, in the meantime..

[chrisky]

Sorry, tired, forgot to post that link:
http://www.sugarcrm.com/forums/showt...light=rapidphp

[aschaeffer]

It makes sense for me 'cause I have in the same module:
Product A: field "Sum" ; "Date started"
Product B: field "Sum" ; "Date started"

So when I want to do an import I have twice "Sum" and "Date started". In this module I have about 5 fields that have 4 times the same names...
So u can imagine the mess.

Ok I'll check that out now!
Take care,
Alan

[chrisky]

I know and understand exactly what you've done and your situation..

Let me sugget that you'd be better off changing the field labels to a more descriptive label that makes sense to you and/or your users, opposed to displaying the db field name in place of a relational label...

Trust me.. I'm right.. lol

Stick with using labels and change the labels to your hears content; however, let me expand on this topic...

You should ALSO try to have your db fields name be the same as your [planned] labels with capitalization and punctuation exlcluded...

I [still] had open on [my notebook] a file from early this morning, related to something I was working on, of which should help to examplify this concept, thus I took 20 seconds to save that file to a network server in order to access it from my X console.

Take note that these field names (the few I paste below), are actual SQL db field names, and these are {for the most part] identical to the acutal field labels utilized with punctuation, capitalizationk, and spaces excluded..

"spousesfullname","landusecode","propertyapntaxid" ,"landassessedvalue","yearassessed",
"annualtaxes","improvementsassessedvalue","totalas sessedvalue","lotacreage","lotsquarefootage",
"buildingsquarefootage","bedrooms","numberofbathro oms","garagetype",

Take my advice! It is alot easier to maintain, manage, develope, and work with things when the db field names are very descriptiive, i.e. just as much if not equal to that of a field label..

Especially, when **it breaks... And for all of those out there using 'custom fields', well.... There's some bug(s) hidden in their, of which most complain about and blaim upon Studio..
My style of naming fields save time and make things easier for debugging and developing, though I'm not the only one who trys to do such, I hope to think that 99% of developers... That is a 'zillion' do the same..

So, lol, I'm telling you that you're barking up the wrong tree...
You don't want to 'display' the field names as the label!
Without wanting me to explain such, stick with labels..

If you would like help on how to change the labels (and you WANT TO do this manually! trust me! though Studio or whatever other wysiwyg or gui interface of which may let you change such might exist, forget them, and especially DO NOT become dependant upon them... If you do, you'll end up joining the ranks of the 'many/majority' of whom post to the forum complaining about being dead in teh water with stuff broken and subsequently never recieving [on a silver platter] a solution to their troubles..

I won't tell ya where these labels are stored..
Instead, I want you to read that rapidphp post of mine...
Ultimately I want you to learn how to do this stuff on your own, and since it takes NO programming skill or knowledge, but only perform particuluar steps [using the computer and/or certain programs], it'll be easy as pie for ya..

I have NO clue what or how to accomplish the same under MacOS, otherwise I was going to mention that if rapidphp doesn't apply to you for Operating System related reasons, that I'd give you the same/neccessary infor and programs pertaining to your particular operating system; however, such excludes the Macs and we'll keep it that simple..

{foregoing explanation right now, as I'm about ready to pass out, 11:10pm, a long day, and a migraine at the moment among other things...}
If you want/need to create and/or display some additional/custom/special labels in excess to what you currently have, well... I have a hunch we'll be going here, and I can tell ya how to do that later (tommorrow or whenever you desire).

[aschaeffer]

Thanks for this long reply

Your definetly right but I did everything wrong from the start I guess because I wrote the DB names in english and the labels in german. I should have written the Labels in english and in german in the labguage file.
Is it gonna mess up if I change the labels in the DB? It's gonna take a while if I do that...
Btw I read the rapidphp post of yours. Quite interesting
I'm using PSPad that does the same so far as I can see. And I'm using Windows, not Mac.

What did u mean with that?

If you want/need to create and/or display some additional/custom/special labels in excess to what you currently have

cu!
Alan