Im looking for remote framework using scripts for ISPconfig. I have ISPConfig 3. But in core there are only mail_ functions. Im understanding, that its not hard to write new function, but if you have examples for ISPconfig3, Ill be very happy... =))) And another one problem: Im trying to add mail_domain, After running this function from remote script, i see domain, but without any name, client_id and activity. That im doing not right? $params = array ( 'sid' => $session_id, 'module' => 'mail', 'function' => 'mail_domain', 'params' => array ( "domain" => 'test1.com', "active" => 'y', "server_id" => '1' )); $domain_id = $soap_client->call('mail_domain_add', $params); if($err = $soap_client->getError()){ die("Error: ".$err); }else{ print_r($domain_id); }
You only have to know the client_id for adding or 0 for admin owner. hope to help //* Add a mail domain public function mail_domain_add($session_id, $client_id, $params) { if(!$this->checkPerm($session_id, 'mail_domain_add')) { $this->server->fault('permission_denied', 'You do not have the permissions to access this function.'); return false; } $domain_id = $this->insertQuery('../mail/form/mail_domain.tform.php',$client_id,$params); return $domain_id; }
Acutally with the 3.0.2 the remote framework will be complete. Instead of knowing the client_id you have to know now the sysuser_id.
There seems to be a bug in this function, as it should be the client ID and not sysuser_id (the variable is named also client_id). The sysuser_id is only for ispconfigs internal use and should not be exposed in the api especially as the api does not offer a function to retrieve this ID and the sysuser id is not unique for a client as there might be more then one sysuser for a client. I will see how this can be corrected until the release of 3.0.2 so that the client_id is used in all functions.
Actually we changed that, because you couldn't get the client id from the e.g. the mailbox, only the sysuser_id and when the sysuser wasn't the main sysuser of a client, the error appeared that there was no client user found. So we changed it. I asked you, if you remember.
I thought the change was only that the function will work even if no client ID id was set (set 0 (admin) as default in this case). I will review the code again. But we will have to change it back to client_id if it was changed to sysuser ID. By the way, the current ISPConfig does not support to add additionaly sysusers for a client as the information about the underlying client can not be set trough the interface, at the moment it is only allowed to add additional admin users. As you see in the SVN version, there has a warning be added now to not try to add sysusers as they can not work (not only in the api, they will not work in the normal web interface as well as all records created by such a user will be invalid and you get a permission error then). Sorry about the misunderstanding, but using the sysuserid in the api instead of client ID is not an option.
I've just checked the code, the reason that it did not work was a wrong fieldname in the SQL query. The original query was: SELECT * FROM sys_user WHERE sysuser_id = $client_id but there is no column sysuser_id in that table. The correct query is: SELECT * FROM sys_user WHERE client_id = $client_id so the loading of sysuser details for a specific client_id will work now. As a solution for for looking up a client_id, I think we can either a) add a lookup function to the API for it or b) we return the client ID automatically in the array that the *_get functions return. Which option would you prefer?
But then I would like to have a function to get the client id from the appropiate mailbox, domain, etc.
That should not be a problem. I will add a function like: get_client_id($sysuser_id); I will add this tomorrow and upload it to svn.
Thank you for answer, But your code is for LOCAL script, i mean it must be run only on server, there is ISPConfig, But im running my script from Remote server, hes connecting to ISPconfig, and adding null value.
@detot: ivomendonca posted you the function stub from the server side so that you understand better how this works. These functions are exposed by a soap server, so the options for calling them remotely are identical.
I am in the process of writing some code using the remoting API and came across two functions that change the order of the arguments parsed. mail_user_update($session_id, $client_id, $domain_id, $params) AND mail_fetchmail_update($session_id, $domain_id, $client_id, $params) $domain_id and $client_id are sent in a different sequence and although this isn't strictly a bug it would be great to have this the same. In my case I am using one function to do all my remoting calls namely 'grud_record'. The function breaks with one of these functions depending which order I send. I haven't checked for other differences.
The parameters should be consistent of course. Please add this to the bugtracker and we will review this.
