Error on SugarCRM REST api v4 - sugarcrm

We got error on REST api v4. It blocks us to get data from sugar database. We are using SugarCRM Version 7.6.2.1 (Build 9)
Strict Standards: Declaration of SugarWebServiceImplv3_1::get_entry_list() should be compatible with SugarWebServiceImpl::get_entry_list($session, $module_name, $query, $order_by, $offset, $select_fields, $link_name_to_fields_array, $max_results, $deleted = 0) in /home/testsugarcrm/app/www/service/v3_1/SugarWebServiceImplv3_1.php on line 20
Strict Standards: Declaration of SugarWebServiceUtilv4::get_data_list() should be compatible with SugarWebServiceUtilv3_1::get_data_list($seed, $order_by = '', $where = '', $row_offset = 0, $limit = -1, $max = -1, $show_deleted = 0, $favorites = false, $singleSelect = false) in /home/testsugarcrm/app/www/service/v4/SugarWebServiceUtilv4.php on line 638
Strict Standards: Declaration of SugarWebServiceImplv4::get_entries() should be compatible with SugarWebServiceImplv3_1::get_entries($session, $module_name, $ids, $select_fields, $link_name_to_fields_array, $track_view = false) in /home/testsugarcrm/app/www/service/v4/SugarWebServiceImplv4.php on line 21
Does anyone know how to fix this error?

These are Strict Standards which will need to be disabled at server/PHP end.
Find your php.ini file (root folder) and change the attribute that is called error_reporting:
from:
error_reporting = E_ALL | E_STRICT
to:
error_reporting = E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_DEPRECATED

Related

RubyMotion: Objective-C stub for message `logInWithPermissions:block:' type `v#:##?' not precompiled

I tried to implement a Facebook login via Parse.com iOS SDK.
When I try to use the PFFacebookUtils.loginWithPermissions:block: method, I got the error.
Objective-C stub for message `logInWithPermissions:block:' type `v#:##?' not precompiled. Make sure you properly link with the framework or library that defines this message.
Anyone experienced this?
I use
rubymotion 2.31
Parse-iOS-SDK 1.2.19 (using cocoapods)
This is my Rakefile:
$:.unshift('/Library/RubyMotion/lib')
require 'motion/project/template/ios'
require 'bundler'
Bundler.require
Motion::Project::App.setup do |app|
app.name = 'myapp'
app.identifier = 'com.your_domain_here.myapp'
app.short_version = '0.1.0'
app.version = app.short_version
app.sdk_version = '7.1'
app.deployment_target = '7.0'
app.icons = ["icon#2x.png", "icon-29#2x.png", "icon-40#2x.png", "icon-60#2x.png", "icon-76#2x.png", "icon-512#2x.png"]
app.device_family = [:iphone]
app.interface_orientations = [:portrait]
app.files += Dir.glob(File.join(app.project_dir, 'lib/**/*.rb'))
app.frameworks += [
'Accounts',
'AudioToolbox',
'CFNetwork',
'CoreGraphics',
'CoreLocation',
'MobileCoreServices',
'QuartzCore',
'Security',
'Social',
'StoreKit',
'SystemConfiguration']
app.libs += [
'/usr/lib/libz.dylib',
'/usr/lib/libsqlite3.dylib']
app.pods do
pod 'SVProgressHUD'
pod 'Parse-iOS-SDK'
end
FB_APP_ID = '<my facebookAppId>'
app.info_plist['FacebookAppID'] = FB_APP_ID
app.info_plist['CFBundleURLTypes'] = [{ CFBundleURLSchemes: ["fb#{FB_APP_ID}"] }]
end
Related code:
def login_with_facebook
PFFacebookUtils.logInWithPermissions(['email'],
block: lambda do |user, error|
if !user
puts 'failed!'
elsif user.isNew
puts 'User signed up and logged in through Facebook!'
else
puts 'User logged in through Facebook!'
end
end
)
end
This is a known bug in the way the Parse SDK bridge files are generated:
http://hipbyte.myjetbrains.com/youtrack/issue/RM-119
Workaround here (for me, I had to do the replacement in the vendor/Pods/build-iPhoneSimulator/Pods.bridgesupport file)
https://groups.google.com/forum/#!msg/rubymotion/36WCWPPkPdc/kBCDS-DOSjsJ

