eladmin-mp and a Chinese admin panel built on MyBatis-Plus

The stack is stated in one line, and it is a specific generation

The project describes itself as a front end and back end separated admin system built on Spring Boot 2.7.18, MyBatis-Plus, JWT, Spring Security, Redis and Vue, and the repository description adds that permissions use RBAC and that it supports data dictionaries, data permission management, one-click generation of front and back end code, and dynamic routes.

The stack list matters more here than it would in a library, because the versions are pinned in the readme rather than left to you. Spring Boot 2.7.18 is a specific point release of a generation that has since been succeeded, and the build is a MyBatis-Plus variant of the original eladmin, which is the same system built on plain MyBatis. The sibling project on the same documentation site is the other branch of the same idea, which is worth knowing if you want to compare the two data access approaches.

The Vue front end uses Element UI, which the topic list confirms, and the readme credits the template it started from, the vue-element-admin template by PanJiaChen, along with the general CRUD front end components by Moxun, the back end operations management features by zhy6599, and the anonymous interface and Redis rate limiting work by j.yao.SUSE. So this is a fork and a composition rather than something written from nothing, which is normal for a project of this kind in this market and is useful context for judging the code quality.

Getting the code is a matter of picking a mirror, and the readme points at both:

| github                                 |   gitee  |
|--------------------------------------| --- |
| https://github.com/elunez/eladmin-mp |  https://gitee.com/elunez/eladmin-mp   |

The front end, the Java modules and the database schema sit side by side at the root of the repository, so a clone gives you all three parts of the system at once.

The documentation site is eladmin.vip, with a live demo at eladmin.vip/demo, and the demo credentials are given in the readme as `admin / 123456`, which is a reasonable thing for a demo and a warning sign for anything derived from it. The readme does not include build or run commands, so the install steps live on the documentation site rather than in the repository, and the `sql/` directory is where the schema lives for the generated tables.

Six modules, and the split tells you where the work is

The project structure is organised by function, and the module list is short enough to be worth reading in full.

`eladmin-common` is the shared module, holding the utility classes and the common configuration. `eladmin-system` is the core module and the entry point of the project, and it is the module you package and deploy. `eladmin-logging` is the logging module, which other modules pull in when they need to record logs. `eladmin-tools` is the third party tool module, containing email, Amazon S3 cloud storage, local storage and Alipay. `eladmin-generator` is the code generation module, which supports generating front and back end CRUD code.

That gives five modules, with the tools module and the generator module being the two that are optional in practice, and the front end sitting in a separate `eladmin-web/` directory at the repository root, alongside an `eladmin/` directory for the Java side and a `sql/` directory for the database schema.

Inside the common module the detail is where the framework decisions show. There is an `annotation` package for the custom annotations, an `aspect` package with the aspects that implement them, a `base` package providing the Entity base class, and a `config` package holding the MyBatis-Plus configuration, the web configuration for cross origin and static resource mapping along with Swagger and the temporary upload path, the Redis and Redisson configuration with the async thread pool, and the permission interception configuration. There is an `exception` package for unified exception handling, and a `utils` package with a set of named helpers, BigDecimaUtils for money arithmetic, RequestHolder for the current request, SecurityUtils, StringUtils, SpringBeanHolder for static access to beans, RedisUtils, EncryptUtils and FileUtil.

The `BigDecimaUtils` entry is the one worth pausing on, because money arithmetic in a billing or commerce back office is a classic place for rounding bugs, and having a dedicated helper for it in the shared module is a reasonable signal about what the project has been bitten by.

The feature list covers the admin basics and then some

The system functions list is a useful inventory of what you get on day one, and it is longer than a starter kit usually is.

User management with the note that a newly added user gets the default password 123456. Role management, which assigns permissions and menus and can set a role's data permissions by department. Menu management, which implements dynamic routes configured from the back end with support for multi level menus. Department management with the organisation structure shown as a tree table, and post management for the positions within each department. Dictionary management for maintaining fixed data such as statuses and genders.

Then the operational modules. System logs record user operation logs and exception logs for debugging. SQL monitoring uses Druid to watch database access performance, with the default username admin and password 123456. Scheduled tasks integrate Quartz with task logs so the run status is visible. Code generation produces front and back end code. The email tool sends HTML formatted mail alongside a rich text editor. Amazon S3 cloud storage is supported for most object storage services and is compatible with the S3 protocol, so Qiniu and Alibaba Cloud work too. Alipay payment is integrated with a test account for trying it out. Service monitoring watches server load, and operations management deploys your application with one click.

The feature list at the top also names cross cutting behaviour: interface rate limiting to keep malicious requests from pressuring the service layer, interface level functional permissions and data permissions with customisable operations, custom permission annotations and anonymous interface annotations for quick interception and pass-through, and wrappers for common front end components such as table data requests and data dictionaries. Unified exception interception and unified exception output are called out too, which removes a lot of repetitive checking from controllers.

The features section adds online user management, server performance monitoring, and the ability to limit a single user to one login.

The anonymous interface annotation and the rate limiter are the interesting parts

Two of the cross cutting features deserve a closer look, because they are the ones a team would otherwise have to build for itself.

The first is the custom permission annotation and the anonymous interface annotation, which together let you protect an endpoint by annotation and let you leave one open by annotation. The credited contribution that added anonymous interfaces and Redis rate limiting together is the hint here: the same mechanism serves both purposes. An interface can be marked as requiring a permission, as open to anonymous callers, as rate limited, or as a combination, and the interceptor reads those annotations at the boundary rather than scattering checks through controller code.

