My job for over 30 years was to find the best IT solutions to business problems given - time, cost, quality. Always considering the factors of “vendor-hype”, “regret”, “fail-fast-exit” and “developer-availability”
I choose Linux over Microsoft server tech way before GC/AWS
I choose Magento e-commerce open-source over expensive property platforms
I choose WordPress over expensive CMS systems
I did not always choose open source. There many are times when paid solutions/vendors were the best options.
Frappe has a chance to be the next Magento/Wordpres in its domain ( Linux is in a different class ). That’s why I invest time in it.
SAP/Netsuite/Dynamics are all super polished ERP lego boxes. Have implemented them all. They can do anything but the true cost is in the configuration and customization. Consultants are $1000/day in western countries. Frappe has a chance of breaking/disrupting this. But - Toyota didn’t break into the market by building cars with terrible paint jobs. Look/feel matters, reliability eventually built reputation but that is not what won initial market share.
These forums get a couple posts a week of the format, “ERPNext will be the next superbigthing if somebody (other than me) does X”.
I’ve never personally noticed problems with listview column alignment or rollover text, but if I had there’d be a pretty clear pathway forward. In open source, you vote with pull requests.
peterg - I have sent simple pull requests under username “ollyboy”. Also have had 2 two bugs fixed in config and charts that I identified and documented as per guidelines. My skills are not strong enough to find/fix the UX issues I submitted. You seem to indicate that these would be easy for you to fix, would be useful if you could comment on the actual issues and provide some hints/advice. I am prepared to put the effort in, was hoping for some help/guidance from this forum.
Can you give some more details , possibly with screenshot?
I worked with SAP almost 20 years now, I like open source and love ERPNext so much, tried to migrate some SAP features to ERPNext, unfortunately some of them not accepted into core due to different reasons. anyway, let us try our best to improve ERPNext together.
That’s great, and you’ll find both the community and the maintainers very supportive if you lead with that mindset of pitching in.
I’m definitely not saying it would be easy for me to fix. The nature of the problem isn’t clear to me, and even if it were I’m only beginning to feel comfortable in Frappe’s complexity. That’s part of the challenge here: fixes that seem very simple often have very unexpected entanglements. I saw that you posted on github, for example, about how fields respond to change versus defocus. I agree completely that the way things work right now isn’t ideal, but because of the way that Frappe’s event architecture works I suspect that it’s not a simple fix.
As for the specific issues you’re highlighting here (column alignment and rollover effects), I’ve never noticed anything myself. If you post steps to reproduce and some pictures like @szufisher suggested, I’ll certainly be interested to take a look. That said, with the new UI coming out in V13, I wouldn’t blame the maintainers if they were reluctant to spend much energy in this direction.
Sounds good.
Please share the version you tried, tested and presented to the client.
Did you do a detailed testing before the presentation?
Can you share the link to the pull request?
Giving detailed information in a post is the key to having good collaboration with the community members. In open source we should not always rely on the core team.
Appreciate that you have made a pull request but we do need to push it many times to get it upstreamed.
Example: customer ledger summary report is broken since long time in v11 my developer pushed it upstream as hotfix. Its been few months and it’s still not merged. Today after updating my clients server I had to manually fix that report. So yes sometimes it can stay there for long time until pushed multiple times.
I cannot blame core team coz they have their own responsibilities to fulfill.
I agree that erpnext/frappe gave potential to replace Sap/dynamics etc. But it is an open source project and the core doesn’t really earn much.
Let us work on the bugs together. We have been deploying Erpnext since 4 hours now and have done more than 30 medium size deployment, many people have told us the our UI is not good but that have never demotivated us to promote erpnext.
People will have their opinion but it all comes down to how much they’re ready to pay.
You can give more presentation on Erpnext and see what others in your region have to say about it.
Update: I see you Raise multiple issues here most are not bugs but deployment faults which have nothing to do with frappe hence they might have been ignored and one is tagged as feature request which is not so easy to do for the whole project just because one person doesn’t like it.
I hope you’re aware the its a open source project and any chance you want should be catering to general use case and not just one person point of view.
I also see a pr here it seem to have failed since ci test hence now merged.
If you need those changes then you can take full course on erpnext and frappe and create an app that will overwrite all those points that you raises issues for, that way it will be faster for you instead of waiting for the core team to accept the pr.
List view is such a fundamental component of frappe, this will be a great improvement. It’s crazy we can adjust the column widths in the child list view but not in the main list view.
You are correct about pull-requests, they are obviously prioritized way above “issues”. Got one of mine approved into dev branch yesterday, only a few days after submitting. ( It to was a one-liner after review )
Great initiative @peterg
One of the most irritating part is the reports frame section. The vertical and horizontal scroll bars are within frame which rests within browser scroll. It would be great is the height is adjusted so that only browser scroll bar is used. Max rows per view is 9. To view further the frame scroll bar has to be used. Keyboard arrow keys move the whole page, not the frame which keeps displaying 9 rows. Am not sure how the width can be adjusted as there can be many columns that can’t be fitted in screen. For a client we have been trying to get it done but no success as yet.
Fixing it will surely help users quickly scroll up and down either with mouse or keyboard.
This I have observed is few V12 instance. Some V12 work fine with one click, others don’t do anything until Save button is clicked 2nd time. Have a hunch that it’s more to do with server response than the software. Maybe what I think is not true and there is some error in code.
Indeed, and the same issue comes up under some circumstances in list view as well. I tried to dig into it once but it wasn’t a trivial fix. There are a number of different max-height directives in the CSS that conflict with each other, and it’s hard to pinpoint where exactly different constraints kick in for different data loads. I intend to give it another dive, but I’m waiting for the new UI to land on v13 beta.
I think something is catching the click event in javascript, actually. I haven’t been able to explore too deeply, but in any case if you throw a click handler on .primary-action it triggers the second time you click but not the first. I suspect there’s something that gets triggered by a defocus event that’s interfering, possibly in a race condition (which would explain why it happens sometimes but not consistently). I’m able to reproduce on v13-beta, fwiw.
Muzzy, check my extra comments on the issue for the two-click save problem, it only happens if the user edits a text field without field exit, drop-down boxes select boxes all work fine as one-click save. The appearance of the “not saved” status to me indicates the javascript is aware changes have been made, the fact that it does not appear as you edit a text field is a giveaway. Don’t you love/hate good testers, they pinged me on this within 10mins of app review.
peterg - Maybe the javascript event being monitored is not full scope, I think the event that frappe monitors for “ready to save” is not triggered by simple text edit in text field. As soon as user tabs or mouse to another field frappe says “not saved” as status, here it knows/assumes there is form data change. If not saved is status is current state then record save always works with one click
Right, that’s by design. It would be undesirable for Frappe to bubble up a field change event on every key stroke. Defocus is probably the right time to do it. What’s unexpected here is the need for a double click on save. The first click triggers a defocus event, as it should, but then the click event itself gets lost.
