Hello Roland,
Comments Inline :-
On Tue, Jun 10, 2008 at 11:48 AM, RolandH <[EMAIL PROTECTED]> wrote:
> Hi Ashish,
>
> yes, for sure that wasn't a bug. Here is another small improvment: make
> externalId of Party entity useable through createPerson service:
>
> Index: applications/party/servicedef/services.xml
> ===================================================================
> --- applications/party/servicedef/services.xml (revision 665986)
> +++ applications/party/servicedef/services.xml (working copy)
> @@ -76,6 +76,7 @@
> <attribute name="statusId" type="String" mode="IN" optional="true"/>
> <attribute name="preferredCurrencyUomId" type="String" mode="IN"
> optional="true"/>
> <attribute name="description" type="String" mode="IN"
> optional="true"/>
> + <attribute name="externalId" type="String" mode="IN"
> optional="true"/>
> <override name="firstName" optional="false"/>
> <override name="lastName" optional="false"/>
> </service>
> Index: applications/party/src/org/ofbiz/party/party/PartyServices.java
> ===================================================================
> --- applications/party/src/org/ofbiz/party/party/PartyServices.java
> (revision 665986)
> +++ applications/party/src/org/ofbiz/party/party/PartyServices.java
> (working copy)
> @@ -144,7 +144,7 @@
> if (statusId == null) {
> statusId = "PARTY_ENABLED";
> }
> - Map newPartyMap = UtilMisc.toMap("partyId", partyId,
> "partyTypeId", "PERSON", "description", description, "createdDate", now,
> "lastModifiedDate", now, "statusId", statusId);
> + Map newPartyMap = UtilMisc.toMap("partyId", partyId,
> "partyTypeId", "PERSON", "description", description, "createdDate", now,
> "lastModifiedDate", now, "statusId", statusId, "externalId",
> context.get("externalId"));
> String preferredCurrencyUomId = (String)
> context.get("preferredCurrencyUomId");
> if (!UtilValidate.isEmpty(preferredCurrencyUomId)) {
> newPartyMap.put("preferredCurrencyUomId",
> preferredCurrencyUomId);
>
>
I cann't update the use externalId in the createPerson service.
I remembered that there has been a discussion on ML long time back for not
keeping externalId on the createPerson service.
User can use this externalId in their own custom service.
I would like to see the community feedback on this then only can take
further action on it.
>
> And a new question :) [BTW: if you ever think RTFM is the right answer to
> my questions, that's fine, please give me a hint of the correct manual]
Its really hard for me to imagine that if you will not spend your time in
reading the document that is shared on Ofbiz Confluence then how should you
overcome
from the thing to ask question on ML instead of getting answer from your own
:-).
>
>
> I'm trying to get behind the idea of CountryCode entity in combination with
> Geo entity...
> my problem: I have to create PostalAddress with ISO 2 letter Country Code,
> while PostalAddress requires a geoId.
You can do one thing , Instead of creating the ISO 2 letter country code why
don't you fetch the associated "geoCode" (from Geo entity) related to the
"countryGeoId" value in PostalAddress in your custom code.
(PostalAddress(countryGeoId) --> Geo(geoId) )
This will be easy for you to maintain the code and keeping the code from
Ofbiz as it is.
> The question right now is: what unique information does CountryCode hold?
> why is it needed?
CountryCode entity is specific to the record for Country.
And at the same time Geo can hold the data related to Country & County etc.
>
> maybe Geo.geoCode is what I'm looking for?
> Does a "fetch Geo where geoTypeId == 'COUNTRY' && Geo.geoSecCode is not
> null && Geo.geoCode == isoCodeWeAreLookingFor " return the correct result?
>From the PostalAddress record fetch the related record from Geo.
For example :- geoData = postalAddress.getRelatedOne("CountryGeo");
geoData.geoCode will return you the 2 Digit ISO code.
--
Ashish
>
>
> Thanks again and again,
> Roland
>
>
> Ashish Vijaywargiya wrote:
>
>> RolandH,
>>
>> Thanks for your comments.
>> No need to create the JIRA issue for it.
>> I managed to update the code because it was of one line change.
>> Please take the update.
>>
>> But we should note it down that it will be considered as "improvement"
>> instead of "BUG".
>>
>>
>
