“’Free software’ is a matter of liberty, not price. To understand the concept, you should think of ‘free’ as in ‘free speech,’ not as in ‘free beer’.” -Richard M. Stallman
Further reading: https://en.wikipedia.org/wiki/Free_software
Long-Lived Integration Workflow
When your project isn’t just a temporary contribution but has its own identity (e.g., a “mod,” a “custom flavor,” or a “branded fork”), the workflow shifts from “temporary branch” to “long-lived integration.”
You are essentially maintaining a parallel product while siphoning updates from the original source.
The Branching Strategy
In this scenario, you need two permanent branches that never die:
upstream-main(orvendor): A clean, untouched mirror of the original project. You only ever pull into this branch.
prod(orcustom-main): Your project’s identity. This contains your unique branding, features, and configurations.
The Mental Model
Think of the upstream project as the engine and your project as the car body. You want to be able to swap out the engine for a newer model without denting the car.
The Long-Term Integration Workflow
Step A: Keeping the “Engine” Current
Periodically update your mirror branch so you have a clean base:
git checkout upstream-main
git pull upstream main
Step B: The “Integration” Merge
Instead of rebasing (which is for short-lived features), you will Merge the upstream changes into your custom project. This creates a “Merge Commit” that acts as a historical marker of when you synced.
git checkout prod
git merge upstream-main
Step C: Resolving “Identity” Conflicts
Because your project has its own identity, you will likely have permanent conflicts (e.g., you changed the README.md or the logo.png).
- Keep your identity: Always favor your custom files during the merge.
- Refactor for compatibility: If the upstream project changed a core function that your custom code relies on, you must update your custom code to match the new API.
- 3. 3. Architecture for Easier Maintenance
If you find yourself resolving the same conflicts every month, your project is too “intertwined.” Aim for decoupling:
| Strategy | Action |
|---|---|
| Configuration Over Modification | Use .env files or config objects rather than hardcoding changes into the upstream source code. |
| The “Plugin” Pattern | Keep your personal code in separate directories (e.g., /custom) and hook into the main app via imports, rather than editing the original files. |
| Wrapper Scripts | If you need to change how the app starts, write a wrapper script (start-my-flavor.sh) instead of modifying the upstream Makefile or package.json. |
- 4. 4. Handling Contributions Back
If you develop a bug fix in your “Identity” project that would benefit the “Upstream” project:
- Cherry-pick that specific commit:
git checkout -b fix-upstream-bug
git cherry-pick <commit-hash-from-your-prod-branch>
- Push this clean, isolated branch to your fork and open a PR.
Summary of the “Identity” Workflow
- Mirror the upstream in a dedicated local branch.
- Merge (don’t rebase) that branch into your custom branch.
- Isolate your unique code into separate files/folders to minimize merge conflicts.
- Cherry-pick fixes back to upstream when they are generic enough to share.
Working with webERP
Working with webERP is a soon to be released e-book that will be available on-line for free and a printed softbound book for purchase.
A number of draft chapters are available now (screeenshots are from pre-release v5 webERP unless noted):
1. Configure a company with webERP
Initial configuration before “using” webERP.
2. Manage Parts, Suppliers and BOMs with webERP
Create parts, identify vendor, configure unit-of-measure, create bill-of-materials.
3. Purchase with webERP (80% updated to v5)
Companies need to buy before they can sell. Create suppliers and tax groups. Issue purchase orders, receive stock, pay suppliers.
4. Manufacture with webERP (20% updated to v5)
Create work order, kitting, receive output goods, close work order.
5. Sell with webERP (incomplete work-in-process)
Configure a customer, configure taxes, price lists, basic sales to payment process, reporting.
Understand user security roles, page security tokens, page security levels and in-page security control.
Additional chapters will cover:
- Advanced Manufacturing. Forecasts and production schedule. Material requirements planning (MRP). Purchase materials based on demand.
- Managing Projects. Create projects, forecast labour, enter time and materials, report on cost and schedule.
- Manage Human Resources. Create employees, timesheets, timesheet reports, security roles.
- Financial reporting.
- Customizing invoices and purchase orders.
- Custom reports.
If you find this information useful, please say hello using the contact form and introduce yourself in a post to the webERP project forum. The community would love to meet you!
webERP User Permissions
Click to search for other posts here on webERP
It is important each user has their own login with a password only they know. Also, each user must be assigned a suitable Security Role which allows only those operations within their scope of work to be performed. This is especially important if you will be using webERP in a regulated or controlled environment.
The default (out-of-the-box) user permissions and security configuration will generally be sufficient to get you started. Eventually though you will want to create bespoke security roles and token assignments based on the structure, staff and relationships of your company.
The webERP security model is comprised of four components:
- Security Role
- Security Roles are user roles with assigned security tokens (each user role has it’s own security role, and more than one security role can have the same security tokens. The webERP system administrator can edit the default security roles and create additional roles if needed for more selective control.
- Each user (login ID) is assigned a Security Role.
- To edit the Security Role assigned to a user, click [Main Menu > Setup > General > Users Maintenance] and edit the desired user (as a security role Administrator user).
Don’t think of the access a specific user requires to do their job, think of the role or job they perform, and assign it group (a “security role”) and make them a member of it, and then provide the group (the security role) with the necessary access.
- Security Token
- Security Tokens are used by webERP to control access to a page.
- A Security Role is assigned one or more Security Tokens.
- To view or edit the Security Tokens assigned to a Security Role, click [Main Menu > Setup > General > Access Permissions Maintenance] and edit the desired role.
- Page Security Level
- Each webERP script is assigned a Page Security Level, which is a Security Token a user must have to be given access to run the script.
- To edit the Page Security Level, click [Main Menu > Setup > General > Page Security Settings] and edit the desired page.
- In-Page Security
- Pages (scripts) control the data, buttons and links presented according to any or all of the Security Tokens assigned to the Security Role of the user.
Users and assigned Security Roles
Default (out-of-the-box) Security Roles
- Accountant
- AP Clerk
- AR Clerk
- Inquiries/Order Entry
- Manufact/Stock Admin
- Purchasing Officer
- Customer (login only)
- Supplier (login only)
- System Administrator
SCC Employees and Security Role
The following organisation chart shows SCC employees with their assigned security role.
E.g. Miquel DeLazes > Security Role: Manufac/Stock Admin [Main Menu > Setup > General > Users Maintenance]
Security Roles and Security Tokens
Miquel Delazes, by being assigned the role “Manufact/Stock Admin”, is given security tokens 0 (Main Index Page), 1 (Order Entry/Inquiries customer access only), 2 (Basic Reports and inquiries with selection options) and 11 (Inventory Management and Pricing)
To create or edit a user Security Role: [Main Menu > Setup > General > Access Permissions Maintenance]
Examining the security role “Manufact/Stock Admin” shows which Security Tokens are assigned to Miquel Delazes through his Security Role “Manufact/Stock Admin”.
In his role as “Manufact/Stock Admin”, Miquel will need to search, create and edit Items, which is accomplished using the “SelectProduct.php” script.
E.g. [Main Menu > Inventory > Maintenance > Select an Item] and click [Seach Now].
Access to the SelectProduct.php script is controlled by the Page Security Level.
Page Security Levels
To view or edit the page security levels (aka script security levels), click [Main Menu > Setup > General > Page Security Settings].
It can be see that the SelectProduct.php script (aka page) has been assigned “Basic Reports and Inquirires with selection options”, which is assigned to the “Manufact/Stock Admin” security role assigned to Miquel as we saw previously.
In-Page Security
A page itself can restrict access and fine-tune security role, security token assignment and security level script assignment.
For example, examine the SelectProduct.php script. User Miquel will not be shown pricing, supplier purchasing or cost information because his “Manufact/Stock Admin” security role does not have Security Token 12 (Prices Security), Security Token 9 (Supplier centre – Supplier access only) or Security Token 18 (Cost authority).