The second is that the rate limiting is implemented on Redis, which means it works across a cluster of instances rather than per JVM. For a system with a Redis dependency already in place, that is the cheap way to get a global limit on an expensive endpoint such as a login attempt or a report query.

The permission model underneath is finer grained than the usual role check. Beyond role based access, the readme describes interface level functional permissions and data permissions, with customisable operations, and role management that can set a role's data permissions by department. That means a user can be allowed to see records belonging to their own department and not another, which is the sort of requirement that appears in enterprise back offices and is rarely built by hand.

The dynamic route part is a front end concern and it is worth being precise about, because the claim is specific: menu management implements dynamic routes, configured from the back end, supporting multi level menus. The routes the client loads are therefore a function of the logged-in user's permissions, not a fixed set in the front end bundle. That is what makes a back office with per-role navigation work without shipping a different front end build to each team.

The code generator is the feature that pays for the project

The code generator is listed twice in the readme, once in the features as the reason for high efficiency development with a one-click generator for front and back end code, and once in the project structure as its own module, `eladmin-generator`, described as supporting generation of front and back end CRUD code.

For a project whose feature set is essentially an admin system plus a code generator, that is the point. The hand written part of an admin panel is almost entirely CRUD: a list view, a form, a search, a delete, a permission. Writing that by hand for twenty entities is a lot of repetitive code that a generator can produce, and the generator is the part of the system that a team will use every day.

The acknowledgements hint at how the front end side is handled, since the general CRUD front end components come from an external contribution, and the code generator is described as producing both halves. The `eladmin-generator` module lives on the Java side, so the generation logic, the templates and the front end scaffolding are driven from the back end.

What the readme does not say is how the generated code is shaped, which entities it can generate for, whether the generated code is meant to be edited afterwards, or how it copes with the permission annotations, since a generated controller has to participate in the same annotation based access control as a hand written one. Those are the questions to ask before you generate your entire domain layer and then find the templates need changing.

The repository root holds a `sql/` directory, which is where the schema for the generated tables and the seed data would live, and that directory is the first place to look when you want to see what the generator expects.

Default credentials and an exposed console are the deployment risks

The readme states the default administrator credentials for the demo, `admin / 123456`, and separately states that the Druid SQL monitoring console uses the default username admin and password 123456. It also states that a newly added user has the default password 123456.

None of that is unusual for a Chinese open source admin template, and the documentation is candid rather than coy about it. But it does define the work required before this goes anywhere near a public interface. Three defaults have to change: the initial administrator password, the password of every user created through the admin, and the Druid console credentials. The third is the one that gets missed, because the SQL monitoring module is usually installed for the benefit of the team and then left enabled.

The Druid console deserves a specific note. It is a database monitoring console, and it is exposed as part of the application, so whether it is reachable from outside depends on your network and on the Spring Security configuration the project ships. The readme mentions a Druid configuration for removing advertisements in the permissions section of the common module, which suggests the console is on by default.

There is a related point about the operations management module. A one-click deployment feature that pushes an application to a remote server is exactly the kind of feature that should be disabled in an environment where the application is reachable by more people than the operators.

None of this makes the project unsuitable. It makes the checklist longer, and every item on it is a configuration change rather than a code change.

Where a template admin system is the wrong answer

There are three situations where starting from eladmin-mp is the wrong move, and the first is the one most teams will hit.

The first is the framework baseline. Spring Boot 2.7.18 and the associated MyBatis-Plus generation are pinned in the description, and the repository's last push was on 2026-05-11 with no GitHub releases, so there is no version history to track the upgrade path. If your roadmap involves a current Spring Boot release, you are looking at a migration of the whole stack, and the value of the template shrinks fast.

The second is a team that does not want a template at all. A full admin panel with users, roles, departments, posts, dictionaries, logs, scheduled tasks, payment integration, cloud storage and code generation is a large surface area, and every one of those modules is code you now own, must patch for a dependency update, and must understand before you trust it with a permission decision. The generator and the RBAC model are the parts with real value. The Alipay integration, the S3 tool, the operations deployment module and the online user management are all optional weight unless your product needs them.

The third is a product with a user-facing front end where the admin is an internal tool. Nothing here helps with the customer facing application, and the Vue and Element UI front end is an admin console rather than a component library, so there is no reuse in the other direction.

The honest summary is that eladmin-mp is a well organised, feature complete starting point for a Chinese enterprise back office, offered in a MyBatis-Plus flavour, and that the interesting work for an adopter is deleting the modules you do not need, changing the passwords, and deciding whether to keep the framework generation at all.

Editorial conclusion

eladmin-mp fits a team building a Chinese market back office that needs user, role, department, post, dictionary, log and scheduled task management on day one, and that wants the code generator to produce both halves of a CRUD screen. It is the wrong choice if you want a current Spring Boot baseline, since the project sits on 2.7.18, and the wrong choice for a system exposed to the internet without changes, because the default administrator password and the Druid console credentials are both documented in the readme. Before you build on it, verify three things: which Spring Boot and MyBatis-Plus versions your own roadmap needs against the 2.7.18 baseline, which of the included integrations you actually want to carry, from Alipay to Quartz to the S3 storage tool, and how you will replace the default credentials and the exposed monitoring console. The code is Apache-2.0, the default branch is `master`, the last push was on 2026-05-11, and the repository publishes no releases.

Frequently asked questions

Official sources

1. elunez/eladmin-mp on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README