Adrian,
Just telling me it should stay, is not enough, you have to provide
reasoning for that.
my opinion is that a job interview is just a communication event of the
new type 'Jobinterview' with the roles already there. A job interview
can then already relate to other communication events
[
https://issues.apache.org/jira/browse/OFBIZ-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumit Pandit updated OFBIZ-4977:
Attachment: OFBIZ-4977.patch
Please find the patch in attachment for the issue.
--
Thanks And Rega
Also, the PerformanceReview model needs to be fixed in the same way as
JobInterview - relate parties to it using an intersection entity.
Taking it even further, JobInterview and PerformanceReview could be
based on a more generic entity - something like PartyInterview, then
each subtype can add
I agree that employee leave belongs in the Work Effort entities.
The JobInterview entity should stay, but its model needs to be fixed.
There should be a JobInterviewRole entity that connects the JobInterview
with Party, then the jobIntervieweePartyId and jobInterviewerPartyId
fields can be rem
Thank you Jacques, I have improved that old comment in rev. 1366294
Jacopo
On Jul 27, 2012, at 7:15 AM, Jacques Le Roux wrote:
>> -// uses the lookup map to determin if the location has been aliased in
>> serviceconfig.xml
>> +// uses the lookup map to determine if the location has bee
Replacing them with the indicated entities..
On 07/27/2012 12:27 PM, Adrian Crum wrote:
I don't understand the question. Are you proposing removing those
entities?
-Adrian
On 7/27/2012 4:42 AM, Hans Bakker wrote:
we intend to reduce the number of entities in HR:
EmplLeave
EmplLeaveReaso
fanse created OFBIZ-4978:
Summary: price rule add not correctly
Key: OFBIZ-4978
URL: https://issues.apache.org/jira/browse/OFBIZ-4978
Project: OFBiz
Issue Type: Bug
Components: product
Sumit Pandit created OFBIZ-4977:
---
Summary: Limitation and issue with
delegator.findByPrimaryKeyPartial method : returns error when partialKeyset
contains PK value.
Key: OFBIZ-4977
URL: https://issues.apache.org/ji
I don't understand the question. Are you proposing removing those entities?
-Adrian
On 7/27/2012 4:42 AM, Hans Bakker wrote:
we intend to reduce the number of entities in HR:
EmplLeave
EmplLeaveReasonType
EmplLeaveType -> workeffort+related-entities so it also appears on
the calendar
JobIn
The local dispatcher name must not match the webapp name. It just has to exist
in the web.xlm of the webapp.
Consider this use case, you have *many* webapps. They all share a set of properties and the values of these properties differ by
webapp (hosts, urls, tokens, timeouts, boolean values, e
From:
Author: jacopoc
Date: Thu Jul 26 07:03:46 2012
New Revision: 1365895
URL: http://svn.apache.org/viewvc?rev=1365895&view=rev
Log:
Made locationMap thread safe using static initialization and immutability.
Modified:
ofbiz/trunk/framework/service/src/org/ofbiz/service/engine/AbstractEng
we intend to reduce the number of entities in HR:
EmplLeave
EmplLeaveReasonType
EmplLeaveType -> workeffort+related-entities so it also appears on the
calendar
JobInterview
JobInterviewType -> communication event and related entities
any comments or suggestions?
Regards,
Hans
No offense but it sounds to me like you're using a hack in place of a proper
solution and are now concerned that it might go away? Can you provide a use
case example for where a service might need to know which webapp it was called
from? Service data is supposed to be supplied via the context,
The requirement is to be able to recognize in which webapp a service is called. If it's not called in the context of a webapp then
it's another problematic. Notably if it's called as a job, where then the webapp is always webtools. I will not consider this aspect
for now (then you need another wa
That seems to be an odd requirement. What if the service call didn't
originate from a webapp?
-Adrian
On 7/26/2012 3:11 PM, Jacques Le Roux wrote:
I did not have the time to read all the thread... I find useful to be
able to read the local dispatcher name from DispatchContext in
services to kn
As long as no one else has a problem with it, I agree that we should
eliminate the unused feature.
-Adrian
On 7/26/2012 5:25 PM, Jacopo Cappellato wrote:
On Jul 26, 2012, at 3:47 PM, Adrian Crum wrote:
I think this has something to do with each application being a separate web
application (
On Jul 26, 2012, at 3:47 PM, Adrian Crum wrote:
> I think this has something to do with each application being a separate web
> application (in a J2EE sense), but I'm just guessing. There seems to be a
> reason you would need some services local to (or restricted to) a web
> application, but I
On Jul 26, 2012, at 5:15 PM, Jacopo Cappellato wrote:
> Hi all,
>
> could you please help me to understand the meaning of the code in
> JmsListenerFactory that deals with the initialization of listeners? I am
> confused and before I touch it I would like to be sure I am not missing
> anything
Hi all,
could you please help me to understand the meaning of the code in
JmsListenerFactory that deals with the initialization of listeners? I am
confused and before I touch it I would like to be sure I am not missing
anything.
Specifically:
1) what is the purpose of the while block in the r
I did not have the time to read all the thread... I find useful to be able to
read the local dispatcher name from DispatchContext in
services to know from which webapp the service was called (webtools being a
specific case, for instance when you run services
from there...)
HTH
Jacques
From: "
Hmmm... please ignore this for now, I need more time to study the code.
Jacopo
On Jul 26, 2012, at 2:39 PM, Jacopo Cappellato wrote:
> I would like to updated the service-config.xsd file in the following way:
>
> Index: framework/service/dtd/service-config.xsd
>
I think this has something to do with each application being a separate
web application (in a J2EE sense), but I'm just guessing. There seems to
be a reason you would need some services local to (or restricted to) a
web application, but I don't know what the reason is.
-Adrian
On 7/26/2012 1:
Hi Anurag,
Please post your query on user mailing list.
On Wed, Jul 25, 2012 at 7:57 PM, Anurag Walia wrote:
> Hello All,
>
> I need you help.
>
> I need to retrieve a list from entity.
>
> Query like: select * from temp where name='ravi' OR name='anu';
>
> I have tried this but not working:
>
I would like to updated the service-config.xsd file in the following way:
Index: framework/service/dtd/service-config.xsd
===
--- framework/service/dtd/service-config.xsd(revision 1365888)
+++ framework/service/dtd/service-config.
... the removal will be documented, as usual, in the "Attic" page:
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic
Jacopo
On Jul 26, 2012, at 11:51 AM, Jacopo Cappellato wrote:
> * but the main question is: considering the layout described above, what is
> the purpose/goal of having several instances of LocalDispatcher with
> different names? Shouldn't we simply create one instance per delegator?
As a side note,
26 matches
Mail list logo
