Aurora Membership Manager

Rejestr zmian

1.3.4

• Makes Aurora Admin practical for event entrances by adding dedicated least-privilege scanner credentials for authorized event/check-in staff without granting member-list or member-write access.
• Adds dedicated checkins_read and checkins_write mobile scopes while preserving compatibility for existing administrator devices through the established member-scope fallback.
• Allows authorized staff to create a one-time Aurora Admin pairing challenge from the Core staff workspace without requiring full membership-management privileges.
• Keeps QR verification and event check-in authorization server-authoritative and re-evaluates the current WordPress user’s capabilities for every request.
• Keeps the additive Aurora Mobile API contract at 1.2.0 and the Core database schema at 1.2.0; no re-pairing or database migration is required for existing administrator devices.

1.3.3

• Adds a server-authoritative Aurora Admin QR verification endpoint using the existing paired-device credentials and member-management permissions.
• Reuses existing Aurora membership/check-in QR identifiers instead of introducing a second QR standard, including member-specific URLs, mmc: values, member IDs, unambiguous email identifiers and external references.
• Reloads the canonical Core member before every result and returns current membership status and expiry rather than trusting validity information carried by a QR payload.
• Adds neutral and legacy-compatible resolver hooks for provider-specific QR identifiers while keeping Core independent from Digital Cards and Pro.
• Adds capability-gated Aurora Admin member creation through the canonical Core repository, preserving server-owned identity fields and applying the configured Core expiry rule when no explicit expiry is supplied.
• Keeps formal privacy-consent provenance out of mobile member creation while allowing supported communication preferences and profile fields to be stored through existing Core rules.
• Advances the additive Aurora Mobile API contract to 1.2.0 while preserving existing members_write device credentials, so paired devices do not need to be paired again.
• Changes no database schema and does not change the public Core add-on API contract.

1.3.2

• Exposes the existing fixed-annual-expiry rollover policy in Initial configuration so an organization can choose the month from which new memberships and renewals use the next membership year.
• Keeps the Core expiry engine as the single source of truth; no WooCommerce-specific expiry calculation or database schema change is introduced.
• Preserves existing installations and defaults: annual memberships continue to roll to the next year from the configured threshold, with October as the historical default when the option has never been explicitly changed.

1.3.1

• Fixes an early-load mobile bearer-authentication route check that could call WordPress REST URL helpers before rewrite initialization and fatally interrupt unrelated REST requests.
• Keeps Aurora Admin bearer authentication restricted to the aurora-mobile/v1 namespace while allowing unrelated REST endpoints to operate normally during early WordPress bootstrap.
• Restores compatibility for sites that run Core alongside independent REST services such as the Aurora License Server; no database schema or Core add-on API contract change.

1.3.0

• Adds the native Aurora Admin REST API to Core for secure direct administration from compatible mobile clients.
• Adds short-lived, one-time pairing challenges and revocable device credentials without storing WordPress passwords or plaintext bearer-token secrets.
• Restricts device authentication to Aurora’s own mobile REST namespace and rechecks the paired WordPress user’s capabilities for every request.
• Adds mobile member list, search and detail endpoints plus controlled member updates through the canonical Core repository, including supported profile and consent fields.
• Protects integration-owned member identity fields from mobile editing and keeps existing Core validation, expiry and consent rules authoritative.
• Adds paired-device management to the existing Core Admin App workspace.
• Adds a controlled extension surface so separately installed add-ons can expose their own Aurora Admin capabilities and protected routes without being bundled into Core.
• Corrects a translation-context annotation in the CSV import error path identified by Plugin Check.
• No database schema change; the existing Core add-on API contract remains 2.0.0.

1.2.8

• Documents organization-specific extensions as a supported way to add tailored rules and workflows without forking Core.
• Adds one contextual extension-discovery panel to the Extensions screen with links to optional extensions and tailored-extension support.
• Keeps commercial discovery limited to the Extensions screen: no global promotional notices, dashboard advertising, remote promotional assets, tracking or locked Core controls.
• No database schema or public API contract changes.

1.2.7

• Fix checkbox and radio sizing in the member editor.
• Improve WordPress.org discovery tags and screenshot captions.
• Confirm compatibility with WordPress 7.1 after final-release testing.
• Clarifies that a saved renewal fee and currency are manual dashboard assumptions, while installed extensions may supply both values only when the fee is left blank.
• Fix final CSV import button remaining disabled when valid rows are ready.
• Prevent immediate import and backup-restore lock refreshes from being misreported as lost when their expiry value is unchanged within the same second.
• Keep a retained CSV preview visible and renew its retry window when a recoverable final-import error occurs.
• Keep member-bound portal tokens restricted to their original member identities.
• Preserve extension-defined consent keys when Core consent fields are updated.
• Report partial CSV write failures instead of treating them as skipped successful completion.
• Fix the renewal onboarding completion condition.
• Clean up Core schema/lock state completely when data deletion is requested on uninstall.

1.2.6

• Refreshes the WordPress.org presentation, documentation and screenshot captions, and adds one public link to information about optional extensions. No runtime, API or database schema changes.

1.2.5

• Removes promotional/storefront content from the WordPress administration while preserving the operational extension inventory and existing add-on hooks; no API or database schema changes.

1.2.4

• Completes the WordPress.org review hardening by fixing translator annotations for backup/restore notices; no functional API or database schema changes.

1.2.3

• Hardened Plugin Check handling for read-only backup/restore status notices; no functional API or schema changes.

1.2.2

• Hardened request/upload handling for WordPress.org review while preserving Core/add-on contracts.
• Normalized admin notice inputs and documented read-only request parameters for static analysis.

1.2.1

• Aligns the WordPress.org text domain with the approved aurora-membership-manager slug.
• Hardens Basic Setup upload hand-off so extension callbacks receive only explicitly registered and validated upload metadata, never the raw PHP upload superglobal.
• Completes the review audit for request nonces, permissions and early input sanitization while preserving the Core 2.0.0 API contract.
• Keeps Core free of commercial licensing and external update delivery; commercial add-ons remain separate plugins.

1.2.0

• Introduces collision-resistant Aurora_MMC and aurora_mmc prefixes across Core APIs, hooks, options, capabilities, routes and interface identifiers.
• Adds a conservative one-time migration for legacy Core tables, options and role capabilities while preserving existing add-on data.
• Uses identifier placeholders for dynamic database table names on supported WordPress versions.
• Removes inline administration JavaScript and strengthens direct output escaping.
• Preserves legacy public shortcodes as compatibility aliases.
• Publishes Core API contract 2.0.0 for the coordinated add-on releases.