How to set arguments for savon version 2

I'm reading railscast #290 that are going with savon version 1.
So I tried to replace command for version 2, but I couldn't do it.
http://railscasts.com/episodes/290-soap-with-savon?view=asciicast
I replaced the commands like these.
ver1 client = Savon::Client.new("http://www.webservicex.net/uszip.asmx?WSDL")
ver2 client = Savon::Client.new(wsdl: "http://www.webservicex.net/uszip.asmx?WSDL")
ver1 client.wsdl.soap_actions
ver2 client.operations
ver1 client.request :web, :get_info_by_zip, body: { "USZIP" => "90210" }
ver2 client.call(:get_info_by_zip) # need more
How can I set namespace web and body parameter USZIP and 90210?
try this (www.webservicex.net is not very reliable though):
#!ruby
require 'savon'
WSDL_URL = 'http://www.webservicex.net/uszip.asmx?wsdl'
client = Savon.client(wsdl: WSDL_URL,
log: true, # set true to switch on logging
log_level: :debug,
pretty_print_xml: true)
zip = ARGV[0] || "10004"
response = client.call(:get_info_by_zip, message: {"USZip"=>zip})
print response

tcpdf date error Message: Undefined offset: 2

i have a date (datepicker jquery) $fecha_constancia:
public function generarReporte(){
$data_b = array();
$container = $this->input->get_post('opc_report', TRUE);
$paciente = $this->input->get_post('paciente', TRUE);
$odontologo = $this->input->get_post('odontologo', TRUE);
$fecha_constancia = $this->input->get_post('fecha_constancia', TRUE);
$diagnostico = $this->input->get_post('diagnostico', TRUE);
$reposo= $this->input->get_post('reposo', TRUE);
$reposo = $reposo*7;
list($day,$mon,$year) = explode('/',$fecha_constancia);
$nueva_fecha = date('d/m/Y',mktime(0,0,0,$mon,$day+$reposo,$year));
$data_a = array(
'fecha_constancia' => $fecha_constancia,
'diagnostico' => $diagnostico,
'fecha_reposo' => $nueva_fecha,
'dias_reposo' => $reposo
but when I'm going to spend the time to the Make pdf throws me the following result:
A PHP Error was encountered
Severity: Notice
Message: Undefined offset: 2
Filename: controllers/constancia.php
Line Number: 38
A PHP Error was encountered
Severity: Notice
Message: Undefined offset: 1
Filename: controllers/constancia.php
Line Number: 38
is that the problem is in the date but not how to fix it
Check that the value of $fecha_constancia is an actual date in the format of Day/Month/Year.
This is line 38, correct?:
list($day,$mon,$year) = explode('/',$fecha_constancia);
Based on the error message, there's no slashes in $fecha_constancia. It can't assign anything to $mon and $year because explode is returning an array with a single element.

PayPalAPIInterfaceServiceService::SetExpressCheckout() returns null response object

I'm using Yii to build an application that requires payments through PayPal. After a lot of digging, I found that ExpressCheckout is the method to use. The code below worked fine some time ago (some (?) weeks ago, I suppose before PayPal rolling out their new developer platform), using version 1.2.95 of the PHP SDK. Now, using the latest version v.2.2.98, the code fails.
require_once(Yii::getPathOfAlias('application.libraries.paypal') . '/PPBootStrap.php');
$logger = new PPLoggingManager('SetExpressCheckout');
$PaymentDetails = new PaymentDetailsType();
$PaymentDetails->OrderTotal = $PaymentDetails->ItemTotal =
new BasicAmountType('USD', $subscription->price);
$PaymentDetails->PaymentAction = "Sale";
$PaymentDetails->OrderDescription = $subscription->description;
$setECReqDetails = new SetExpressCheckoutRequestDetailsType();
$setECReqDetails->PaymentDetails[0] = $PaymentDetails;
$setECReqDetails->CancelURL = 'someCancelUrl';
$setECReqDetails->ReturnURL = 'someReturnUrl';
$setECReqType = new SetExpressCheckoutRequestType();
$setECReqType->SetExpressCheckoutRequestDetails = $setECReqDetails;
$setECReq = new SetExpressCheckoutReq();
$setECReq->SetExpressCheckoutRequest = $setECReqType;
$paypalService = new PayPalAPIInterfaceServiceService();
$ok = TRUE;
try {
$setECResponse = $paypalService->SetExpressCheckout($setECReq);
if($setECResponse && strtoupper($setECResponse->Ack) =='SUCCESS') {
$token = $setECResponse->Token;
// Redirect to paypal.com here
$this->redirect(
'https://www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=' . $token);
}
}
catch (Exception $ex) {
Yii::trace(__METHOD__ . ': Exception while interacting with PayPal API, error: '
. $ex->getMessage());
$ok = FALSE;
}
The offending line is:
$setECResponse = $paypalService->SetExpressCheckout($setECReq);
In PayPalAPIInterfaceServiceService::SetExpressCheckout(), these two lines:
$resp = $this->call('PayPalAPIAA', 'SetExpressCheckout', $setExpressCheckoutReq, $apiCredential);
$ret->init(PPUtils::xmlToArray($resp));
are the issue. $resp is null, so the next line fails at the PPUtils::xmlToArray($resp) method call.
Obviously, either I'm missing something here, or PayPal does something wrong.
Any help?
After a lot of debugging, the cause of the issue was that the service.EndPoint.PayPalAPI parameter was not defined in sdk_config.ini. For some reason that I don't recall, this parameter was deleted from the working config file from the previous version.
Now, the express checkout method works fine, even with the latest 2.3.100 version of the API.

How to force text/html mime type using PeopleSoft SendMail()

I am trying to send an html formatted email using SendMail() in PeopleCode. What I am trying to do is very a basic html email (e.g. bolded text, a href tags, etc).
We recently upgraded to PeopleTools 8.52
When I use the default SendMail() example from PeopleBooks, The email is sent as plain text, regardless of the fact that I specified the content type as "text/html".
Local string &MAIL_CC, &MAIL_TO, &MAIL_BCC, &MAIL_SUBJECT, &MAIL_TITLES, &MAIL_TEXT, &MAIL_FILES, &MAIL_FROM, &REPLYTO, &SENDER;
Local number &MAIL_FLAGS;
&MAIL_FLAGS = 0;
&MAIL_TO = "laurie_thomas#peoplesoft.com";
&MAIL_CC = "";
&MAIL_BCC = "";
&MAIL_SUBJECT = "Testing SendMail - Are you receiving Attachment?";
&MAIL_TEXT = "This is a test for SendMail function";
&MAIL_FILES = "/data9/ps/e841g2bp/lat/attach.txt";
&MAIL_TITLES = "";
&MAIL_FROM = "peoplesoft#peoplesoft.com";
&MAIL_SEP = ";";
&CONTTYPE = "Content-type: text/html; charset=utf8";
&REPLYTO = "lthomas#peoplesoft.com";
&SENDER = "00972#peoplesoft.com";
&RET = SendMail(&MAIL_FLAGS, &MAIL_TO, &MAIL_CC, &MAIL_BCC, &MAIL_SUBJECT, &MAIL_TEXT, &MAIL_FILES, &MAIL_TITLES, &MAIL_FROM, &MAIL_SEP, &CONTTYPE, &REPLYTO,&SENDER);
If &RET <> 0 Then
MessageBox(0, "", 0, 0, "Return code from SendMail=" | &RET);
End-If;
As it turns out, this is a documented bug observed by Oracle (Bug:13714374). This occurs when upgrading from PeopleTools 8.51 to 8.52 (which is why it happened to us).
Solution from Oracle:
This Bug Fixed in the PT 8.52.08 patch, which became available on
05/24/2012