6 Commits (d0eddeee57c29f68bd91922f552a92a58a8bb80f)

Author	SHA1	Message	Date
Kirill Solomko	9d021be65a	MT#59979 add license control ... * UI and API parts are now under license control * new Util::License::get_license($c, $name) - fetches license status by name (1 if enabled, and also if /proc/ngcp/check if 'ok') * add Catalyst::Plugins::NGCP::License with license($name) to fetch valid license by name from anywhere using $c->license('pbx') or from the templates using c.license('pbx'). It internally uses Util::License::get_license($c, $name) * License::get_license_status($c) now requires $c as first argument as well logs license status check errors. * new ActionRoles::License that enables usage of :Does(License) RequiresLicense('pbx') LicenseDetachTo('/denied_page') in the Controller chains * Add license control for UI elements and return 403 Forbidden if a resource is covered by licenses and the license is not active * Hide UI elements if a license is not active * API/Entities/Entities new $c->set_config key: - per endpoint: $c->set_config({ required_licenses => [qw/pbx device_provisioning/] } - or per method: $c->set_config({ required_licenses => { POST => [qw/pbx device_provisioning/] } } } * In case if an API endpoint does not have a license: 403 Forbidden "Invalid license" reply is returned. * Add license based restrictions to API endpoints * /api documentation: - completely hide endpoints that do not have an active license - hide only methods that does not have an active license Change-Id: Iba45fc5068b02306a617fed7b5405f2210574b61	2 years ago
Rene Krenn	9c103302c8	MT#60575 dynamically load provisioning templates module ... Change-Id: Ibff509825f82a75c9b0221505a1673d78b401989	2 years ago
Kirill Solomko	205b27a267	MT#59478 API better transaction and error handling ... * Role/Entities*: POST/PUT/PATCH/DELETE methods changes: - support deadlock detection and transaction retry (2 retry attempts at the moment) - improve transaction control, use local $guard instead of saving the ref to $c->stash, as in that case it went out of scope too late and also reported an error message into the log about abnormal $guard out of scope interruption - move all non transaction related code outside of the scope - add error handling when methods such as update_item, and a like do not return the expected data, instead of simply going out of scope and resulting in an uncontrolled reply * Role/API: - rework transaction control: + get_transaction_control() is renamed to start_transaction() to better reflect what it does + complete_transaction() is renamed to commit_transaction() + remove unused %params arg + pass $guard into commit_transaction() instead of having it stored as $c->stash->{transaction_guard) that caused the $guard ref to be destroyed much late than expected (there was also a typo as transaction_quard, which is not relevant anymore with the changes + add check_deadlock() that is invoked when an exception is caught or an $c->errors contain an error, and if the error message represents a transaction error, the transaction block is re-invoked via "goto TX_START" - rework error(): + it now accepts args as following: ($self, $c, $code, $message, @errors) # code -> returned as HTTP code in the reply # message -> returned as HTTP message in the reply # errors -> contain errors for internal logging, last element often contains a DBIx exception + populates all @errors into $c->error so they are available on demend in the code via $c->error or $c->last_error + $c->log->error is not invoked now as the errors become printed in log_response() - log_response() now prints collected errors from $c->error correctly as a separate log line, that is alike to the other api logs so that those can be looked up by the request's tx_id, also all errors are now printed only into api.log * Adjust all $self->error() calls in catch($e) to include $e as the last argument, as well as the duplicate $c->log->error is removed from those ocassions * Remove all $c->log->error() calls as they are replaced with either $self->error() (that logs it correctly into api.log) or $c->error('err') that also adds it correctly into api.log * API::CallForwards: rework to use Entities/EntitiesItem * API::Contracts: rework POST to use Entities * API::PeeringGroups: rework POST to use Entities * API::SubscriberRegistrations: rework POST to use Entities * API::RewriteRuleSets: improve create_item() functionality * Utils/Message: add 'api_retry' log type * $c->session->{api_request_tx_id} is changed to $c->stash->{api_request_tx_id} because sometimes the session ref is different and a different tx_id becomes used Change-Id: I633ce7a8047b1bf00a2f6889003088edf0825dcd	2 years ago
Rene Krenn	e73dd3ea27	TT#132650 api .csv upload for provisioningtemplates ... the POST /api/provicioningtemplates/<reseller>/<template> request will accept text/csv content type to provision many susbcribers at once. Change-Id: I59079ba8f2bacc0ce2b1367d2bd1a7251cf4763c	5 years ago
Rene Krenn	4c47920f2e	TT#132650 run provisioningtemplate from api ... provisioning templates with their dynamic forms can be executed by a entityitem POST request, ie. POST /api/provicioningtemplates/<reseller>/<template> or POST /api/provisioningtemplates/<readonly template> Change-Id: I77f6c9d42e1afdb49635d3f11e4d73bcf6269605	5 years ago
Rene Krenn	b6e696621b	TT#132650 /api/provisioning_templates CRUD rail ... the /api/provisionintemplates rail provides the operations to create, edit and delete "provisioning templates" know from the "batch provisioning" feature of admin panel. these templates can also be defined in config.yml, while it is however only possible to edit templates stored in the database. executing a template and/or uploading a .csv for bulk execution will be available in a separate part. Change-Id: If8627327270edfce5bca1be3b1f777c1bd44e90f	5 years ago