I agree with you, we can keep the main/base doctype as a central place for database table definition and business logic, other doctype variant is purely for different presentaion/view and authorization control(filter on record level, hide, read only , mandatory on field level) .
As I promised, if there is enough interest and feedback from the community member, I can submit the PR soon.
[New Feature Proposal] Doctype Variant: more user friendly scenario specific user interface (form view) and permission control for complex process
I’m interested . A great side effect of something like this is that we move away from having to write a lot of code in controllers to change presentation of a document based on specific field states and move towards achieving this same behaviour with configuration of variant doctypes. Less code. More value.
This would be very beneficial to all… hope to see it contributed soon
Any other community member like this proposed feature? or has any other comments?
I would like to see at least 5 LIKES before start the PR:smiley:.
Still one more LIKE needed to start the PR,
Are you going to implement it in some existing doctype too? Because that would be nice.
this feature is for creating existing doctype’s variant.
So, there is actually no doctype that will use this “as default”? Like, there is no “doctype’s variants” in the core of ERPNext?
Yes, this feature only enables end user to base on standard doctype creating his/her own doctype variant for specific business scenario, there will be no out of the box standard doctype variant after installation.
I do can offer an real user case!
I do have some customers that have Roles involved into the Sales Order
The Sales User is allowed to create the Order, by is not allowed to apply Order Discounts, but can apply discounts into the Items.
The Sales Manager, only is allowed to review the Order and Apply discounts on the grand total, on cases where it’s needed.
For Review, the Sales Manager only needs see (Customer Info, Address Info, Totals and Discounts)
The accounts User, needs also the same information of the Sales Manager, with the difference that him will attach the commissions for the 2 past users involved into the transaction, so Accounts User, can see Sales Team also, that is not allowed by the Sales Users and Sales Manager.
It’s a simple case, but I think It’s enough to offer one real Business Case.
I have been looking at this feature for long, especially in Payment/Receive and Stock Entry. It is difficult to make some users understand this One Doctype for many activities concept when some doctypes are used for operationally very different functions by the business
And you forgot to add that someone is going to use and test it in PRODUCTION
Updated, thanks for your reminder.
I believe quite a few of us work with other ERPs where this is standard functionality in some shape or form so I think that if there is someone willing to pay for this or spend their time implementing it we may not insist on having a paying customer. Some of these gaps actually make it difficult to get some serious customers to adopt. It should be enough that someone is willing to contribute it and that the feature makes sense. If it makes sense and doesn’t break any existing functionality then it should be accepted on its merit.
Use cases are myriad and we haven’t even considered it’s application in child tables.
For example, in a Journal Entry scenario, we can have different fields in the item child table editable/visible depending on the content of a specific field (out group of fields). Not all the fields that apply when posting to a supplier account apply when posting to a P&L account.
@szufisher To achieve this the doctype variant can have an optional field that captures a condition to be met in order for the template described by the doctype variant to apply. Any change to the field referenced in the condition triggers a check to see if the condition is met and if so, applies the correct template to the field.
I had this chat with @szufisher personally, but putting it here for the public record.
- Any feature built without direct customer feedback and UAT is usually half baked, as no matter how experienced a developer is, there will be edge cases that will be missed, and use cases that will be missed all together.
- There are issues that only show up in production.
- There are issues that only show up at scale.
- We have worked with close to 1000 customers now without having the need of this feature (we do have field-level permissions to hide fields selectively)
- There is just too much maintenance headache to accept a mid / large feature without guaranteed maintenance (from a paying customer).
- YAGNI - “Always implement things when you actually need them, never when you just foresee that you need them”
Thanks for your time and guidance, I understand your point and support your decision, I will try to fine tuning my solution internally and wait till there is real customer who need this feature.
Point taken Rushabh,
But I think that, since I use ERPNext in my organisation, I probably qualify as a customer who can test it in production
Also, I’m acting here more like a system integrator than a developer and the prospects I talk to need many of these features discussed here (even when they don’t know how to explain it clearly)
Hi @szufisher, I am really looking forward for this new feature as I am struggling with the existing user permission setting. I am not a programmer but how can I help?
if you are hosting ERPNext locally and you have total control of the server, you can hire a developer to adapt my code( available in this PR https://github.com/frappe/frappe/pull/7946) into your server, and testing it, after test you can move it the your production environment and help to prepare documentation about your real business case, then we have chance to apply review the PR by core team.