Re: OFBiz Integrations

[Rodrigo Lima]

8) OAuth2 (Facebook, Linkedin, Twitter, SAML etc)

Em ter., 29 de set. de 2020 às 19:14, Rishi Solanki 
escreveu:

> Dear All,
> In another thread on "Integration with facebook ecommerce platform" one
> good suggestion came from user Andrew Williams to integrate OFBiz with
> WooCommerce and WordPress. I would like to extend it to all required
> integrations.
>
> Below are the areas as per my understanding where we would require
> integrations which is in general expected.
>
> 1) Payment (Amazon, Apple, PayPal, First Data etc)
> 2) Shipping (UPS, UPS, FEDEX, DHL etc.)
> 3) Other Selling Portals and Channels (Amazon, WooCommerce, Wordpress,
> Shopify etc.)
> 4) Communication related integration. (Email, SMS, Chatbot, Whatapp etc)
> 5) Supporting modules like Reports tool, Sales Force etc.
> 6) Data Import Tool like JSON, Excel, CSV etc.
>
> Please add more in the list. Once will have all items listed, we will push
> that list over the confluence page, and all supporting docs link. Later we
> can pick one by one and mark them complete from there, in this way from the
> open list everyone will have the opportunity to pick any and contribute.
>
> We can also think of creating open tickets from the approved list to work
> on. Looking forward.
>
> Rishi Solanki
> *CTO, Mindpath Technology*
> Intelligent Solutions
> cell: +91-98932-87847
> http://www.mindpathtech.com
> LinkedIn 
>

Re: Brainstorming: Security Configuration Patterns

[Rodrigo Lima]

Hi,

Ideas:

1 - LDAP Secure Integration
2 - Implementation the Rest URL Secure ( LDAP based ).
3 - SOAP Header ( Service BUS Security concept ).



2009/5/5 Andrew Zeneski andrew.zene...@hotwaxmedia.com

 Actually, SecurityGroup is a group that links permissions
 (SecurityGroupPermission) which then get associated with UserLogins
 (UserLoginSecurityGroup). In some systems a Role is a collection of
 permissions, much like a SecurityGroup in OFBiz.


 On May 5, 2009, at 2:26 PM, Harmeet Bedi wrote:

 To me this seemed to be intent from data model.

 - Group is PartyGroup that can be a collection of party through
 PartyRelationship.
 - PartyGroup is a Party. SecurityGroup can apply to Party hence to a
 PartyGroup
 - SecurityGroup is not a group of users, it is a role that applies to a
 Party.


 On closer inspection that does seem to be the case.
 It seems that SecurityGroup is really a collection of user logins.. so not
 a role at all.

 I see your point.. inserting a SecurityRole entity between Group and
 Permission would be more flexible. In that case SecurityGroup is really a
 UserLoginGroup.

 Harmeet

 - Original Message -
 From: Ruth Hoffman rhoff...@aesolves.com
 To: dev@ofbiz.apache.org
 Sent: Tuesday, May 5, 2009 1:44:34 PM GMT -05:00 US/Canada Eastern
 Subject: Re: Brainstorming: Security Configuration Patterns

 Harmeet:

 Groups within OFBiz are similar to roles but in the RBAC model a role
 is an entity in and of itself. A group or collection of groups (also
 defined in RBAC as unique entities) may have one or more roles applied
 to them just as a user might. I think the value of RBAC is in its
 extensibility.

 For example, by defining roles we can abstract the definition of a
 permission (the security constraint in this case) away from the
 assignment of the permission.

 Just my 2 cents.
 Ruth

 I think an important thing missing is parentId in SecurityGroup.
 Adding that would give you heirarchy. Groups sort of are roles. Group has
 association with Subject(UserLogin through UserLoginSecurityGroup),
 Permission(SecurityGroupPermission), Permission is tied implicitly to action
 and resource.. Sort of RBAC.

 Harmeet

 - Original Message -
 From: Ruth Hoffman rhoff...@aesolves.com
 To: dev@ofbiz.apache.org
 Sent: Tuesday, May 5, 2009 11:05:12 AM GMT -05:00 US/Canada Eastern
 Subject: Re: Brainstorming: Security Configuration Patterns

 Hi All:
 One pattern I worked with some time ago is called Role Based Access
 Control (RBAC). This would be similar to #4 below, where you have a
 role - with permissions associated with that role - defining
 authorization levels. If you are interested in exploring this further,
 I'd be happy to elaborate.

 Ruth
 David E Jones wrote:

 This thread is specifically for discussing possible configuration
 patterns to use in OFBiz going forward. Please keep other discussion
 in another thread, including the merits of each possibility... let's
 just brainstorm in this thread.

 To get things started, here are the patterns that have been discussed
 recently (in high level terms, we can get into implementation and
 specific practices later on), these are in no particular order:

 1. artifacts responsible for their own security (especially services
 and screens), and security permissions are referred to directly (ie
 the actual permissions are configured directly in the XML tags for the
 artifact)

 2. artifacts responsible for their own security, and no direct
 references are used and instead an indirect security control is
 referred to; this is basically the permission service model we've been
 using where a permission service is basically a security policy that
 refers to permissions, can query/filter/whatever to do record level
 security, and in customization the permission service can be
 overridden or its function changed by ECA rules without touching any
 OOTB code or configuration

 3. a hybrid of #1 and #2 where artifacts refer directly to permissions
 and there is external configuration based on those permissions that
 can add other qualifying permissions and/or invoke logic to change how
 that permission is evaluated (ie override the default behavior of
 requiring the user to have that permission and either add additional
 constraints or allow alternative constraints even if the user does not
 have the original permission that triggered it all); this is recursive
 so that if an alternative permission is configured that permission may
 also have further alternative permissions; also being recursive if
 attached logic evaluates other permissions that may have alternative
 permissions and/or permission logic attached to them; as I understand
 what Andrew has implemented, this is the pattern he followed

 4. artifacts are not responsible for their own security except to
 specify whether any sort of permission is required or not (ie a
 require-permission attribute, would be true by default; for example
 most ecommerce screens would have this set 

Re: [VOTE] Move from Beanshell to Groovy

[Rodrigo Lima]

-1

2008/5/21, David E Jones [EMAIL PROTECTED]:


 This is a vote based on the recent discussion thread for changing the OFBiz
 best practice tool for writing data preparation scripts from using Beanshell
 to using Groovy, and more generally making Groovy the standard scripting
 language wherever generic scripting is needed, even as a way to implement
 services (as a secondary best practice to using simple-methods).

 This sort of decision is perhaps not totally necessary to vote on, but does
 have a big impact on the project and many people involved, so a vote should
 help draw opinions and lead the community toward the best decision possible.

 Please vote:

 [+1] Yes, replace Beanshell with Groovy
 [+0] I'm not for, but I'm not against
 [-1] No, stick to Beanshell and don't migrate toward Groovy

 Many comments were brought up in the discussion thread, but addition
 comments related to your vote are welcome. As per usual everyone is welcome
 to vote and express opinions though only PMC votes are binding.

 -David