[
https://issues.apache.org/jira/browse/OFBIZ-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15618390#comment-15618390
]
Montalbano Florian commented on OFBIZ-7950:
-------------------------------------------
Hi,
you may be totally right about this part. If an address without the "Address 1"
field makes sense, then we should allow it.
Does someone have an example for this ?
I looked into the service "createPartyPostalAddress" which creates a record for
storing the postal data and it requires at least the following fields :
- address1
- city
- contactMechId
- postalCode
So, if we want to adopt a more flexible address policy, we'll need to change
this service too. But it may impact other functionnality as well.
If we ever change this policy, then we can use an <xor> check (the same than
for the firstName/lastName check) to see if at least one data about the address
is filled by the user.
> Improve consistency of service createEmployee
> ---------------------------------------------
>
> Key: OFBIZ-7950
> URL: https://issues.apache.org/jira/browse/OFBIZ-7950
> Project: OFBiz
> Issue Type: Improvement
> Components: humanres
> Affects Versions: Trunk
> Reporter: Montalbano Florian
> Assignee: Nicolas Malin
> Priority: Minor
> Labels: consistency, create, employee, service
> Attachments: OFBIZ-7950_proposition.patch
>
>
> In the humanres component, we can create an employee through the form
> https://localhost:8443/humanres/control/NewEmployee .
> This form has required fields that are not the same requirement than the
> service called when submitting the form.
> The service called is createEmployee.
> In the service, everything is declared optional but the
> postalAddContactMechPurpTypeId (which is set in the form as an hidden field).
> This means we could create an Employee without forcing a telephone number or
> a primary address or even a first name.
> But then, within the service, a check is done on the firstName and lastName
> parameters and if missing, an error shows up.
> We could harmonize things a little.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
