SugarCRM - Custom Print Layout - sugarcrm

I created a model in SugarCRM and I need to print the details view. But this must be printed with a different layout.
It must have the company logo for example, if I just wanted do print the bean information, the default print would be sufficient, but I need something closer to a report, because this info will be given to the costumer.
I would like to know if there is a way to create a printing template, and if there is, how can I create one?
Thanks for your help, if you need more information please comment.
rfnpinto

Even in SugarCRM CE you can leverage the included Sugarpdf class, which is an extension of TCPDF.
If you have SugarCRM Professional you can find examples of this in the Quotes module. If not, you're flying blind, so I can give you the gist of it.
Using the Contacts module as an example, create /custom/modules/Contacts/views/view.sugarpdf.php with contents like the following:
<?php
require_once('include/MVC/View/views/view.sugarpdf.php');
/**
* this defines the view that will drive which PDF Template we use
*/
class CustomContactsViewSugarpdf extends ViewSugarpdf{
public function display(){
$this->sugarpdfBean->process();
$this->sugarpdfBean->Output($this->sugarpdfBean->fileName,'D');
sugar_die('');
}
}
Create /custom/modules/Contacts/sugarpdf/sugarpdf.pdfout.php with contents like the following:
$contact = BeanFactory::getBean($_REQUEST['record_id']);
if(empty($contact->id)){
sugar_die('Could not load contact record');
}
$name_str = "<p><strong>Name: {$contact->name}</strong></p>";
$this->writeHTML($name_str);
$this->drawLine();
}
function buildFileName(){
$this->fileName = 'ContactPDFOut.pdf';
}
}
From there, you can print a PDF document per your format if you hit the URI index.php?module=Contacts&action=sugarpdf&sugarpdf=pdfout&record_id=1234
Once that's working in the way you want, you can add a button the Contacts Detailview to access that URI more easily. Dig into /custom/modules/Contacts/metadata/detailviewdefs.php and find the existing buttons array. It'll look something like this:
'buttons'=>array('EDIT', 'DUPLICATE', 'DELETE', 'FIND_DUPLICATES'
Just enhance this with your own button and hidden input
'buttons'=>array('EDIT', 'DUPLICATE', 'DELETE', 'FIND_DUPLICATES',array(
'sugar_html'=>array(
'type' => 'submit',
'value' => '(Wrongfully Hardcoded Label) Print PDf',
'htmlOptions'=>array(onclick => 'this.form.action.value=\'sugarpdf\';this.form.sugarpdf.value=\'pdfout\'')
)
)
...
The hidden array should be part of $viewdefs['Meetings']['DetailView']['templateMeta']['form'] and defined like so:
'hidden' => array('<input type="hidden" name="sugarpdf">'),
I haven't tested this recently but this is the general idea of adding custom Print PDF abilities to any particular screen within SugarCRM. TCPDF options are pretty extensive and forming the template just right is going to be very tedious, but I think once the "plumbing" is working here you'll figure that bit out, but feel free to ask followup questions.

Related

TYPO3 field helpers / hints / tips

since I'm pretty new to TYPO3 I'd like to know is there a possibility of adding simple text hints / tips below any type of field, something like this, for Nickname input field:
Thank you in advance!
Out of the box, not yet.
We are discussing a generic way to do so as we speak, but right now you'd need to create your own renderType for FormEngine.
Given the amount of PHP knowledge you have this is easy to intermediate.
Here are the steps:
Step 1: add your own formEngine Type class in ext_localconf.php
$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']['nodeRegistry'][1463078603] = array(
'nodeName' => 'ApparelCalculation',
'priority' => 40,
'class' => \T3G\Apparel\FormEngine\ApparelCalculation::class,
);
The number 1463078603 should be unique, so a good idea is to use the current unix-timestamp for that.
Step 2: Instruct your field to use that renderType
Add a TCA override file in YOUR_EXTENSION/Configuration/TCA/Overrides/tt_content.php (in this case we're overriding tt_content, thus the name. If you want to reconfigure another table in TYPO3, use the filename according to the tablename.
Add something along this:
$GLOBALS['TCA']['tt_content']['columns']['header']['config']['renderType'] = 'ApparelCalculation';
See how the renderType name is identical to what we registered in step 1.
Step 3: Render what you like to render
I'll add the configuration of my special case class here, but I will cover the important things later in this post:
It might be helpful for your case to copy from backend/Classes/Form/Element/InputTextElement.php since that seems to be the element you want to put your tip to.
<?php
namespace T3G\Apparel\FormEngine;
use T3G\Apparel\Calculation\Calculation;
use TYPO3\CMS\Backend\Form\Element\AbstractFormElement;
use TYPO3\CMS\Core\Utility\GeneralUtility;
class ApparelCalculation extends AbstractFormElement
{
/**
* Renders the Apparel Calculation Table
*
* #return array
*/
public function render()
{
$resultArray = $this->initializeResultArray();
$calculator = GeneralUtility::makeInstance(Calculation::class);
$resultTable = $calculator->calculateOrder($this->data['databaseRow']['uid']);
$resultArray['html'] = $resultTable;
return $resultArray;
}
}
I won't focus on things outside the render()method, because that's just plain PHP.
It is important to call $this->initializeResultArray(); first, so TYPO3 can work its magic to gather all the data.
From here on I'd suggest to use xdebug to get a grip of what you have available in that class.
The amount of information is very dense, but you will have everything there you need to build even the craziest stuff.
Now that you know how everything plays together you might think about extending backend/Classes/Form/Element/InputTextElement.php with plain PHP, grab the result of the parent render() call and simply add your tip to it.
Enjoy :)

Zend creating forms based on requests within one controller/action

I don't really know how to word the title well, but here's my issue. I decided instead of having 25 controllers to handle pages, I have one PageController with a viewAction that takes in a :page parameter - for example, http://localhost/website/page/about-us would direct to PageController::viewAction() with a parameter of page = about-us. All of the pages are stored in a templates folder, so the viewrenderer is set to render application\templates\default\about-us.phtml.
I did this so I can consolidate and it seemed like a better approach. My question is the following: lets say when the page request is contact-us, I would need a Zend_Form to be used within the contact page. So, I would need a way within PageController::viewAction() to recognize that the page needs to have a form built, build the form, and also upon submission the need to process it (maybe this should be handled in an abstract process method - not sure).
I have no idea how to implement this. I thought maybe I can store a column with the name of a form and a connecting page identifier. Even better, create a one-to-many page to forms, and then in the submission loop through the forms and check if submitted and if so then process it (maybe there is a isSubmitted() method within zend_form. I really don't know how to handle this, and am looking for any help i can get.
Thanks!
Here is something that came to mind that may work or help point you in a direction that works for you.
This may only work well assuming you were to have no more than one form per page, if you need more than one form on a page, you would have to do something beyond this automatic form handling.
Create a standard location for forms that are attached to pages (e.g. application/forms/page). This is where the automatic forms associated with pages will be kept.
In your viewAction, you could take advantage of the autoloader to see if a form for that page exists. For example:
$page = $this->getParam('page');
$page = ucfirst(preg_replace('/-(\w)/ie', "strtoupper('$1')", $page)); // contact-us -> ContactUs
$class = 'Application_Form_Page_' . $page;
// class_exists will invoke the autoloader to map a class to a file
if (class_exists($class)) {
// a form is defined for this page
$form = new $class();
// check if form was posted
if ($this->getRequest()->isPost()) {
if ($form->isValid($this->getRequest()->getPost()) {
// form is valid - determine how to process it
}
}
// assign the form to the view
$this->view->pageForm = $form;
}
All this really leaves out is the action you take to process a specific form. Since the contact form will likely generate an email, and another form may insert data into a database, you will need some sort of callback system or perhaps another class that can be mapped automatically which contains the form processor code.
Anyway something along those lines is what came to mind first, I hope that helps give you some more ideas.

drupal 7 form validate add class?

In my form I create a checkbox
$form['existing_customer'] = array(
'#type' => 'checkbox',
'#title' => t('Are you an existing customer?')
);
When I validate it using hook_validate I would like to add a class to the label? Any ideas how to achieve this?
I can't imagine why you'd want to do this in a validation function, and I think there's a far easier way to accomplish what you're trying to do.
Each element in a Drupal form is wrapped with a container (which has an ID). Inside this container there will only ever be one label.
So if you need to target the element in CSS or JS you just need to do something like this:
#existing-customer-edit label {
// The rule
}
OR
$('#existing-customer-edit label').something();
If you really need to edit the label manually then you're going to have to provide a custom theme for that element, have a look at this example for more information (it's for Drupal 6 but the concept is the same in Drupal 7).
thanks Clive did a fairly nasty work around in the form validation function
$form_state['complete form']['myselectbox']['#title'] = '<span class="privacy-error">you did not check me</span>';
It ain't pretty but it works!
You can add a class in hook_validate():
$form_state['complete form']['submitted']['existing_customer']['#attributes']['class'][] = 'class_name';

Zend Form Element with Javascript - Decorator, View Helper or View Script?

I want to add some javacsript to a Zend_Form_Element_Text .
At first I thought a decorator would be the best way to do it, but since it is just a script (the markup doesn't change) then maybe a view helper is better? or a view script?
It seems like they are all for the same purpose (regarding a form element).
The javascript I want to add is not an event (e.g. change, click, etc.). I can add it easily with headScript() but I want to make it re-usable , that's why I thought about a decorator/view helper. I'm just not clear about the difference between them.
What is the best practice in this case? advantages?
UPDATE: Seems like the best practice is to use view helpers from view scripts , so decorators would be a better fit?
Thanks.
You could create your own decorator by extending Zend_From_Decorator_Abstract and generate your snippet in it's render() method :
class My_Decorator_FieldInitializer extends Zend_Form_Decorator_Abstract {
public function render($content){
$separator = $this->getSeparator();
$element = $this->getElement();
$output = '<script>'.
//you write your js snippet here, using
//the data you have in $element if you need
.'</script>';
return $content . $separator . $output;
}
}
If you need more details, ask for it in a comment, i'll edit this answer. And I didn't test this code.
Use setAttrib function.
eg:-
$element = new Zend_Form_Element_Text('test');
$element->setAttrib('onclick', 'alert("Test")');
I'm not actually seeing where this needs to be a decorator or a view-helper or a view-script.
If I wanted to attach some client-side behavior to a form element, I'd probably set an attribute with $elt->setAttrib('class', 'someClass') or $elt->setAttrib('id', 'someId'), some hook onto which my script can attach. Then I'd add listeners/handlers to those targeted elements.
For example, for a click handler using jQuery , it would be something like:
(function($){
$(document).ready(function(){
$('.someClass').click(function(e){
// handle the event here
});
});
})(jQuery);
The benefit is that it is unobtrusive, so the markup remains clean. Hopefully, the javascript is an enhancement- not a critical part of the functionality - so it degrades gracefully.
Perhaps you mean that this javascript segment itself needs to be reusable across different element identifiers - someClass, in this example. In this case, you could simply write a view-helper that accepts the CSS class name as the parameter.
"the markup doesn't change", Yap,
but I like to add some javascript function throw ZendForm Element:
$text_f = new Zend_Form_Element_Text("text_id");
$text_f->setAttrib('OnChange', 'someFunction($(this));');
The best way is if you are working with a team, where all of you should use same code standard. For me and my team this is the code above.

Disable translation of Zend_Navigation elements

Is there any easy way to disable translation of some of the Zend Navigation elements?
e.g. in this case
$page = new Zend_Navigation_Page_Mvc(
array(
'label' => $blogPost->alreadyTranslatedTitleFromDb
// ...
)
);
$container->addPage($page);
Now, when I use:
$page->getLabel();
the label is translated twice. The same for breadcrumbs, sitemaps etc.
I wrote a patch with unit tests for this:
http://framework.zend.com/issues/browse/ZF-10948
If you want only some specific elements to be disabled, i think that only way is to use a partial view script and create your own logic for the menu.
You may add custom properties to the pages. Example: add a property doNotTranslate and in your view script check for this property to know if element should be translated or not.
More info about partial view script is available at http://framework.zend.com/manual/en/zend.view.helpers.html#zend.view.helpers.initial.navigation.menu