I’m interested in developing an app for nextcloud. Essentially I am interested in creating a basic Customer Relationship Management (CRM) app. Such an app would be very similar to the Deck app, but instead of a Kanban deck it would be a sales pipeline, each stack would become represent a sales stage, and each card will become a sales opportunity. See Odoo for another open source example of a CRM, you will find tutorial videos for such a CRM like this.
Each sales stage will have a defined probability of success, and each opportunity a potential value. Then one can add logic to produce a value of the sales pipeline by multiplying the values by the probabilities for all stages and summing them up for all stages.
Later I would like to add other functionality, e.g. clients attached to sales opportunities, and clients linked to contacts from the contacts app, and also importing emails from the mail app to opportunities records, that kind of thing.
It seems to me that the best way for me to implement this would be to reuse the existing Deck app code and inherit from it so that I benefit from maintenance and updates to that app. It seems I could inheirit from the card and Stack etc classes in OCA\Deck\Db and other code. Therefore my question is, is this possible, and are there any examples out there of other Nextcloud apps doing this?
I should add that I am a complete beginner in php, some experience of web development generally, but very experienced in OOP in other languages such as python and C++.
I am not aware of any 3rd party app that is using code from another 3rd party app.
In general, you can include code from other apps by use OCA\Deck\.... but these would be very brittle in my humble opinion. Each time the maintainer of the Deck app changes something in his code, you would have to keep track. This is especially true, as the update of the Deck app needs a synchronized update of your app => I would decide against such a structure as it renders the complete Nextcloud unstable at worst.
You could of course fork the app and manually sync any changes into your code base. That is more work from your side in the first moment but will keep everything contained. You have the power over the time of your releases and can test the code before publishing.
Then there is a continuum toward writing an app completely on your own. The more specialized code you need, the more it makes sense to cut off any direct dependencies. I suspect you will come to a point where the Deck’s business logic is more in your way than any useful help.
I do not know what you have in your mind exactly and how this would work internally. I am just not sure if the Deck app is that close to your use case that a fork makes sense.
1 Like
I wouldn’t recommend it.
Other applications don’t have static API for use by other software, so you cannot depend on the next version working the same way.
What I’d recommend you do instead is FORK it. You can then decide which changes the parent project makes that you would like to include in your fork.
1 Like