What's new in EzyPlatform 1.5.1?

This release focuses on expanding per-API permission control, improving the Role system for Admins and Users, and optimizing login and callback URL flows across both Admin and Web.
  1. Added an Event to control API permission checks
    Added the check_api_user_permission_required Event, allowing applications to decide on a per-request basis whether user permission checks are required. The Event receives feature, method, uriTemplate, and userId. A result of true requires a permission check, false skips the check, and null uses the platform's default behavior.
  2. Added Feature configuration for multiple Roles
    WebRoleFeatureConfig has been extended with getFeaturesMapByRoleName(), allowing a single configuration to define Features for multiple Roles instead of being limited to one Role. Configuration dependencies are also automatically bound and now provide setters for easier extension and customization.
  3. Added APIs for assigning Roles by name
    Added saveAdminRolesByAdminIdAndRoleNames() and saveUserRolesByUserIdAndRoleNames() to assign Roles to Admins or Users directly by Role name. Assigning Roles to an Admin by ID is now idempotent, preventing duplicate records from being created when the same Role has already been assigned.
  4. Added batch Role lookup APIs
    Added findByNameIn(), getRoleIdsByNames(), getRoleIdMapByNames(), getRoleMapByIds(), and getRoleNameMapByIds(). These APIs allow multiple Roles to be retrieved in a single operation, reducing the number of database queries when applications need to process multiple Roles at once.
  5. Improved the Admin login flow
    Before redirecting to the login page, Admin now stores the current URL as the Callback URL. After a successful login, users are redirected back to the correct previous page, and the Callback Cookie is cleared after use. The Callback Cookie is created only when the URL is valid, providing a more accurate and secure redirect flow.
  6. Improved the Web login flow
    ezyweb.redirectToLogin() now stores the current path and query parameters in sessionStorage.loginCallbackUrl before redirecting users to the login page. An existing callback is not overwritten when the user is on /login or /register, ensuring that users return to the correct original page after completing the login process.
  7. Extended WebAuthenticationInterceptor customization
    WebAuthenticationInterceptor has been extended so subclasses can customize getAccessToken(), needToCheckPermission(...), and checkPermission(...). This gives applications greater flexibility when implementing custom Access Token retrieval, deciding when permission checks are required, or providing their own Permission logic.