6 Commits (8c556bbe36cbd7cef134c61d3035315727a1ed0c)

Author	SHA1	Message	Date
Kirill Solomko	8c556bbe36	TT#149459 improve and automate expand functionality ... * add dictionary support for fields that are expanded if encountered in all endpoints, with a possibility to override it, if defined on the endpoint's field level * move expand definitions from form fields into the Expand dictionary * simplify the expand usage, it now operates only with the <x>_id fields that are returned and visible in the response (e.g. if reseller_id is returned, then ?expand=reseller_id), the returned expand object name is <expand_field_name>_expand the, so in case of ?expand=reseller_id, the returned object will be reseller_id_expand * adapt Role/SystemContacts to work correctly with the expand functionality * expanded fields are returned as <expanded_field_name>_expand Change-Id: I4cab44ede9b40c70a95bbcedc81f58dd1f4e3b67	4 years ago
Kirill Solomko	2b144caf2c	TT#128605 implement dynamic fields expand ... * add API functionality to request additional data and expand fields in GET methods * syntax: - /api/resource/?expand=all - expands all expandable fields e.g.: customer_id field is expanded and customer internally is queried and returned under "customer" => {...} (the returned data is identical to what /api/customers/id would return) - /api/resource/?expand=reseller_id,customer_id - expands only reseller_id and customer_id fields, if they are expandable - /api/resource/?expand=reseller_id,invalidfield_id - returns the data and expands only fields that are expandable (reseller_id in this case) but if it finds either unknown fields or non-expandable fields, changes HTTP status code to "409 Conflict" * adapt all API endpoints to support dynamic expand fields expanding functionality, however the actual expand for them requires modifying the form fields in the following format: has_field 'contact_id' => ( element_attr => { expand => { class => 'NGCP::Panel::Role::API::CustomerContacts', id_field => 'contact_id', alias => 'contact', fetch => 0, }, }, ); - class - represents the class that should be used by the logic to fetch the relevant data - id_field - which field from the resource needs to be expanded, it should be the "id" field (subscriber_id, domain_id, etc.) - alias - (optional), under which key the fetched data is stored. the field name is used as the key if the option is omitted. - fetch - (optional), if the returned data is under $data->{contract_id} then it will be fetched from there and stored under the key (field name or alias), otherwise the whole retreived data is stored under the key (field name or alias) * adapt /api/autoattendants to use the new approach (old one was expand=1) * currently supported endpoints with expand: - admins - autoattendants - domains - customers - customercontacts - resellers - subscribers Change-Id: Iac53409dad944ed4794039a48dc3a9f6dce25bc1	4 years ago
Yaroslav Fedorina	d3d1e9e3f1	TT#26107 Clarify external_id field description ... Change-Id: I6054b579bb713454dc70d456e3b4d62c666f13fb	8 years ago
Guillem Jover	a6d859ca8f	MT#21193 Remove unused dependencies and imports ... The codebase does not use autodie directly, it does indirectly via Sipwise::Base, and the autodie module is part of the standard perl distribution anyway. TryCatch is imported via Sipwise::Base, and that depends on it. The rest are not used anymore in the codebase. Change-Id: Ic08e246cc60d7d151381dff39e0eba517a492e06	9 years ago
Andreas Granig	04a64e1493	MT#16465 partly remove namespace::sweep and others ... Remove namespace::sweep Remove MooseX stuff Remove perl5i Remove Moose where possible Change-Id: I4f873afb466f4e58a04c3304ff74df2185470b03	10 years ago
Rene Krenn	2537819f0d	MT#12643 billing networks and multi bill prof WIP ... -properly validate billing mapping intervals -api/contracts and api/customers complete +the problem with updating the "prepaid" preference remains at the moment +billing_mappings field contains future (editable) mappings only, the full schedule is given in a separate field +hal-links to all occurring billing profiles and networks -extended tests: api-customer.t and api-contract.t -api-billingnetworks.t test -billing networks panel controller +search by enclosed IP address -panel UIs for billing networks, customers, contracts +past billing mapping intervals that cannot be edited are displayed by a seperate hfh "block" part of the billing_profiles repeatable -profile packages api, UI +terminating billing profiles (MT#8645) will be broken +fixed now: profile cannot be terminated unless there are: -zero non-terminated customers, whose mappings contain the profile with future or open end -zero profile packages, that link to the profile in either one of their initial-, underrun- or topup profile sets +panel edit should work, termination wip +topup_profiles w/o amounts +contracts/customers API profile_package_id field: +apply the package's initial profiles +api/customer and api/contract profile definition modes (id/profiles/package) +api OK, api-customer.t tests +customer and contract panel UI with selector to specify actual billing mapping, schedule or profile package (same as api) +terminate logic harmonized: profiles, networks, packages +api tests updated +prepare for merging: cleanup, enable tests Change-Id: I6c0dec72f490b5731fc673cd393d6aeb08dd8143	10 years ago