I started learning Tryton recently. I have to say that it’s no easy to start but if you are patient and you dig in the forum, documentation, code… you can find answers.
I’m trying to build an internal tool that uses Tryton as headless-erp?, web-framework?, erp-framework?.. I don’t know how to call it but basically the idea is to take advantage of what Tryton already offers (much more of what I need) and create a simpler user interface adapted to mobile screen, that uses few modules like Party, Products and Sales. This would be used by non-technical users and the regular tryton-desktop client for the most advanced ones.
My approach is based on flask_tryton but I’m not sure if it’s a good idea since I saw that there were already similar attempts before:
I know that there are integrations like Vue Storefront (not exactly what I’m looking for) but I would like avoid JS due to the fatigue and use simpler (old school) solutions like unpoly or htmx
So… what do you think? Is it worth it to continue or should I look for a different approach?
Hello @Joans,
welcome on board! Good to have you here.
Did you try Sao, - our web-client, - on a mobile screen? E.g. Tryton
You can use the access permissions to limit the non-technical users. You can simplify/specify the functionality with additional custom modules. The sao webclient can be easily tweaked to your taste with a custom.css file. And of course Sao can be improved.
The name of headless erp is called Tryton server, or trytond for its technical name.
The name of an internal tool that uses Tryton as headless-erp is called Tryton client. Existing clients are tryton, sao and proteus.
If your application does more than using Tryton server, then it is called a Client application.
First approach with Tryton is to provide users with the menus and forms they need and nothing more. It is a matter of configuring access rights.
I think it is a good idea to create a specific interface for specific users. For example, if disabled people cannot read and click with a mouse, then repeatable tasks may benefit from a dedicated interface on a dedicated touchscreen.
I think it is not a good idea to simplify Tryton interface for a "standard’ user, because using an ERP through a simplified interface is more complex than using the standard interface. I made a lightning talk on this at Tryton Unconference http://brochures.sisalp.fr/case%20against%20UI%20customisation.pdf
If you want to have a mobile frontend you may be interested in this talk:
Here I explain how to build offline applications connected to tryton.
If you want to have an online application its easier to just plug directly to the tryton API or even use custom routes.
First of all, thanks all of you for your comments.
Let me try to answer…
Yes, I was aware of SAO. I’ve played a lot with the demo It’s great that it can be improved but, in my opinion, I believe it’s not meant for non-technical users (at least not for mine)
Thanks for the clarification. It seems that “Tryton client” were the words I was looking for.
Interesting… I was not aware of that resource. Was the talk recorded? I would like to have some context for some of the slides.
To be honest, I feel a little bit overwhelmed for all features, modules, possible customization it offers, that’s why I try to start simple.
My intention is not to re-invent the wheel and try to create my own UI but instead to use it to learn the internals of Tryton and in parallel to help the non-technical users (there are 2, potentially 3) to start. The clients SAO & tryton-desktop will be there, but not for everybody since the beginning.
I already manged to create an small “Tryton Client” proof-of-concept based on Parties and Products. I’m happy with the result, and it was useful to learn the internals of Products & Products-Templates, for example.
But now that I saw that there are plans to replace flask-tryton with REST API for user application I suppose that’s the path I should follow instead.
If you have any other Idea or recommendation, I’ll be happy to read it.
In this talk I explain how you can use flask tryton to have a web app on top of tryton.
Yes, I guess the future is the REST API but there is an intermediate path that you can use now and that we use for simple web applications (like yours). You can create custom routes on a modules that will be server by the tryton web server. This can be used to create an API (for example like the timesheet api used by chronos)
The routes can be used to create an API for scratch or even to server the HTML page directly.
Once you have it setup, it a mather of give the custom URL to the users you want to use the application and give the tryton client to the full users of the system.
I am exploring the possibility of creating a web client for tryton using (Remix) which will communicate with tryton backend in a simpler REST-like manner rather than through JSON-RPC.
I imagine this will allow us to create our own simpler and customized web UX/UI and extend it when we add additional custom tryton modules in the future in an easier and faster way.
User Application is a way to identify with the platform but you will need to define the routes on the server. The intermediate path is defining your routes, no mather which autentification mechanism you use for the users.
Well you should keep in mind that although the Tryton models can be used as-is (ie there is validation of the input and so on), when a Tryton module is developed it’s done by assuming that the client will behave some ways.
As I said those assumptions are only done in order to make the process for the user smoother (from the data pov, everything should be OK) but those thoughts are there though.
So by using your own UX/UI, you will gain some stuffs but might lose also others.
Of course, it’s your choice and you’re free to do whatever you would like but I maintain a fork of the Tryton client with custom widgets in it and it has been a PITA sometimes. I am saying this just so that you know what you are getting into .
Personally I’m using EmberJS which directly connects to Tryton using JSON-RPC. Basically in the same way how both clients work. In that way I created a planboard so the users in the field can see what’s coming and the users in the office can plan the user very easy by dragging-dropping the items.
Also, together with CapacitorJS I created an Android app specifically for the users in the field. The interface of the app only shows the needed data and is touch friendly.
Everything is directly connected to Tryton, but the users in the office are still using the default Tryton desktop client to have the complete overview.
It’s great that it can be improved but, in my opinion, I believe it’s not meant for non-technical users (at least not for mine)
.