How to improve user involvement in development of ERPNext

Not really.

contributor1/feat-branch is sent as PR to be merged into erpnext/develop branch.

Only one PR can be setup in a bench at a time. contributor2/feat branch is separate repository. Can’t do “bench get-app” and set multiple repos and branches there

1 Like

Thx, Please advise would it possible with our own fork and multiple PR merged into it. Am interested as I want two healthcare-related PR to be merged and want to put in a test environment. Suggest an ideal way to achieve this pls.

We’ve been using Sentry in production systems for about 3 years now, and we have it as a custom app with basic reporting functionality.

For automated instances per pull request, we could look at Github Actions (although the freemium state of this project might be prone to changes) or a more established product like Tugboat, which has a free tier that we can explore. There’s probably more options, but these could be a good start. The biggest challenge we faced with these deployment engines in the past was database management, but I think these products are mature enough now to deal with.

+1 for making this thread, @revant_one

github actions have anything that keeps the instance running? Instance should be deleted when PR is merged?

Following command can build images for the PR branch.

git clone && cd frappe_docker
docker build -t frappe/erpnext-worker:PR-24603 --build-arg=GIT_REPO= --build-arg=GIT_BRANCH=e-commerce-refactor -f build/erpnext-worker/Dockerfile .
docker build -t frappe/erpnext-nginx:PR-24603 --build-arg=GIT_REPO= --build-arg=GIT_BRANCH=e-commerce-refactor -f build/erpnext-nginx/Dockerfile .

We can build such images on chosen PR(s) (Manual Trigger) and run it on tugboat?
Every PR on tugboat is unnecessary.

Also anyone suggest FOSS alternative to tugboat?

Hosting PR images on docker hub won’t be a problem I guess as we delete them after PR is merged.


try images, frappe/erpnext-nginx:PR-24603 and frappe/erpnext-worker:PR-24603

Play with docker is down,

here’s the stack

PWD: Play with Docker


From the technical side, I think a “Try this” button in every PR would be perfect. This would spin up a temporary container where anyone can try the changes.


I’m not 100% sure if GA will give you an instance, but it does let you run playbooks if we wanted.

You can disable automatic deployments, but I think Tugboat requires you to use their CLI tool to trigger builds manually.

Either way, I think we could try a quick test with each of these maybe and see if they’re viable?

i dont know if it is tugboat alternative but this is an interesting open source project backed by y combinator might be helpfull

I got good search results on search keywords “preview environment”.


PWD worked. It installed fresh new site on the given repo/branch combination

I like this idea

Which property management system is it? Would be interesting to develop same for ERPnext

Whoever want to try the ecommerce refactor PR try this.

I rather not say in this forum. I think it is bad taste. But their strategy is not monolothic. They have the base product (like Frappe in our case), then on top of this base product, they have a vertical implementation focused on property management. On top of the same base product, they have another vertical implementation focused on asset management (computers, equipment, etc.) You may install both vertical products in the same installation if you want.

Unlike ERPNext which places all domains (verticals) all in one place so there is no chance for differentiation.

While this is a step in the right direction, it is not really addressing the true kernel of the problem.

As a developer @revant_one you were wise in pointing out that you may have a difficult time understanding the issues from a business user perspective. This effort of yours still requires the “PR” step that is not within the catalog of skills the average business user has at their disposal. They would still be unable to participate in this exercise except to provide commentary on some developers functional PR.

This process does not enable the business user to get their own PR type additions up for consideration. It only enables them to comment on the work of others.

I can see where this might eventually get us to the true point of origin (business users). So to that end I applaud this project for it’s intent and it’s origins. It will be a great starting point.

Thank you @revant_one for having the courage and commitment to help get this underway.


1 Like

Introducing POS Awesome

Seems to have implemented this concept using this thread alone.

PR/Issue is the point where software is built, Forum or Issues do not influence that much once discussions are on PR. The user comments on PR can influence reviewers immediately.

It is the point where user can even completely block the feature or change the direction.
Once the discussion moves to PR, most of it continues there.

Let’s not call it PR. Let us call it “List of Fixes and Features” or “List of improvements”

Following is my imagination:

Step 1:

User visits (Custom Frappe App). and logs-in.

User sees list of features that are coming up in ERPNext.

Step 2:

User clicks on one of the feature “feat: Employee Grievance”

User sees details about a site where the feature is deployed

Here we can either keep the credentials open or give the responsibility of management to site creator and ask users to contact site creator for access.

What is up for consideration is again based on trust and reputation.
Anyone who wish to contribute (major/minor) code needs to know the process of pull request.

I’ve seen people send valid PR(s) that get merged just through user interface.
The branches they send PR from are generally named patch-1, patch-2, patch-N.

PR is the ONLY way to change the code.

Enabling business users to send their contribution is another important interaction. It may also have some part of training, coaching involved and we need more human interaction than code or ui there.

If it is a PR it might get landed up in my “imagined” UI and there will be more “user” eyes on that PR making it candidate to be considered for merge.

For people who can install development environment, switch branches, try out things locally, it can be done using the any mode of developer interaction and trying out the commits the developer pushes. No need of a UI where there is a button to “Try” feature.

For users who can’t setup development environment to try branches and forks there needs to be some way? Because users are always more in number than developers I think there should be easy way.

My “imagination” targets all users who just “use” the system daily. Not developers.


I think I get what you mean. I understand it this way:

bench update for Frappe / ERPNext is limited to the committed pull requests approved by the Frappe team which have been admitted into the official branch (develop).

What you want is to have a Live Demo site updated with the official branch PLUS the unapproved Pull Requests of a selected focus area. This way, the users who do not code but have domain expertise can contribute their inputs by pointing out errors or refinements to the model.


You know what… That is the perfect answer!

Thank you for the clarification. I really like the direction this is going.



looking forward to see it in action.

Hi Team,

I believe this platform has massive potential.

I for one would be more than willing to learn how to code and contribute to the team.

I would say I am a beginner/intermediate at coding in JS/Python/Html/CSS.

I have already watched all the frappe and erpnext tutorial on youtube, but I still feel that it isn’t enough for noob developers to start contributing.

I really think that a full on tutorial such as those you get on Udemy for other frameworks such as Angular or Django, will give the Dev community a massive jump start and will start growing at a massive rate.

If I could learn how to develop and build features for ERPNext, I would of already been contributing to this project.