[Shared Development] Document Management and Git Version Control for Files inside ERPNext

Hey guys. We are currently working on a full Document Management system for ERPNext and version controlling files within ERPNext by implementing our own python client within.

So I have a brief explaining the project below. Please write me at d.ottenbreit@eso-electronic.de if you want to contribute to the development of this so we can get it out fast and so we can make the app amazing and the code bullet proof. Once this is tested it will be released to Open Source.

I would like to assign a developers to this and I would like to ask if you would be willing to contribute financially to this development. Please contact me at d.ottenbreit@eso-electronic.de if you want to sponsor this development together with us.

So here we go:

Introducing Document Management through FileTypes and Git Version Control


DocTypes are an excellent way for storing structured information. However in business there is also the need for unstructured data to be stored safely, revision-proof and with proper access rights handling. Just think about resumes of your employees or supplier questionaires you recieve from potential customers.

But it doesn’t end there. When building complex products companies typically have instruction manuals that go with the item or documentation on how the item is built internally.

Currently the only way to store this information is by adding it as an attachment to a DocType showing up in the sidebar or in an unstructured way in the File Browswer. While this is a good concept for things like a picture of an employee or item or email communication transmitted through the Support Issues it lack the structure, versioning and access rights handling wanted for enterprise document management.

This is why we are introducing the concept of FileTypes

What are FileTypes?

Files can typically be put in a category, so much like a DocType describes the class of an entity the FileType is the same level of abstraction.

FileTypes are always in a 1:N relationship to DocTypes meaning a FileType is only linked to one DocType while a DocType can have multiple FileTypes.

This is important because the logic of DocTypes being the way information in structured within the App and within the individual company is not supposed to change. FileTypes are not supposed to compete with this structure but to compliment DocTypes by storing this unstructured or semistructured data in a safe way.

Example without Version Control

Assume you have to store the following files of an Employee:


FileType Mandatory Multiple Version control
Resume… Yes … No … No
Diploma… No … Yes … No

This means that whenever you wanted to create an Employee you would have to upload the employee’s Resume because of Mandatory = True. However you would only be able to upload a single file because of Multiple = No. This file would not be under version control so it coulr be replaced or changed without tracking those changes.

The Diploma behaves similarly, however people could have multiple diplomas which is why Multiple = Yes would allow multiple FileTypes of one type to be uploaded to one DocType.

Example with Version Control

Assume you have to store the following files of an item:


FileType … Mandatory Multiple Version control
Instruction Manual … Yes … Yes … Yes
Manufacturing Documentation Yes … No … Yes

Whenever lets say a designer or engineer makes a change to the Instruction Manual or a Manufacturing Documentation you would want to track those changes under Version Control.

The way this works is by the user working with a Git client or by using the ERPNext integrated Git client. To use the internal Git client the user Downloads the original file, makes his or her changes and pushes (uploads) the new file to the server. When uploading something that is under version control a commit message is mandatory.

The history is visible in ERPNext for every version controlled FileType and changes can be undone (jumping back to previous version).

Permissions in Git

Permissions can be set by Role for each FileType by giving no access rights, read rights or read / write rights.

FileType Browser

In order to quickly access FileTypes the user can find them in the DocType entity but can also use the FileType Browser. This browser is a tree browser that is structured by DocType > FileType > Entity. Access rights within the FileType Browser follows the Git permissions as set in the DocType setup.


This is an interesting addition that I think would be very useful. I’m a bit confused about why you’d choose to use the git client to upload instead of sticking with the current system of file uploads. It seems like an unnecessary complication to the process, but maybe I’m misunderstanding?

Also, I’m curious how you would handle amended documents that are related. For example, you might do an assembly document connected to a BOM. If I create a new BOM revision, can that be connected to the same FileType file as the previous rev, or do I need to load a new one?

Hi Dominik

Let’s see what we can do now.

Rob @RobertSchouten, what do you think?

@dominik I think the best way would be to extend the existing File doctype

Lets start small. What is the #1 feature you need in the existing File doctype? Versioning?

We can:

  1. Add a property in File to save versions
  2. Add a property in File to identify, if this file is an original or a version.
  3. If File is versioned, define the steps to upload a new version (same filename?)
  4. When a new version is updated, then make a new File record for the old version
  5. Ability to view versions of a file within the File doctype
  6. Ability to delete old versions, set rules on how many old versions should be kept

Added this:


@dominik @IAGAdmin anyone taking ownership to check if the specs are okay?