And you forgot to add that someone is going to use and test it in PRODUCTION
[New Feature Proposal] Doctype Variant: more user friendly scenario specific user interface (form view) and permission control for complex process
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)
[v12] Permission Bug
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.