the mca I am using is in the yahoo directory.
so I am not proposing to put yahoo mca in the trunk.
I do have a shippers mca that deals with ups, fedex, dhl.
BJ Freeman sent the following on 9/30/2008 7:43 PM:
> [The point I was trying to make is that the decision of whether or not
> an email is a
[The point I was trying to make is that the decision of whether or not
an email is a Yahoo email has to be made *somewhere* - so why not keep
Yahoo-related code in one place? Your approach scatters the
Yahoo-related code.]
to me putting email processing in the yahoo code is squattering the
email p
ah, I was asking if there was any opposition to the change.
I have it mostly done.
thanks.
Adrian Crum sent the following on 9/30/2008 5:44 PM:
> Until someone is willing to to make those changes, you're stuck with the
> tools at hand. That's why I suggested moving your parsing logic to the
> pr
Until someone is willing to to make those changes, you're stuck with the tools
at hand. That's why I suggested moving your parsing logic to the processing
logic you already have.
Your example:
If an email has a return path that contains "[EMAIL PROTECTED]" and/or (not
sure which) the email is
just to recap my question had to do with modifying the
ServiceMcaCondition.java
to handle a contians operator and allowing more than one condition for
fields and headers.
Nothing specific about the type of email like fedex or ups.
BJ Freeman sent the following on 9/30/2008 3:39 PM:
> #1 is to de
#1 is to determine were to direct the specific email
that is my uncerstainding of mCA.
otherwise why not just do a way with it?
#2 not sure the function of #2 since that can be filtered by the mca.
Why bury the filter algorithms in code. isn't
From a design perspective, my preference would be to have a good
separation of concern. Something like:
1. MCA triggers service call
2. Service pre-parses mail - drops obvious rejects
3. Service forwards mail to a processing chain:
Pre-Parsed Mail -> Fedex Processor -> UPS Processor -> Import P
if you look at the msg about checking for duplicates in the user ML you
can see that any thing that will take longer will eventually clogs the
system.
Most of my clients have hundreds of emails from shippers
(fulfillment/dropshippers) and suppliers about status of drop ship
inventory.
So I would li
routines are in java. and meant to parse the email. they never get put
in the communications event.
Adrian Crum sent the following on 9/30/2008 1:13 PM:
> What are the processes written in? Are they services? If yes, then you
> could set up a service group and have the email go from service to
> s
What are the processes written in? Are they services? If yes, then you
could set up a service group and have the email go from service to
service - each service acting on the email accordingly.
-Adrian
BJ Freeman wrote:
thanks
but I have many processes that are based on the email subject and
thanks
but I have many processes that are based on the email subject and or
sender. Fedex notification, UPS Notifications, Order of different formats
Import routies, etc.
would like to do this in the mca so I don't have to write this in java
code then do the same thing.
Adrian Crum sent the follow
The way I handled it here was to have a simpler condition that sent the
email into a processor that did additional evaluations on the email.
-Adrian
BJ Freeman wrote:
if seemed pretty simple to add the conditionals.
but looking a the decision tree it looks like is an or'ed condition.
if I have
if seemed pretty simple to add the conditionals.
but looking a the decision tree it looks like is an or'ed condition.
if I have two condition for the same header or field and one of them is
true then they will all be true.
The question is, is expanding the conditions to accept and and or
condition
Thanks Scott for the pointers. I missed those as the titles didnt look
relevant.
I think GenericDelegator is being refactored currently - what about adding
additional parameter to the findBys or other suitable way which allows
callers to specify whether to create a transaction or not? Seems like
David (and others),
There is a fundamental difference between the
RecurrenceRule/RecurrenceInfo entities and the TemporalExpression entity
that needs to be addressed.
In the example David gave below, the duration of the recurring event is
assumed to be 8 hrs (byHourList="09,10,11,13,14,15,16
David,
Sorry it took so long to reply to this - I've been giving it a lot of thought
before answering.
I think it would be best to just have the one WorkEffort, and any changes made
to recurring instances of it would be made to the original copy.
On a side note, the implementation here has som
Or modify the performFind service so it accepts an optional EntityCondition
parameter that contains additional permissions.
-Adrian
--- On Tue, 9/30/08, Scott Gray <[EMAIL PROTECTED]> wrote:
> From: Scott Gray <[EMAIL PROTECTED]>
> Subject: Re: usage of party entity status field
> To: dev@ofbi
Ok Jacopo,
i will remove the invoice conversion service and will adapt the payment
application screens and programs so it will be possible to apply a
payment on another currency...however this 'other' currency should be
available on the payment as an 'original' currency.
In order to be able to di
Thanks Jacopo,
I think I will make a FAQ for that...
Jacques
From: "Jacopo Cappellato" <[EMAIL PROTECTED]>
On Sep 30, 2008, at 5:28 AM, Hans Bakker wrote:
Hi Jacopo,
the point below is very important, does it mean the ledger posting is
checking the company base currency against the invoice
Thanks Scott i will have a look into that
however i stiil think that making the status field mandatory and filled
as in any other status field, would be much easier for many other
programs/views which now have to use this special treatment
thanks again for your suggestion...
Regards,
Hans
O
createShipment parameters : add a shipmentId in IN parameters
-
Key: OFBIZ-1978
URL: https://issues.apache.org/jira/browse/OFBIZ-1978
Project: OFBiz
Issue Type: Improvement
Hi Hans
You could always run the prepareFind service in a groovy script, add
your extra condition for the null and then run the executeFind
service. It's not too much coding and you can copy most of it
straight from the performFind service.
Regards
Scott
2008/9/30 Hans Bakker <[EMAIL PROTECTED]
but the problem is performFind cannot do that and adding this to
performfind is a major undertaking for us...
so be it
On Mon, 2008-09-29 at 22:38 -0600, David E Jones wrote:
> The more common approach is to design the search or other
> functionality to be more flexible, because at the
23 matches
Mail list logo
