Skip to content

Releases: dntrply/erpnext_project_access

ERPNext Project Access v0.1.0-alpha.2

Pre-release

Choose a tag to compare

@dntrply dntrply released this 06 Sep 14:51
022df2b

Second alpha release of ERPNext Project Access.

The main change in alpha.2 is safer activation behavior: installing the app no longer automatically activates its Project/Task access policy on a fresh site.

What changed

  • Added ERPNext Project Access Settings.
  • Fresh installations start disabled.
  • A System Manager must explicitly enable the access policy.
  • While disabled:
    • Project and Task permission hooks remain neutral.
    • Native ERPNext/Frappe permissions determine visibility and access.
    • Controlled Task workflow actions are not exposed.
    • Direct calls to controlled Task mutation endpoints are rejected.
  • Existing alpha.1 installations remain enabled when upgraded to alpha.2, avoiding an upgrade that unexpectedly broadens access.
  • Settings warnings describe the consequences of saving either the enabled or disabled state.

Access model when enabled

  • Project access is additionally restricted to:
    • document owner, or
    • an explicit user-specific share.
  • Task access is independently restricted using the same owner/share model.
  • An explicitly shared Task can remain accessible even when its parent Project is private.

Controlled Task workflow

Worker actions:

  • Open -> Working
  • Working -> Pending Review

Task-owner/reviewer actions:

  • Pending Review -> Working
  • Pending Review -> Completed

These actions allow a restricted worker to participate in the workflow without granting broad general Task Write permission.

Alpha.2 validation

Validated on the JSS reference deployment:

  • Existing alpha.1 installation upgraded to alpha.2 and remained enabled.
  • Activation setting could be disabled and re-enabled without uninstalling the app.
  • Permission-query hooks were neutral while disabled.
  • Controlled mutation endpoint rejected calls while disabled.
  • Worker UI lost the custom action while disabled.
  • Re-enabling restored the custom worker action.
  • Full worker/reviewer workflow succeeded after re-enabling:
    • Open -> Working
    • Working -> Pending Review
    • Pending Review -> Working
    • Working -> Pending Review
    • Pending Review -> Completed
  • A separate fresh test site confirmed:
    • Settings DocType exists after installation.
    • Stored Enabled = 0.
    • Runtime is_enabled() = False.
    • Historical upgrade patch is recorded without changing the fresh-install default.

Compatibility

Validated with:

  • Frappe Framework 16.29.0
  • ERPNext 17.0.0-dev
  • HRMS 17.0.0-dev on the reference deployment

The reference deployment is an intentionally mixed development stack and should not be interpreted as a broad compatibility guarantee.

Frappe 16.29 or newer is recommended because earlier Frappe 16 versions contain a linked-table permission-query issue that can cause an otherwise readable Task to disappear from Task List when its linked Project is inaccessible.

Upgrade note

For existing alpha.1 installations:

  1. Update the app.
  2. Run bench migrate.
  3. Alpha.2 preserves the enabled state.
  4. Review ERPNext Project Access Settings before changing activation.

For fresh alpha.2 installations, the app remains passive until explicitly enabled.

Documentation

See:

  • docs/HOWTO.md
  • docs/ROLE_SETUP.md
  • docs/ACTIVATION.md
  • docs/INSTALL.md
  • docs/INSTALLATION_EFFECTS.md
  • docs/UNINSTALLATION_EFFECTS.md

Status

Alpha-quality software. APIs, configuration, permissions behavior, and workflow behavior may still change before a stable release.

ERPNext Project Access v0.1.0-alpha.1

Pre-release

Choose a tag to compare

@dntrply dntrply released this 06 Sep 05:25

First alpha release of ERPNext Project Access.

This release provides explicit-share-based access control for ERPNext Projects
and Tasks, together with a narrow Task worker/reviewer workflow that does not
require granting general Task Write permission.

Included

  • Project visibility and permissions based on ownership and explicit DocShare
  • Independent Task visibility and permissions
  • Explicitly shared Tasks remain accessible even when the parent Project is private
  • Controlled worker actions:
    • Open → Working
    • Working → Pending Review
  • Controlled Task-owner review actions:
    • Pending Review → Working
    • Pending Review → Completed
  • Normal ERPNext Task validation and completion lifecycle is preserved

Validated workflow

The alpha was exercised end-to-end with a restricted worker:

  • Worker could see and open an explicitly shared Task
  • Worker could not open the private parent Project
  • Worker did not require the broad HR Manager role
  • Start Work succeeded
  • Submit for Review succeeded
  • Return for Rework succeeded
  • Resubmission succeeded
  • Approve & Complete succeeded
  • Completion set Task progress to 100%
  • ERPNext closed the worker's ToDo normally

Compatibility

Validated on:

  • Frappe Framework 16.29.0
  • ERPNext 17.0.0-dev
  • HRMS 17.0.0-dev

The validation environment is an intentionally mixed development stack and
should not be interpreted as a broad compatibility guarantee.

Frappe requirement

Frappe versions prior to 16.29 contain a linked-table permission-query issue
that can cause a readable Task to disappear from Task List when its linked
Project is inaccessible.

Frappe 16.29 or newer is therefore recommended for this alpha.

Status

Alpha-quality software. APIs, configuration, and workflow behavior may change
before a stable release.

Documentation

See the current How To guide for the access model, setup, worker/reviewer workflow, acceptance test, and troubleshooting.

Note: the How To was added after the v0.1.0-alpha.1 tag was created, so it is maintained on main and will be included in the next tagged release.