Two more:
- [UX] Show more columns in mobile view
- [UX] Allow to display more columns in list view (like in kanban)
4 Likes
Would be godd to have a swipe to delete function in mobile apps .
Iāve already sent a PR with a first version of GSuite integration.
6 Likes
My WISH is actually quite simple.
I just want to be able to run the ābench updateā command and have it actually update the system to the latest revision. Currently, it generates tons of errors about things being updated that require commit or stash. Then you run into another large list of permission errors.
As an implementer (not a programmer or developer) I cannot understand why I have all of these errors to suffer through to simply update my system. I did not do anything but install the system, import items and customers, then add and configure users. Yet I get all of these errors. I made no program changes, so the errors must have been caused by the install.py program when it was first installed.
So, yes, I have a simple wish that when a release is push out, it should not generate any errors when one tries to update it to the next revision.
Anything less than this is a huge red flag to businesses that want to adopt this as their ERP solution.If the business could afford a developer staff to try to decipher the errors and fix the issues, then they probably could afford a commercial ERP system instead.
At this point I think it is time for version stability. Rather than trying to push out new versions every 2 months, how about making sure a live productions system can easily upgrade from the last version to the new one you release without such headaches.
In order for this project to become the next real viral or killer app, it must become upgrade friendly. Otherwise, people will use it only once to get their feet wet with ERP and then move on to a system that is much easier to maintain. You will have lost them to any future features or improvements simply because they do not want the endless headache of trying to maintain ERPNext with no documented success path to upgrade.
My thoughts.
BKM
8 Likes
I agree with you on the āeasy upgradeā idea.
As of right now, if you are sure that no modification has been done to the files you can use ābench update --resetā in order to reverse al file changes. Keep in mind that if you use the Delevoper mode you might be overwriting some files in the file system.
Regards
Yes I would agree.
odoo upgrades didnt always work, but I dont recall seeing upgrades over a year of use that were broken as fields werent assigned etc.
I think also Iāve seen other times that a git stash or reset is reqd when I didnt see this once with Odoo. Not that they are very good or anything, but agree with the poster that the upgrades break a little too often for comfort (even if a fix is available often soon after)
Regarding comments by @bkm and @Julian_Robbins: Perhaps ERPNext could adopt an LTS strategy like Canonical tries to with Ubuntu. A two-ish year cycle. Opting out means that there are features youāll lose out on and some critical things like security fixes and some bug fixes. But it would make for a more stable environment for customization and likely, a more painful user experience in the LTS upgrade change. Itās a trade off. Personally, Iām a fan of shorter cycles.
Shorter cycles are fine, but only if a true effort is placed into creating the upgrade path for each release that does not result in endless stash, commit, or permissions issues. I am handling these issues in other posts to try to get my production implementation to level up.
So much effort is placed into making a good product, but not enough time is being spent on bringing your user base along with you as you progress the product forward. I just believe that is a mistake in the long run. It alienates system implementation specialists and regular users and limits your loyal following to only the developers and programmers that can figure out on their own where the errors are and how to get around them.
To build a true loyal following, the ability for EVERYONE to level up and follow the product is essential. It does not however mean that you have to stifle progress. It just means adding the the task of testing the upgrade path to the normal workflow of creating a new version. It would be no different than adding continued support for a new module. The work load is about the same.
BKM
2 Likes
If you donāt edit ERPNext / Frappe files directly (which is NOT recommended esp if you are NOT a developer), you should be able to upgrade directly.
If you are so annoyed with stashes, then donāt edit the files. Simple.
1 Like
I think a 3 + 6 + 3 strategy would be better. 3 months to decide / vote (foundation) features in the next version, 6 months to develop them with the support of the community (this is important), and last 3 for the freeze of features, test and stabilization (community help is important again).
We are talking about ERP system, with backups is one of the most critical part of in a company software infraestructure. However, stability and security are more important than a myriad of features.
I would not rule out doing a repository model like Debian:
- main: for the core part maintained by frappe guys.
- contrib: for apps mantained by comunity (important point i think)
- non-free: for pay apps or modules donated by third parties.
I guess you didnāt really read my full posting. You should really read everything before making such inflammatory comments. I did NOT edit any of the files.I did the following and ONLY the following:
- Install a fresh Debian OS on a local server w/no options and no GUI
- Create a single linux user ājmiā (aside from the root)
- log in as jmi user
- Load and run install.py with only the --production switch (no user switch selected)
- Log into ERPNext as Administrator and complete the initial setup
- Created 4 ERPNext users
- Import āItemsā and āCustomersā
- Logged out as Administrator and Logged in as another user
- Discovered a bug in POS module and reported it on this forum
- Waited for the fix to be ready (ver 8.0.22) and attempted to run ābench updateā
- Ran into all of these stash, commit, and permission issues.
My observations:
- Install.py created a āfrappeā directory in the /home directory and installed everything in that directlry. It did NOT use the /home/jmi directory as I wanted.
- While install.py created the /home/frappe directory, it did NOT create the associated frappe user!
- Nowhuere in this scenario did I edit anything!!! I only added data to the ERPNext system. If creating users in ERPNext and setting their permissions causes sensitive files to be edited that might interrupt the upgrade process, then this should be documented somewhere so others do not run into this.
- On the other hand, if this scenario is unusual, then the developers should be looking into the inner workings of the install.py and the creation of users instead of make snakry comments to me about something I did NOT do!!
It is stuff like this that can torpedo a perfectly great package. Implementation people and general users should not have such a hard time using a system. Snarky comments and unhelpful developers does not fair well for a product that could become great. It only gets in the way. I think it is sad.
I am very grateful to those that have been so helpful up up to this point. they are the heros of your package in spite of your own elitism.
BKM
5 Likes
in order to install in your jmi user home you have to run:
python install.py --develop --user jmi
Well, the document I read implied the --user switch was to ācreateā a user during the install process. I had already created the ājmiā user and just ran everything from there with the following command:
python install.py --production
After having so much trouble afterward I found this wjen I looked for the dire4ctlries created:
**********************************************8
jmi@MSD-ERP:~$ sudo -i
[sudo] password for jmi:
root@MSD-ERP:~# ls -la /home
total 16
drwxr-xr-x 4 root root 4096 Apr 22 11:39 .
drwxr-xr-x 21 root root 4096 Apr 22 10:33 ā¦
drwxr-xr-x 7 frappe frappe 4096 Apr 22 11:54 frappe
drwxr-xr-x 2 jmi jmi 4096 Apr 22 11:38 jmi
root@MSD-ERP:~#
root@MSD-ERP:~# ls -la /home/jmi
total 1596
drwxr-xr-x 2 jmi jmi 4096 Apr 22 11:38 .
drwxr-xr-x 4 root root 4096 Apr 22 11:39 ā¦
-rw------- 1 jmi jmi 945 May 10 09:48 .bash_history
-rw-rār-- 1 jmi jmi 220 Apr 22 11:06 .bash_logout
-rw-rār-- 1 jmi jmi 3515 Apr 22 11:06 .bashrc
-rw-rār-- 1 root root 1595408 Nov 6 2016 get-pip.py
-rw-rār-- 1 jmi jmi 10677 Apr 22 11:33 install.py
-rw-rār-- 1 jmi jmi 675 Apr 22 11:06 .profile
root@MSD-ERP:~#
After seeing the āfrappeā directory (knowing I didnāt ask for it to be created) I did the following to search out all of the users in the system (look at what I found):
root@MSD-ERP:~#
root@MSD-ERP:~# awk -Fā:ā ā{ print $1}ā /etc/passwd
root
daemon
bin
sys
sync
games
man
lp
mail
news
uucp
proxy
www-data
backup
list
irc
gnats
nobody
systemd-timesync
systemd-network
systemd-resolve
systemd-bus-proxy
Debian-exim
messagebus
statd
sshd
jmi
redis
mysql
postfix
root@MSD-ERP:~#
Notice that āfrappeā is not listed as a user, but the /home/frappe directory was created. Hence my dilema.
This is probably not the right topic for this set of comments so I would be happy to move it else where if you want. I really just wanted to express my frustration with attempting to upgrade from 8.0.x to version 8.0.22 and to ask for a better upgrade path in the future. This line of comments has gone off topic, and only served to further emphasize my point. It was never meant to hijack the topic.
BKM
BKM
- non-free: for pay apps or modules donated by third parties.
There was some discussion on this as it related to how that failed in the Odoo ecosystem. A customized app seems like a hard thing to monetize beyond a handful of users. Maybe youāve got a great use case, but I think the strength of ERPNext is itās ability to be adapt to unique businesses or unique needs. In my mind that means itās a limited market. There are several custom code shops that have made a business out of extending ERPNext on a consultative basis.
- non-free: for pay apps or modules donated by third parties.
There was some discussion on this as it related to how that failed/ is failing in the Odoo ecosystem. A customized app seems like a hard thing to monetize beyond a handful of users. I think one of the strengths of ERPNext is itās ability to be adapt to unique businesses or unique needs. In my mind that means itās a limited market. There are several custom code shops that have made a business out of extending ERPNext on a consultative basis.
1 Like
i agree with @tmatteson about a LTS it is needed. An ERP system needs to dependable for a business and a major update every 6 months is to fast. Not to mention that for some implementation at a company of good size can take upwards to 6 months to implement. I am considering having a fork for LTS for my customers because without it some of them wont be able to use ERPNext to support their business and that means they will end up using SAP or odoo. In my opinion ERPNext stands a big chance of disrupting SAPs market share and I feel like many here that is just a better system than odoo. I do feel they have a better ecosystem for ad don but that will come in time.
6 Likes
I mean pay applications with modules that connect to payment services like echosign for example.
I agree with the concept of lts but with nuances. The erp itself should be LTS, as I said in the other message, we are talking about software that will manage the entire company, it does not make sense to have versions less stable or without long-term support.
But 24 months in my opinion is too long. I think it is preferable to have annual releases with fewer changes as it would help to stabilize and migrate in production environments.
Another way would be to have a branch of testing or development where anyone who wants to test and evaluate future changes can do so.
In our case we have physical stores and online, we will need enough custom modules, in 6 months can happen as we said before we have a complete migration and proof of a version and there is a new one.
We could make shorter periods of releases if we mix test periods of the current release with the decision of features of the following, 6 (development) 3 (testing v9 and features for v10).
3 Likes
ERPNext must be stable as soon as possible because it is dealing with money and there is no space for any mistakesā¦ or will lose his fans
5 Likes
@meigallodixital That the thing about linux distros like centos/ ubuntu they have releases every 6 months but there is a version that has LTS which we need. The way the release work right now border on the line of fedora which is always bleeding edge. Not so safe for a company.
I guess the main question that i have for anyone is would you use fendora as your server or ubuntu, debian, or centos?