How to change the label, in line item in Quote in sugarCRM?
and how to remove some of the fields?
just like from:
Quantity Quoted Line Item Mft Num Tax Class Cost List Unit Price Total Discount
to
Quantity Item Name Mft Num Cost Unit Price Total
Note: Based on the label names specified by you, it appears that you're using Sugar 7.9 or newer. Therefore this answer is written with that version in mind.
Changing Labels
Labels can be changed in Administration -> Studio -> Products -> Labels.
Make sure the selection on the top right is set to "All Labels".
You probably also have to change the Labels in Administration -> Studio -> Quotes -> Labels
If that should also fail and Quick Repair & Rebuild doesn't help, you could try a bit more invasive way:
Replace the label-IDs (LBL_...) of your choice in the custom file mentioned in the next step with the text you want to be displayed. However, such text would then be displayed for all languages.
Removing Fields
If you want to remove fields you probably have to do it via code. Do this by copying
modules/Products/clients/base/views/quote-data-group-list/quote-data-group-list.php to custom/modules/Products/clients/base/views/quote-data-group-list/quote-data-group-list.php (you'll probably have to create the folders first)
Then remove the fields that you don't want to see in custom/modules/Products/clients/base/views/quote-data-group-list/quote-data-group-list.php
After your changes make sure to check the syntax of the file with php -l custom/modules/Products/clients/base/views/quote-data-group-list/quote-data-group-list.php, so that you don't brick your Sugar by accident.
Start a Quick Repair & Rebuild in Administration -> Repair to load your changes.
If something went horribly wrong and Sugar won't load after, just delete the custom quote-data-group-list.php and the contents of the cache/ folder and Sugar should load again.
Related
I just upgraded to ReSharper 8.1.23.546 and it added a new key to our team settings file:
<s:Boolean x:Key="/Default/Environment/SettingsMigration/IsMigratorApplied/=JetBrains_002EReSharper_002EPsi_002ECSharp_002ECodeStyle_002ESettingsUpgrade_002EMigrateBlankLinesAroundFieldToBlankLinesAroundProperty/#EntryIndexedValue">True</s:Boolean>
What is this, and why did it add it to the team settings file? Will it cause issues with other developers when this is stored in version control and they haven't upgraded to this version yet?
This is an indicator that ReSharper has migrated some settings that have changed from one version to the next, and is used to not run the migration again.
In this case, ReSharper 8.0 introduced some new formatting options - number of blank lines around property/auto-property, and number of blank lines around single-line property/auto-property. I don't know for sure, but looking at things, it's reasonable to assume that ReSharper 7 used the number of lines around a field when formatting properties.
If you've got a fresh install, introducing these new options is no big deal - everything will be default, and nothing will get written to the settings file. But, if you've previously customised the number of blank lines around a field, then introducing these new options will change the existing behaviour, because the formatter would use the new default options, rather than the old, customised value. So, the migrator runs and checks to see if the number of lines around a field is anything other than the default. If it is, it checks to see if you've already edited the number of lines around properties. As long as they're still set to the default, it overwrites the (default) value to be the same as the number of lines around a field - it migrates the previously used field values to overwrite the default values for properties. It then adds the migration indicator to make sure the migrator doesn't run again, else you'd never be able to have default formatting for properties and non-default formatting for fields.
As for why it's in the team settings, I presume that's because the customised field value is also in the team settings file. Since this file is shared, it makes sense to only migrate the values once, so the indicator should also be in the shared file. There will be no danger in sharing this with the team.
I'm probably biting off more than I can chew with this particular problem, but I'll try to be as specific as possible in case it's within my scope. Disclaimer: I'm not terribly experienced with MS Word, beyond simple data entry/some formatting, and I have absolutely zero experience working with macros or VBasic. Unfortunately, I'm afraid the solution to my problem will come in the form of one of those last two.
THE GOAL:
What I want to do is to have placeholder text throughout my template document that will change content but not formatting when the first instance of it is changed. Basically, I'm writing a template for support manuals for a software suite. Each app has certain similar features like the menu bar, data entry screen, diagnostic log screen, transaction history, etc., so I am pre-writing those sections and using placeholders when I need to insert certain app specific properties.
I started off using the Insert->Quick Parts->Document Property->Subject tool which I used as a placeholder for the app name. I set the Property to [Subject] and then used Insert->Quick Parts->Field->Subject throughout the document, wherever I needed to include the app name. This worked fine in this case because the app name will always be capitalized. I simply change the text in the first [Subject] (which is content controlled) and update the fields throughout the document, and they all match nicely, easy-peasy, work done, go home and drink beer, right?
Not quite.
Our software handles part tracking via scanners and SQL Server, so while the interface and menu in the apps remains largely unchanged, the parts they track change from app to app. Because of this, I need to change the part name when I reference it within the text of the manuals; for example, if I'm working in ToiletPap.app and our TP is tracked by the roll, I need every mention of [Component] to be changed to roll. If I'm working in LightBulbs.app, I need [Component] to say bulb.
My first efforts went toward creating a custom doc property called Component using the Advanced tab under the Document Properties dropmenu. I then created a plaintext content control around my first [Component] titled Component and made my next [Component] a field with modified code: {COMPONENT * MERGEFORMAT}. This comes from copying what I can find when [Subject] works. This didn't work at all; updating the text in the first CC doesn't change the Content doc prop, and my fields return "!Undefined Bookmark, COMPONENT".
I got close to what I need by using the [Comments] doc property, set initially to [Component]. I used it just like [Subject], but (this is when I realized that capitalization was going to be an issue) when I mention my [component] in-text, as often as not, I need to to be lowercase instead of upper.
I've looked on MS's forums and a few others as well as here on SO, and I can't find anyone who's trying to do the same thing, much less an answer to how. Please keep in mind when answering, it would be a great help to me if you would include step-by-step instructions on how to enter/implement the code you provide because, as I mentioned, I have no idea how to go about editing macros/VBasic for MS Word.
To restate and summarize my overall question: How can I use a placeholder that displays the text "[Component]" so that, when I change the first instance of [Component] to something else, say "hopper", every subsequent instance of [Component] is updated to hopper but maintains its current capitalization and formatting scheme?
Apologies for the length of the request, but I wanted to make sure I explained the situation as accurately as possible. Thanks in advance for your consideration and responses.
I managed to solve this one after a couple extra hours of tinkering. I didn't need macros or VBasic, either.
On the first instance of [component] I created a plain-text content control to act as a container (not a necessity, but it makes it look nicer. Will likely cause a problem eventually, but for now, it's working as intended) and bookmarked it. Then, for all other instances of [container] I selected each and used Insert->Quick Parts->Field->Ref with the following field code:
REF Text1 \*Lower
Where "Text1" is my bookmark and "*Lower" indicates all lower case. The *Lower can be replaced with *Upper or *FirstCap to indicate all upper case or capitalize the first letter respectively. Now, each field reflects the text of the first with the capitalization appropriate to each field's location within the document. Just like using the doc prop with [Subject], ^a -> f9 is needed to update all fields within the document.
If I open the extension manager, switch to the tab Import Extensions and select the filter I get the following options:
Display all extensions (empty)
Only display installed extensions (working)
There should also be a Only display updatable extensions selection but this isn't displayed. What is the reason therefore?
I made a TYPO3 update to 4.7.2 and perhaps thats the reason why it isn't correctly displayed?
The repository is up to date.
The filter has been moved from the Import Extensions to the Available Extensions tab.
You do not actually want to import an extension, but update an existing one.
Just suggestion: I had similar issues with button displaying in EM before (4.6.x) (ie. Install ext button) and realised, that the button is available, but sprite image had wrong position which caused that the button was transparent,
Try to use ie FireBug to check it, and eventually fix the CSS (and report the bug)
Edit:
Some doom apparently, I just had identical situation just seconds ago ;) Fortunately found the reason: the ext list is displayed with ExtJS grid, which can contain custom filtering per column. Literally: when you for an example click on the column's dropdown arrow, you can in its filter set some value to narrow the search results.
Ie.: in the main filter field write news and additionally in the Extension Key column set other filter tt_news. (if you want to display only %tt_news% in result list of %news%)
In that case even if you'll clear the main filter, the one set on the column will stay active, so next time when you'll try to search for realurl in main filter, it will return empty list as Extension Key filter is still set to tt_news.
Weeeird, however helped me :)
You can recognize filtered columns as their names are written with cursive, finally you can just check every column and disable any filtering on each.
We're trying to implement a mobile version of our Typo3 site, but whenever I add a new Template Object and select something in "Make this a sub-template of", I get this error:
I'm not very good with typo3, so if anyone could point me in the right direction it would be great. Thanks.
Go to Install Tool > Database Analyser > COMPARE and mark the checkboxes to add missing fields and tables (you don't need to remove suggested things)
Repeat the operation as long as required, if some field can not be added by COMPARE, you need to include it manually via phpMyAdmin. Most probably in such case you'll need to resolve some conflict.
Next go to Extension Manager, find the TemplaVoila ext and search for Update button, to make sure that the config is saved correctly to the file.
If i make a label in TFS, and later make a new label with the same name... then the old label is replaced by the new one.
How do I prevent TFS from overwriting a label?
The following MSDN article covers using the Scope of a label to try and minimize the occurrences of these mishaps:
Using the /Child Option to Avoid Labeling Mishaps
If you issue a label command together with a pre-existing label name and an itemspec that includes files that are already marked by the same label, the value of the /child option determines whether the marked files are updated with new revision information. That is, the files are labeled by the same name, but have different scope.
Thanks, that led me on the right track.
It seems that the label overwrite is a "feature" and not a bug. It's working as designed
sixletter's link above explains it, and below are two more with info about it.
http://msdn.microsoft.com/en-us/library/ms181439(VS.80).aspx
http://msdn.microsoft.com/en-us/library/ms181440(VS.80).aspx
Apparently TFS labels are not a snaphot of a point in time like in other VCS's , though i do not fully understand the explanation.