Alpha testers wanted: scoped Project/Task access with restricted Task workflow

dntrplytch · September 6, 2026, 8:32pm

I’ve released v0.1.0-alpha.2 of a small open-source ERPNext app called ERPNext Project Access, and I’m looking for testers and—equally importantly—feedback on whether I’ve overlooked a simpler native ERPNext approach.

The use case came from a real ERPNext implementation: we wanted Projects to be visible only to their owner or explicitly selected users, while allowing an assigned Task to be visible independently of its parent Project. We also wanted a restricted worker to move an assigned Task through a small workflow without granting broad Task Write permission.

When enabled, the app adds an owner/explicit-DocShare scope fence to standard Project and Task permissions. The controlled Task flow is:

Open → Working → Pending Review

The Task owner can then either return it to Working or complete it.

Alpha.2 is deliberately safe-by-default: a fresh installation is disabled. Installing the app does not change Project or Task access until a System Manager explicitly enables ERPNext Project Access Settings. Disabling it again makes the app’s permission hooks neutral and removes the controlled actions.

I’ve now tested two environments:

A clean automated smoke install on Frappe 16.33.0 / ERPNext 16.34.1, covering fresh installation, disabled behavior, activation, and the permission-query fence.
A full worker/reviewer workflow on our reference deployment with Frappe 16.29.0 / ERPNext 17.0.0-dev.

The stable-v16 result is intentionally described only as a smoke test; I’m not claiming broad version compatibility yet.

Release:
https://github.com/dntrply/erpnext_project_access/releases/tag/v0.1.0-alpha.2

Documentation:
https://github.com/dntrply/erpnext_project_access

Tester feedback / native alternatives:

github.com/dntrply/erpnext_project_access

Alpha.2 tester feedback and native-ERPNext alternatives

opened 03:22PM - 06 Sep 26 UTC

dntrply

`v0.1.0-alpha.2` is ready for outside alpha testing. Release: https://github.co…m/dntrply/erpnext_project_access/releases/tag/v0.1.0-alpha.2 The app is intentionally passive on a fresh install. A System Manager must explicitly enable **ERPNext Project Access Settings → Enable ERPNext Project Access** before the owner/share access fence and controlled Task workflow become active. ## What would be most useful to test Please include your Frappe and ERPNext versions and whether the site is new or already has Projects/Tasks. - Fresh install leaves Project/Task behavior native until explicitly enabled. - Enabling restricts non-Administrator Project/Task scope to document owner or explicit user-specific share, while normal role permissions still apply. - An assigned/shared Task can remain accessible while its parent Project is private. - A restricted active assignee can use `Open → Working → Pending Review` without general Task Write permission. - The Task owner can use `Pending Review → Working` or `Pending Review → Completed`. - Disabling the app returns its permission hooks to a neutral state and removes/rejects the controlled actions. ## Compatibility already exercised A clean install/activation/query-fence smoke test passes on: - Frappe 16.33.0 - ERPNext 16.34.1 - MariaDB 11.8 - Redis 8 The complete worker/reviewer workflow has separately been exercised on the JSS reference deployment with Frappe 16.29.0, ERPNext 17.0.0-dev and HRMS 17.0.0-dev. The clean stable-v16 result is a smoke test, not a claim of full workflow certification across ERPNext v16. ## One question I especially want feedback on If ERPNext/Frappe already has a native configuration or workflow pattern that provides this combination of: 1. Project visible only to owner/explicitly selected users, 2. Task independently visible to an assignee even when the parent Project is private, 3. assignee allowed to perform narrow Task-state transitions without broad Task Write access, 4. reversible activation without replacing the standard Project/Task DocTypes, please point me to it. A simpler native approach would be preferable to maintaining custom code where it already exists. Bug reports, permission-model edge cases, upgrade observations, and suggestions for a better native design are all welcome.

I would especially appreciate feedback on this question: Is there already a native ERPNext/Frappe configuration that provides this combination?

Project visible only to owner/explicitly selected users.
Task independently visible to an assignee even when the parent Project is private.
Assignee permitted only narrow Task-state transitions rather than broad Task Write access.
All of this without replacing the standard Project and Task DocTypes.

If there is a cleaner native mechanism, I’d much rather learn about it than maintain unnecessary custom code. Otherwise, reports from other ERPNext versions and real permission setups would be very useful while this is still alpha.