- What is script-development/kendo-report-tool and what does it do in a Laravel app?
- It is a thin, Laravel-native client for submitting user-generated reports to a Kendo report service. It registers an auto-discovered KendoReportToolServiceProvider, merges and publishes a config/report-tool.php file, and exposes a single KendoReports::submit(...) call that sends a multipart POST authenticated with a report:create Bearer token. It is intended for backends where report creation is a supporting workflow rather than the core domain, and it returns the decoded result to the caller.
- How do I install and configure kendo-report-tool in a Laravel application?
- Install it with Composer, then publish the config file with php artisan vendor:publish so config/report-tool.php is available in your app. Set the REPORT_TOOL_* environment variables for the service endpoint, token, and behavior flags per environment, and confirm the package's service provider is auto-discovered. Because the integration surface is small, most of the setup work is credentials and environment configuration rather than application code.
- Which PHP and Laravel versions does kendo-report-tool support?
- The published CI matrix targets PHP 8.4 and 8.5, so older PHP runtimes are a gating factor for adoption. Framework version support beyond that matrix is not clearly documented, so check the composer.json constraints against your host application before installing. In a legacy Laravel estate on PHP 8.2 or 8.3, expect the package to be blocked until support widens.
- How do I submit a report, and can I upload files with the package?
- You call KendoReports::submit(...) with the report payload, and multipart uploads accept either Illuminate\Http\UploadedFile instances or local file paths. That covers the usual Laravel upload flow without extra adapters. File count and size limits are not clearly enforced by the package itself, so validate them in your host application and confirm the Kendo API's limits before relying on it.
- Should I call KendoReports::submit directly inside a controller request?
- Prefer invoking it from a queued job or console command rather than directly inside a user-facing HTTP request. The submission is a synchronous multipart POST, so inline calls consume request latency and PHP-FPM or Octane worker time. If the report is non-critical and fast, an inline call can work, but queueing keeps user-facing responses predictable and gives you a place to add retries.
- Is the HTTP client injectable or mockable for application tests?
- The assessment flags injectable or mockable HTTP client support as an open question, and no explicit Laravel HTTP client injection point is documented in the release notes. The package ships a Pest and Testbench harness, which supports its own test suite and gives you a pattern to follow for host-application integration tests. To keep your app testable, wrap KendoReports::submit behind your own interface or service class so you can fake submissions without hitting a Kendo sandbox.
- What are the default timeouts, and does the package support retries or idempotency?
- Default connect_timeout and timeout values are not described in the release notes, so treat them as something to verify in config/report-tool.php and set explicitly for your environment. No retry/backoff policy or idempotency key support is documented, which matters because queued jobs can retry and create duplicate reports. Add deduplication at the job level, such as a unique report reference or a queued job with a uniqueness lock, until the package offers first-class idempotency.
- What does REPORT_TOOL_SWALLOW do and when should I enable it?
- REPORT_TOOL_SWALLOW=true degrades failures to an error_log entry plus a null return instead of surfacing an exception. That is convenient for non-critical reporting where a failed report should never block the main workflow, but it is risky if used broadly because failures become invisible to your normal error handling. Keep it off initially and enable it only for report types where silent failure is genuinely acceptable, and check where error_log is routed in your deployment.
- How is the Bearer token scoped and rotated, and does the package handle PII?
- The client authenticates with a report:create Bearer token, which appears to be a narrow scope, and the token is supplied through REPORT_TOOL_* environment variables so it can differ per environment. How tokens are rotated or scoped per Kendo project is not specified, so plan rotation through your secrets management and confirm the scope with the Kendo service owner. The package intentionally does not scrub PII because report content is user input, which makes data governance and retention your responsibility.
- Is kendo-report-tool production-ready at version 0.1.0, and what safeguards should I use?
- This is a 0.1.0 release, so breaking changes should be expected and the package's 0.x support and versioning policy is not clearly stated. It fits best in a Laravel app on PHP 8.4+ with a queue worker, adopted first for a non-critical report type or internal tool. Wrap it behind your own service interface and pin the version so you can replace it or adapt to Kendo API changes without touching every call site.