How to Add a Creator Province Filter to a To-Do Page and Fix Pagination Bugs

How to Add a Creator Province Filter to a To-Do Page and Fix Pagination Bugs

The purpose of this article is to record the first real‑world requirement I faced, share the implementation ideas and optimization steps, and help developers think systematically when tackling new features.

Requirement Analysis

New query condition: Creator Province (same values as the existing province list).

When the user clicks the search button, the system must filter the to‑do work orders by creator province.

The backend list API needs to accept the new filter.

Work‑order status count statistics must also consider the creator‑province field.

The reset button must clear the newly added field.

Specific Implementation

Adding Frontend Controls

Locate the component at

workOrderSl/toDoOrder/index

and edit the

index

component.

Use Element UI components:

el-row

– row container

el-col

– column container

el-form-item

– a form field

el-select

– dropdown bound with

v-model

el-option

– options generated with

v-for

Different Status Work‑Order Count

The

queryCount

method already aggregates counts for four statuses using a single backend endpoint. The new field

creatorPro

is added to

formData

and the backend query is updated to filter by this column.

resetFormData() {
  this.formData = {
    creatorPro: null
  }
  this.queryPro()
}

Query Button

The existing API call is extended with the

creatorPro

condition; the SQL

WHERE

clause receives an additional

AND creator_pro = ?

predicate.

Reset Button

When the reset button is clicked,

resetFormData

sets all fields, including the new one, to

null

and re‑executes the query.

Backend – Fuzzy Search for Work‑Order Group Member Names

Requirement: change exact name search to a fuzzy

LIKE

query.

Modify the SQL

WHERE

clause to use

LIKE concat('%', #{name}, '%')

.

Bug Analysis

The original code caused pagination bugs: only the first page returned results, later pages were empty.

Investigation showed the

LIMIT

clause started at offset 10, so when the total result set was less than 10 items the query returned nothing.

SELECT p.id, p.province, p.city, p.employee_code, p.employee_name, p.org_id,
       (SELECT INSERT(p.employee_phone, 4, 4, '****')) AS employee_phone,
       p.type, p.state, p.isValid, p.creator_id, p.creator, p.create_time, p.update_time
FROM employee_pro_10096 p
WHERE 1=1 AND p.employee_name LIKE concat('%', '运维01', '%')
LIMIT 10, 10;

The calculation of

startRow = (pageNo - 1) * pageSize

was incorrect for the second page, causing the offset to skip the first ten records.

Fixes applied:

Corrected the start‑row calculation and ensured

pageNo

is properly passed from the front end.

Adjusted the boundary condition to use

>=

when

(pageNo * pageSize) >= itemCount

, resetting

pageNo

to 1.

Final Thoughts

After the fixes, the fuzzy search returns the correct number of records across all pages, and the reset button works as expected. The project’s tight coupling prevents using PageHelper directly, but studying its principles can help understand the differences.

Author: 柳~

Source: https://www.cnblogs.com/zhiliu/p/18319813