How to setup Disabled/Enabled checkbox for a custom doctype so that api will not release the data?

ERPNext
1

I have a custom doctype. This doctype is saving data into the database. Like the name of rooms.

I have tried creating Disabled and also tried creating Enabled check field in the doctype. It does show up in the list view at the status column.

But when using postman to get the data, I am still getting the rooms with Disabled=1 or Enabled=0.

The url looks like this in postman.
https://erpnext.example.com/api/resource/Rooms

What am I missing? What else need to be done?

using the following versions

Frappe Framework: v15.126.0 (version-15)

ERPNext: v15.124.5 (version-15)

2

After searching in google and some ai chats with duck.ai and gemini, it seems that the disable/enable does not affect api calls.

If using api, then have to set a filter to exclude the disabled.

https://erpnext.example.com/api/resource/Rooms?filters=[["enabled","=",1]]

Something like that. Seems to work but I do not think it is very secure.

Then again, I am not an expert. :slight_smile:

Please share your thoughts and advice.

3

The enabled checkbox alone won’t restrict API access. Adding filters=[["enabled", "=", 1]] works for filtering resultsbut the API caller can remove that filter

If you’re using a custom Frappe app, I’d suggest handling this through server-side permission hooks.

In hooks.py

permission_query_conditions = {
    "Rooms": "my_app.permissions.rooms_query"
}

has_permission = {
    "Rooms": "my_app.permissions.rooms_permission"
}

Then in permissions.py:

def rooms_query(user):
    return "`tabRooms`.`enabled` = 1"

def rooms_permission(doc, user=None, permission_type=None):
    if permission_type == "read" and not doc.enabled:
        return False
    return None

permission_query_conditions filters permission-aware list queries, while has_permission helps prevent direct access to disabled recordsOne thing to watch out for: frappe.get_all() and custom APIs that bypass permission checks won’t be covered automatically.

I’d test both /api/resource/Rooms and /api/resource/Rooms/<room_name> with a regular API user to confirm the behavior.