Difference between revisions of "MOR API user details update"

From Kolmisoft Wiki
Jump to navigationJump to search
Line 10: Line 10:
* For Backwards-compatibility old name 'user_update_api' is also usable. Call: '''/api/user_update_api'''
* For Backwards-compatibility old name 'user_update_api' is also usable. Call: '''/api/user_update_api'''
* Methods: POST, GET(if allowed, not recomended)
* Methods: POST, GET(if allowed, not recomended)
<br><br>
Note if Admin checked Allow Resellers to use Admin Tariffs in [[API Configuration]] then using this API Reseller can set for his Users Wholesale or Retail Tariffs which belongs to Admin.
<br><br>
<br><br>
===Parametres===
===Parametres===

Revision as of 05:25, 8 September 2014

Description

MOR API Update user from params.

Please note that it is not necessary to send ALL user parameters - you can send only those you need to update.

Usage

  • From MOR X4 call: /api/user_details_update
  • For Backwards-compatibility old name 'user_update_api' is also usable. Call: /api/user_update_api
  • Methods: POST, GET(if allowed, not recomended)



Note if Admin checked Allow Resellers to use Admin Tariffs in API Configuration then using this API Reseller can set for his Users Wholesale or Retail Tariffs which belongs to Admin.

Parametres

Parameters which are included into hash (if it is used):

  • user_id - Users ID in MOR database, whose details we want to change. REQUIRED.
  • u - username of user which can modify details (admin, reseller or accountant). REQUIRED.
  • u0 - vat number
  • u1 - lcr id
  • u2 - warning email hour
  • u3 - hide destination end
  • u4 - currency id
  • u5 - tariff id
  • u6 - warning email balance
  • u7 - spy device id
  • u8 - language
  • u9 - username
  • u10 - warning balance call
  • u11 - acc group id
  • u12 - generate invoice
  • u13 - usertype
  • u14 - taxation country
  • u15 - blocked
  • u16 - quickforwards rule id
  • u17 - last name
  • u18 - call limit
  • u19 - clientid
  • u20 - recording hdd quota
  • u21 - cyberplat active
  • u22 - recordings email
  • u23 - first name
  • u24 - warning balance sound file id
  • u25 - postpaid
  • u26 - accounting number
  • u27 - agreement number
  • u28 - hidden
  • ay - agr_date year
  • am - agr_date month
  • ad - agr_date day
  • by - block at date year2011
  • bm - block at date month
  • bd - block at date day
  • pswd - password
  • user_warning_email_hour
  • pgui - privacy gui [0-off, 1-on]
  • pcsv - privacy csv [0-off, 1-on]
  • ppdf - privacy pdf [0-off, 1-on]
  • recording_forced_enabled - [0-off, 1-on]
  • i4 - invoice detailed csv [0-off, 16-on]
  • tax4_enabled - [0-off, 1-on]
  • tax2_enabled - [0-off, 1-on]
  • accountant_type_invalid
  • block_at_conditional - 15
  • tax3_enabled - [0-off, 1-on]
  • accountant_type
  • tax1_value - float
  • show_zero_calls - [0-off, 1-on]
  • warning_email_active - [0-off, 1-on]
  • compound_tax - [0-off, 1-on]
  • tax4_name -
  • allow_loss_calls - [0-off, 1-on]
  • tax3_name -
  • tax2_name -
  • credit - float
  • tax1_name -
  • total_tax_name -
  • tax2_value - float
  • tax4_value - float
  • ignore_global_monitorings - [0-off, 1-on]
  • i1 - invoice pdf [0-off, 2-on]
  • tax3_value - float
  • cyberplat_active - [0-off, 1-on]
  • i2 - invoice csv [0-off, 4-on]
  • i3 - invoice detailed pdf [0-off, 8-on]
  • recording_enabled - [0-off, 1-on]
  • email_warning_sent_test - [0-off, 1-on]
  • own_providers - [0-off, 1-on]
  • a0 - address
  • a1 - city
  • a2 - postcode
  • a3 - county
  • a4 - mob_phone
  • a5 - fax
  • a6 - direction id
  • a7 - phone
  • a8 - email
  • a9 - state

Note that parameters are shown in the same order as they have to be when generating the hash. Last parameter in a row is API_Secret_Key

Parameters which are not included into hash:



Reguest

We have user_id = 123, API Secret Key = 456789, u15=1 (we want to block user)

We send: 

HTML POST: http://<server_ip>/api/user_details_update?u=username&user_id=123&u15=1&hash=0ab3ede4e93a55c38855a2cc9b9e169d35442c48

* Note that username and password are not included in hash

Other examples: 

HTML POST: http://<server_ip>/billing/api/user_update_api?u15=1&user_id=789&u=admin&u15=1&hash=0in2w8n01rwnodv4t0y5zzfp1h5hdp1fyk7z

This request blocks (u15=1) user with ID 789 (user_id=789). User belongs to admin (u=admin). 


HTML POST: http://<server_ip>/billing/api/user_update_api?u16=3&user_id=789&u=admin&u15=1&hash=0in2w8n01rwnodv4t0y5zzfp1h5hdp1fyk7z

This request changes user quickforwards rule to rule with ID 3 (u16=3) user with ID 789 (user_id=789). User belongs to admin (u=admin).

Returns

Success 

<page>
  <status>User was updated</status>
 </page>



Errors

  • <error>User was not found</error> - User was not found using user_id. Use correct user id.
  • <error>Incorrect hash</error> - Hash was not correct. Check API_Secret_Key and order or params while concatenating hash_string.
  • <error>Access Denied</error> - Check params and permissions.
  • <error>You have no editing permission</error> - Accountant dont have permission.
  • <error>Tariff not found</error> - Tariff was not found using param u5.
  • <error>User was not updated</error>
  • <message>problem message</message>



See also

Retrieved from "https://wiki.kolmisoft.com/index.php?title=MOR_API_user_details_update&oldid=18320"