Adding missing PHP classes #11
Conversation
|
So you are also working with PHP in sommobilitat?? Nice! In theory, php classes should pass the same tests cases than the equivalent Python classes. Do you want the PR to be merge or are you still working on it? |
|
Yes! We plan to use the PHP version of intercoop We are still working on the tests, feel free to implement them if you want to |
|
I have no spare time right now (preparing the HackaSom and working on the
new forms that will accept intercoop users). So go on and keep me informed.
Before proceeding i will do a head ups to avoid duplicate efforts.
Just curious, why the shift from python to php, have you changed your erp,
or it is just that your "portal" is php?
Missatge de Bernat Torres <[email protected]> del dia dv., 21 de
set. 2018 a les 14:56:
… Yes! We plan to use the PHP version of intercoop
We are still working on the tests, feel free to implement them if you want
to
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAge0v90s6AVEsYsspuOV4KlWhLE_H6tks5udOIWgaJpZM4WyH1B>
.
--
David García Garzón
|
|
We'll keep working on the necessary tests and keep you posted about our advance! As we previosly commented, our idea is to use intercoop as the protocol for internal communication between apps. We'll have odoo as our central data repository so, when a new user signs in in our coorporate website (wordpress - php) we'll use it as portal to send registration data to odoo. And we'll use our client area (flask - python) as portal also to retrieve user data from odoo. That's why we need both implementations. I hope this architecture idea makes sense to you :) Thanks for the followup! |
|
Of course that you can use it for whatever you want. It will be good for
the stability that your are using it so intensely.
I am a little worried, though, about the fact that as you are using it for
a different purpose than intercoop, unwillingly, the implementation you are
doing may shift to a design that is not suited or overkill to the main
purpose of the protocol.
Indeed i also wanted to use it for other purposes too, like chrismast
bouchers and member invitations, but all of them was about accessing the
service. If you are using it as generic signed RPC protocol at some point
you will need to extend it. So, just be alert and let's talk if you get to
that point.
Missatge de Daniel Quilez <[email protected]> del dia dv., 21 de
set. 2018 a les 16:11:
… We'll keep working on the necessary tests and keep you posted about our
advance!
As we previosly commented, our idea is to use intercoop as the protocol
for internal communication between apps.
We'll have odoo as our central data repository so, when a new user signs
in in our coorporate website (wordpress - php) we'll use it as portal to
send registration data to odoo. And we'll use our client area (flask -
python) as portal also to retrieve user data from odoo.
That's why we need both implementations. I hope this architecture idea
makes sense to you :)
Thanks for the followup!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAge0gNAcv-2mC7MgakClXCPX4OXM3Kgks5udPOLgaJpZM4WyH1B>
.
--
David García Garzón
|
|
Indeed is going to be used for a slightly different purpose as it was designed but at the end we though our goal (send data between entities) doesn't differ that much from the original idea. We wanted to ask, maybe meet, to see if you're planning to use a completely different approach to implement your internal API of communication between client area and ERP. Would be good if we join development efforts to achieve same goals and try to create tools that can be easily adapted for other cooperatives from the social economy. We'll be happy to use and try to help as much as we can. |
Adding missing PHP classes: