- What is the mybizna/partner package used for?
- The Partner module is part of the MyBizNa ERP family and is meant to add partner and stakeholder management to a Laravel application. Its stated scope is Eloquent models, migrations, and CRUD scaffolding for partner directories, contacts, and relationships. Treat the exact feature list as unconfirmed, because the 2025.001 release note contains no changelog, so verify models and routes against the repository before committing.
- How do I install mybizna/partner in a Laravel app?
- Run composer require mybizna/partner with an explicit version rather than a caret constraint, then publish config and migrations with vendor:publish and run php artisan migrate. Confirm the publish tags and any required core package by reading the service provider and composer.json, since setup steps are not documented in the release. Also check whether the package ships Blade, Livewire, or Vue assets that must be compiled alongside your application.
- How do I configure the package and decouple it from the MyBizNa user schema?
- Expect publishable config for table prefixes and relationship settings, and expect the package to assume a shared core for users, tenancy, and settings. If your host app uses a different user or tenant model, plan an adapter layer or contract override in the service provider. Read the bindings before writing code, because a package that hard-codes a schema will force either a refactor or a wrapper.
- Which Laravel and PHP versions does mybizna/partner support?
- There is no stated support matrix in the release note, so check composer.json for the illuminate/support constraint and the php version floor. Those two values decide whether the package fits your stack at all, and they are cheap to verify before any build slot is allocated. Validate on a single reference stack, such as PHP 8.2 with Laravel 11, before widening.
- How should I test a partner module built on mybizna/partner?
- Test at the layer you actually depend on: feature tests for the CRUD endpoints and unit tests around the Eloquent relationships, using an in-memory SQLite database for speed. If the migrations use MySQL-specific SQL, run a second suite against your production engine, because portability is where this package family typically breaks. Also assert on authorization policies and tenant scoping, since partner records are usually sensitive counterparty data.
- Is mybizna/partner safe to use in production?
- Treat it as provisional. The 2025.001 release ships only a compare link, with no changelog, migration notes, or diff summary, which signals that changelog and semver discipline are not yet established. Because partner records are typically core counterparty data, require a schema review and a manual diff read before production use rather than an install-and-go test.
- Why does version 2025.001 appear lower than 2025.2 in Composer?
- Composer normalises 2025.2 to 2025.2.0 and 2025.001 to 2025.1.0, so the newly tagged release sorts below the previous one. The compare link 2025.2...2025.001 is consistent with a re-tag or a versioning-scheme change rather than a forward release. Until the maintainer says which tag is canonical, composer update may not pick it up and a constraint like ^2025.2 will exclude it.
- Does mybizna/partner work with PostgreSQL or SQLite, or only MySQL?
- Database support is not documented, and migration portability is a known weak point in this package family. Open the migration files and look for raw SQL, engine-specific column types, and index or fulltext assumptions before assuming cross-database support. Running the migrations against your target engine on a throwaway database is the fastest way to find out.
- What are the alternatives to mybizna/partner?
- If you only need a partner or vendor directory, a small set of Eloquent models with migrations and resource controllers is often cheaper than adopting a domain module with an unstated schema contract. If you want an off-the-shelf CRM-style layer, compare against packages in the same ERP family or a dedicated CRM package that documents its data model. The deciding factor should be how closely the package's partner schema matches your existing records.
- How actively is mybizna/partner maintained and how painful are upgrades?
- A release with a bare compare link indicates the project has not yet adopted changelog or semver discipline, which is a leading indicator of upgrade cost on every future release, not a one-off. Depending on the family core package also widens the blast radius to anything else pinned to that core. Before adopting, ask the maintainer for a release cadence, a support policy, and a security-disclosure process.