This allow to write callouts on the fly!!!
Without recompiling, rebuilding, nothing, the callouts are written and they just work.
My idea is in future to extend this feature to:
- beanshell process
- beanshell modelvalidator table events
- beanshell modelvalidator document events
- beanshell modelvalidator login event
This will allow complete extensibility without code compilation.
All of this finally thinking to empower implementors to work without IT intervention :-)
Please vote to include it in 3.4 now, or postpone it.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Please vote to include it in 3.4 now, or postpone it.
I forgot to write that BeanhShell scripts could lead to possible security issues.
That's why by default i would like examples to be avoided in core system for now.
Under security issue i mean that beanshell script could return all records, not only records for current user or current organization/Client.
Kind regards,
Trifon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I forgot to write that BeanhShell scripts could lead to possible security issues.
Thats what i heard too.. Perhaps Kontro or Bahman can throw some light. Beanshell was something present in Compiere days. Maybe just make it as sumtin that can be disabled by the client.
+1 to be published early
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> I forgot to write that BeanhShell scripts could
>> lead to possible security issues.
> Thats what i heard too.. Perhaps Kontro or Bahman
> can throw some light. Beanshell was something present
> in Compiere days. Maybe just make it as sumtin that
> can be disabled by the client.
Yep, scripts security are just like java security. It must not be allowed for final users, just for System Administrator - and that's the way how is acting currently.
So, I think it's ok.
Meanwhile you don't allow normal users to edit/create scripts, the security risk is controlled.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with you - instead of calling it AD_BeanShell we can call it AD_RuleEngine (or something similar).
+ Add EntityType (suggestion from Teo)
+ Add RuleEngineType (initially just BeanShell, in future those you mentioned)
+ Add EventType (initially just Callout, in future Process, ModelValidatorEvent ... PayrollConcept
Now, in your example user is adding a script on GardenWorld - currently this must be forbidden (as discussed in this thread).
Script must be allowed JUST to System Administrator. A user on such window can drop a table, or extract the system admin password.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I said we can use column DATA ACCESS LEVEL , the reason is because we need define a Rule to a client or org , the payroll only show the rule create to a Org or Client, but you are in right , we need some way to limit the access. but also need can create rule to a client or org in specific.
A good example is SaaS you would add different business logic to each Entity ;-)
Kind regards
Victor Perez
www.e-evolution.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> As I said we can use column DATA ACCESS LEVEL ,
> the reason is because we need define a Rule to a
> client or org , the payroll only show the rule
> create to a Org or Client, but you are in right ,
> we need some way to limit the access.
> but also need can create rule to a client or org
> in specific.
I don't agree, maybe you can show the script to users, but you CAN'T allow editing of scripts for users. Just System Administrator can edit it.
To allow editing of scripts by users there must be a security layer over the script that I think is hard to achieve.
So, I suppose in an implementation of payroll, the scripts must be defined in System to be used in the different clients/orgs.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> As I said we can use column DATA ACCESS LEVEL ,
>> the reason is because we need define a Rule to a
>> client or org , the payroll only show the rule
>> create to a Org or Client, but you are in right ,
>> we need some way to limit the access.
>> but also need can create rule to a client or org
>> in specific.
>I don't agree, maybe you can show the script to users, but you CAN'T allow editing of scripts for users. Just System Administrator can edit it.
>To allow editing of scripts by users there must be a security layer over the script that I think is hard to achieve.
>So, I suppose in an implementation of payroll, the scripts must be defined in System to be used in the different clients/orgs.
>Regards,
>Carlos Ruiz
My suggestion is that when create this window with DATA ACCESS LEVEL as System let the access to System Administration, but also we need to enable set by client and org.
In the payroll we show all the rules to a client or organization and this depend the Role the user ;-)
can we continue in the FR?
Kind regards
Victor Perez
www.e-evolution.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We should default this as unchecked or not accesible by default except to Admin role. Only when users want it that the chain of accountability in the IT dept allows it.
Since Victor has his own Rule Engine... we try to make his merge without impact from one IT guy (victor) to the other IT guy (carlos) :-)
This marvelous idea of allowing IT guys working independently ala Eclipse Plugin has been the holy grail of ppl like Kontro, but today we see someone who really does it well.
Congratulations and highest regards to Carlos Ruiz and Lady Ruiz :-) <--- the woman behind the successful OS contributor.
red1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi community, I want to ask permission to break the trunk freeze in this special case to include a new functionality:
I have a working patch that implement this new functionality:
http://adempiere.com/wiki/index.php/BeanShell_Callout
[ 1877902 ] Implement beanshell callout
http://sourceforge.net/tracker/index.php?func=detail&aid=1877902&group_id=176962&atid=879335
This allow to write callouts on the fly!!!
Without recompiling, rebuilding, nothing, the callouts are written and they just work.
My idea is in future to extend this feature to:
- beanshell process
- beanshell modelvalidator table events
- beanshell modelvalidator document events
- beanshell modelvalidator login event
This will allow complete extensibility without code compilation.
All of this finally thinking to empower implementors to work without IT intervention :-)
Please vote to include it in 3.4 now, or postpone it.
Regards,
Carlos Ruiz
Hi Carlos,
nice functionality congratulations.
>Please vote to include it in 3.4 now, or postpone it.
[+1] include it now.
Kind regards,
Trifon
Hi,
Best idea I've recently seen! Very good to see.
I don't know if my vote counts, but +1 for immediate inclusion :)
Rgds,
Akos
Hi Carlos,
>Please vote to include it in 3.4 now, or postpone it.
I forgot to write that BeanhShell scripts could lead to possible security issues.
That's why by default i would like examples to be avoided in core system for now.
Under security issue i mean that beanshell script could return all records, not only records for current user or current organization/Client.
Kind regards,
Trifon
Carlos and Trifon!
I think need add the COLUMN DATA ACCESS LEVELl as other AD components I think this solve the issue.
kind regards
Victor Perez
www.e-evolution.com
Very progressive idea! Nice!
>I forgot to write that BeanhShell scripts could lead to possible security issues.
Thats what i heard too.. Perhaps Kontro or Bahman can throw some light. Beanshell was something present in Compiere days. Maybe just make it as sumtin that can be disabled by the client.
+1 to be published early
Hi,
>> I forgot to write that BeanhShell scripts could
>> lead to possible security issues.
> Thats what i heard too.. Perhaps Kontro or Bahman
> can throw some light. Beanshell was something present
> in Compiere days. Maybe just make it as sumtin that
> can be disabled by the client.
Yep, scripts security are just like java security. It must not be allowed for final users, just for System Administrator - and that's the way how is acting currently.
So, I think it's ok.
Meanwhile you don't allow normal users to edit/create scripts, the security risk is controlled.
Regards,
Carlos Ruiz
+1 to include it.
Regards!
Hi Carlos!
We have implement the same functionality but to payroll,we create in AD a new window called AD_RuleEngine
I think that we can join in it same table, so we want can integrate other scrip language or syntax of Rule Engine as JRules
http://www.adempiere.com/wiki/index.php/Rule_Engine_Implementation
What do you think?
Victor Perez
CEO
www.e-evolution.com
Thanks Victor, I reviewed your implementation.
I agree with you - instead of calling it AD_BeanShell we can call it AD_RuleEngine (or something similar).
+ Add EntityType (suggestion from Teo)
+ Add RuleEngineType (initially just BeanShell, in future those you mentioned)
+ Add EventType (initially just Callout, in future Process, ModelValidatorEvent ... PayrollConcept
Now, in your example user is adding a script on GardenWorld - currently this must be forbidden (as discussed in this thread).
Script must be allowed JUST to System Administrator. A user on such window can drop a table, or extract the system admin password.
Regards,
Carlos Ruiz
Hi Carlos!
As I said we can use column DATA ACCESS LEVEL , the reason is because we need define a Rule to a client or org , the payroll only show the rule create to a Org or Client, but you are in right , we need some way to limit the access. but also need can create rule to a client or org in specific.
A good example is SaaS you would add different business logic to each Entity ;-)
Kind regards
Victor Perez
www.e-evolution.com
Hi Victor,
> As I said we can use column DATA ACCESS LEVEL ,
> the reason is because we need define a Rule to a
> client or org , the payroll only show the rule
> create to a Org or Client, but you are in right ,
> we need some way to limit the access.
> but also need can create rule to a client or org
> in specific.
I don't agree, maybe you can show the script to users, but you CAN'T allow editing of scripts for users. Just System Administrator can edit it.
To allow editing of scripts by users there must be a security layer over the script that I think is hard to achieve.
So, I suppose in an implementation of payroll, the scripts must be defined in System to be used in the different clients/orgs.
Regards,
Carlos Ruiz
Hi Carlos!
>> As I said we can use column DATA ACCESS LEVEL ,
>> the reason is because we need define a Rule to a
>> client or org , the payroll only show the rule
>> create to a Org or Client, but you are in right ,
>> we need some way to limit the access.
>> but also need can create rule to a client or org
>> in specific.
>I don't agree, maybe you can show the script to users, but you CAN'T allow editing of scripts for users. Just System Administrator can edit it.
>To allow editing of scripts by users there must be a security layer over the script that I think is hard to achieve.
>So, I suppose in an implementation of payroll, the scripts must be defined in System to be used in the different clients/orgs.
>Regards,
>Carlos Ruiz
My suggestion is that when create this window with DATA ACCESS LEVEL as System let the access to System Administration, but also we need to enable set by client and org.
In the payroll we show all the rules to a client or organization and this depend the Role the user ;-)
can we continue in the FR?
Kind regards
Victor Perez
www.e-evolution.com
We should default this as unchecked or not accesible by default except to Admin role. Only when users want it that the chain of accountability in the IT dept allows it.
Since Victor has his own Rule Engine... we try to make his merge without impact from one IT guy (victor) to the other IT guy (carlos) :-)
This marvelous idea of allowing IT guys working independently ala Eclipse Plugin has been the holy grail of ppl like Kontro, but today we see someone who really does it well.
Congratulations and highest regards to Carlos Ruiz and Lady Ruiz :-) <--- the woman behind the successful OS contributor.
red1
Dear Adempiere Community!!!
I made the implementation JSR 223: Scripting to callout now you can run any script any script engine.
http://scripting.dev.java.net/
This moment the engine are installed in Adempiere are (BeanShell,Groovy,Jhyton), Moises you will happy for this :-)
to call a script from a call out now you need use next syntax:
@script:beanshell:ValidateQtyOnHand
@script:groovy:ValidateQtyOnHand
@script:jhyton:ValidateQtyOnHand
Note: When you create the rule , you have that set search with this rule
Rule based in beanshel
Search Key : beanshell:ValidateQtyOnHand
Rule Based in groovy
Search Key : groovy:ValidateQtyOnHand
Rule Based in jhyton
Search Key : jhyton:vValidateQtyOnHand
also you need set the Even Type as Callout and Rule Type as JSR 223 Scripting APIs
thank Carlos motivate this integration
Kind regards
Victor Perez
CEO
www.e-evolution.com
Thanks Victor for this improvement.
I updated the wiki page
http://adempiere.com/wiki/index.php/Script_Callout
Regards,
Carlos Ruiz
Thanks! victor and Carlos for adding this!
Regards!
I know that I'm a bit late - but I like this new functionality.
+1 to put it into trunk now
Regards,
Karsten