it was mentioned in the liked topic already … as per by status of knowledge know you make 1 app which contains ALL customization you are doing.
from one angle this appears to me not to be ideal and I would like to find out whether and how it is possible to put every customization (let’s say an extra field in the Employee, or the Customer) into separate Apps. the bid advantage of that method would be that you are very clear about what each little App exactly does and it makes it much more clear (and therefore likely) to share customization’s with others.
For example I’d very much more like install an app that adds a favorite colour field to the Employee (and also is name employee-favorite-color) then install a “someones-customizations-app” to my system. I guess you get what I am going for
I very much agree! People come up with excellent ideas, and the frappe framework is quite easy to work with once you understand the core concepts.
I like the idea of one customization per app but it doesn’t seem like there’s any way to control that. Having a good way to browse apps, and easily install them though could go a long way towards app sharing.
I’m not sure we would see that come from frappe though, they are pretty committed to integration into the main product rather than promoting an ERPNext customisations library. The problem with that is that I believe the community is missing out on a lot of good stuff because people don’t want to spend the time to figure out a pull request or wait for the a request to be accepted and integrated.
your post sounds a bit as if you had knowledge that this (putting 1 customization in 1 separate App) is not possible currently and needed to be developed. Do I understand this correct?
what for sure would work is a manual way. which is not the most convenient method though I guess
create 1 button on a fresh ERPNext system and push that to an App
Oh it’s definitely possible to do 1 customization per app, just there’s no way to ENSURE 1 per app.
I think the thing needed to make it easy and appealing for people is a type of App Store that is easy to push apps to and keep updated, and short concise write-ups on app creation and app store use.
The frappe team is committed to expanding the ERPNext code base, and encourages people to make pull requests to the main product rather than make custom apps with features other people might want. I agree with them, because it means they are committed also to maintaining the code which other developers might not be, BUT, having a great store would also allow them to approach app authors and ask to put it in the main product if appropriate because let’s face it not every customization is good for the base product.
Here are two links to resources that are available now to help with github apps and a place to store targeted scripts.
Maybe enabling more of such Community projects (from single buttons to more complex Apps as the kanban from @aruizramon) would be something the (yet to be to be erected) Foundation wanted to support (a bit similar to what the OCA [Odoo Community Association) does with their github repositories?
I’ve seen multiple times on the forum where someone proposes a customization they need and are building, and the response from the frappe team is that it should be in the base product and can they send a pull request I can’t find them now of course but this thread is a good read too and highlights Frappe’s direction.
Don’t get me wrong, I think merging as much into the base product as possible is a great thing. But I also see the benefits of a healthy app repository for all the things that don’t make sense to have in the base product. It would provide a great place to see what apps are actually available rather than scouring Github, and encourage people to write targeted apps rather than 1 big app with all customizations I think. In the end it could still help Frappe with their “monolith” approach by making it easy to see what others have done and decide what to pull into the main.
thanks, for the link. I guess I'd be on the not-integrating everything side of spectrum n that discussion ...
But this only touches our point here on the side, what we are looking for is rather small adjustments that are not main-stream enough to be build in but still would be used by more then one person, so easy sharing is of a great worth.
Also if you have an App which does only one little thing its very easy to use this for building something you might need which is maybe not the same but similar (other button for other doctype i.e) from such
The problem with small apps is that they quickly start conflicting with each other and there are even bigger problems in maintaining integrity across versions (similar to git vs SVN)
disclaimer: not coming from much technical understanding here but …
… logically I can’t really follow why a favorite color field would more likely conflict with anything else when it comes in a single-button-App compared to having been installed with 20 other custom fields in the same app.
Suppose I am creating a couple of apps. Now I want that each of them should be customizing different default doctypes. But after using fixtures, both will be having same custom fields. How can they be differentiated? How can they have different fields for different apps?