Thanks, Anyhox, what I’m sseking is more like the presentation (10 slides max) you show to a CIO on why Tryton is superior to a self-developed solution (and maybe some competitors like ERPnext, adempier, dolibar). What are the highlights of elaborated technique Tryton implemented in the 12 years of its existence?! All these “little” things another application would need to implement, while in Tryton it’s already there.
Some background: Some CSAs (community supported agriculture, Solidarische Landwirtschaft) are seeking software solution for their processes. Some of the group are just starting, others are in business already and need a better solution. There is already quite a list of CSA solutions, AFAIK none of which is modular and each one focusing on different aspects. One of the bigger German CSA has a quite sophisticated solution, tailored to their needs. The developer of this solution (1 person plus a helper) is about to reimplement its solution from scratch. IMHO this will end up in another CSA-solution, reinventing wheel over wheel as requirements of CSAs differ. So my aim is to convince the developer to drop its backend and use Tryton instead., leveraging all the sophisticated features and maturity Tryton already implements.
Here are some point I’ve already found to give you an impression of the direction:
- Optimized for distributed transactions
- What exactly does this mean? conflict handling?, low latency?, …?)
- Caching
- Authentication incl. LDAP integration, 2FA (password + SMS), …
- Authorization (RBAC) for Models, single Fields and even single Actions
- Workflows
- Scheduled Actions
- Email notifications and integrated E-mail “client” (← better term?)
- Sending Noifications to connected Clients
- Uses Postgresql
- for tests and development no DBMS is required, sqlite can be used
- Modular architecture (1 module for 1 concept) eases understanding and extending/customization
- works on lines, not on documents ← why is this a feature?
- data historization: if required, just enable for a Model
- Built-in automatic migration mechanism
- International support: Several concurrences, languages, OUMs, … (← not strictly technical, but “core”)
Point I would be interested to learn about:
- Ease of using custom WebUIs, aiming to remove complexity for the users and provide views and workflows more tailored to the user’s tasks.
- Ease of integrating GraphQL-based front-ends (this is what the 1 developer has in mind)