[DISCUSSION] How far are willing to go with diluting the Party component to be diluted with business domain specific functions

[Pierre Smits <pi...@gmail.com>]

While going through some unread JIRA notification I came across:
https://issues.apache.org/jira/browse/OFBIZ-9896, and I took a peek at the
starting point: https://demo-trunk.ofbiz.apache.org/partymgr/control/main

I find it a bit curious that we have in the party menu:

   1. Create Employee
   2. Create Customer
   3. Create Prospect

#1 is clearly a function that belongs in the HR department, and we have a
specific component (HRM) for that. Equally so, #2 and #3 belong in the
CRM/Sales domain, and we also a specific component (SFA) for that.

If we continue with this, the next committer will feel entitled to add
similar functions for supplier, vendor, tax authority, any kind of (N)GO,
trucker, patient, HR Representative, worker, manager, etc.

Would it not be beneficial to both the project and its adopters when we:

   - provide a clear description about what and for whom the application is
   intended for;
   - remove the above mentioned menu-items (and the associated screens, and
   services) from the component, and (if necessary) create/move these to the
   above mentioned business domain specific components?

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OEM - The OFBiz Extensions Marketplace1
http://oem.ofbizci.net/oci-2/
1 not affiliated to (and not endorsed by) the OFBiz project

Re: [DISCUSSION] How far are willing to go with diluting the Party component to be diluted with business domain specific functions

[Rishi Solanki <ri...@gmail.com>]

+1.

Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co

On Sun, Nov 26, 2017 at 2:57 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Le 25/11/2017 à 21:31, Taher Alkhateeb a écrit :
>
>> With that being said, I think the party component is relatively stable
>> and not getting constantly diluted. But yeah maybe it's carrying too
>> much probably for historical reasons.
>>
> Hi Pierre, Taher,
>
> I agree with both of you. I just wanted to say that the party component
> has not been constantly diluted pertaining to party creation.
> IIRW, it exits as is since I know it (2004) and I was able to verify at
> least with R09.04 tonight (so 8 years ago, R4.0 seems not to work with Java
> 8, R09 does, at least not too badly)
> As Taher said, this does not mean that we can't put some effort in
> redesigning its UI, maybe not the top priority though...
>
> Jacques
>
>

Re: [DISCUSSION] How far are willing to go with diluting the Party component to be diluted with business domain specific functions

[Jacques Le Roux <ja...@les7arts.com>]

Le 25/11/2017 à 21:31, Taher Alkhateeb a écrit :
> With that being said, I think the party component is relatively stable
> and not getting constantly diluted. But yeah maybe it's carrying too
> much probably for historical reasons.
Hi Pierre, Taher,

I agree with both of you. I just wanted to say that the party component has not been constantly diluted pertaining to party creation.
IIRW, it exits as is since I know it (2004) and I was able to verify at least with R09.04 tonight (so 8 years ago, R4.0 seems not to work with Java 8, 
R09 does, at least not too badly)
As Taher said, this does not mean that we can't put some effort in redesigning its UI, maybe not the top priority though...

Jacques

Re: [DISCUSSION] How far are willing to go with diluting the Party component to be diluted with business domain specific functions

[Taher Alkhateeb <sl...@gmail.com>]

I agree the mentioned menu items should be removed from the party
component and moved to the appropriate components. I also agree that
we shouldn't add domain-specific behavior to the generic party
component. So +1 for moving them.

There is also more stuff that perhaps should be moved away. For
example when viewing any party you have tabs including:
- vendor
- tax info
- shipping lists
- party skills
- resumes
- employment application
- product store roles
- financial history
- billing accounts
- financial accounts
- requests
- orders
- quotes

I think all of those also should be moved to appropriate components.
This requires a comprehensive study of how and where to move such
items. A JIRA might help in capturing all this information.

With that being said, I think the party component is relatively stable
and not getting constantly diluted. But yeah maybe it's carrying too
much probably for historical reasons.

On Sat, Nov 25, 2017 at 11:04 PM, Pierre Smits <pi...@gmail.com> wrote:
> While going through some unread JIRA notification I came across:
> https://issues.apache.org/jira/browse/OFBIZ-9896, and I took a peek at the
> starting point: https://demo-trunk.ofbiz.apache.org/partymgr/control/main
>
> I find it a bit curious that we have in the party menu:
>
>    1. Create Employee
>    2. Create Customer
>    3. Create Prospect
>
> #1 is clearly a function that belongs in the HR department, and we have a
> specific component (HRM) for that. Equally so, #2 and #3 belong in the
> CRM/Sales domain, and we also a specific component (SFA) for that.
>
> If we continue with this, the next committer will feel entitled to add
> similar functions for supplier, vendor, tax authority, any kind of (N)GO,
> trucker, patient, HR Representative, worker, manager, etc.
>
> Would it not be beneficial to both the project and its adopters when we:
>
>    - provide a clear description about what and for whom the application is
>    intended for;
>    - remove the above mentioned menu-items (and the associated screens, and
>    services) from the component, and (if necessary) create/move these to the
>    above mentioned business domain specific components?
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OEM - The OFBiz Extensions Marketplace1
> http://oem.ofbizci.net/oci-2/
> 1 not affiliated to (and not endorsed by) the OFBiz project