Hi Pierre, I would say that SystemProperty is definitely not the best solution. For one thing, a system property is sort of a framework configuration, like the theme, mail settings, some paths, etc ...
If you want an association between a calendar and a workeffort, then just create an assoc entity. I would recommend to steer away from "not so obvious" places as this is exactly why we started the refactoring project in the first place. Another thing to notice is that the service getWorkEffortEventsByPeriod actually checks first in the incoming parameters whether a list of entityExprList is passed to it, if not, it will call getDefaultWorkEffortExprList passing in the WorkEffortType and CalendarType. So maybe you can avoid the whole thing by making the filtration logic on the screen level (or data preparation level) by passing the correct entityExprList. My personal preference would be something like the following: - actually delete getDefaultWorkEffortExprList and fix the calling code - do not add any mapping entities - either hardcode the filtration on screen level OR - create a new service that applies the filters for each component separately (manufacturing, project, etc ...) In other words, change the world around the edges, not at the heart of the thing! This makes the code more resilient and not too specialized and component dependent. My 2 cents. Regards, Taher Alkhateeb -----Original Message----- From: Pierre Smits [mailto:[email protected]] Sent: 23 March 2016 15:40 To: [email protected] Subject: Re: [DISCUSSION] Refactor WorkEffort - Calendar(s) One solution we could apply is storing the mapping in the SystemProperty entity, like: {code} <SystemProperty systemResourceId="workeffort" systemPropertyId= "calendarType.CAL_MAINTENANCE" systemPropertyValue="WEPT_MAINTENANCE" description="Calendar Type to Work Effort Purpose Type association"/> {code} Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Wed, Mar 23, 2016 at 1:00 PM, Pierre Smits <[email protected]> wrote: > HI all, > > [pre-amble] > Currently, the workeffort component is also housing functionalities > for calendars. For this we have the following datasets: > > - <EnumerationType description="Calendar Type" > enumTypeId="CALENDAR_TYPE" hasTable="N" parentTypeId=""/> > - <Enumeration description="Personal Calendar" enumCode="PERSONAL" > enumId="CAL_PERSONAL" sequenceId="01" enumTypeId="CALENDAR_TYPE"/> > - <Enumeration description="Manufacturing Calendar" > enumCode="MANUFACTURING" enumId="CAL_MANUFACTURING" sequenceId="02" > enumTypeId="CALENDAR_TYPE"/> > - <Enumeration description="None" enumId="CAL_NONE" sequenceId="03" > enumTypeId="CALENDAR_TYPE"/> > > The Enumerations mentioned above are used in functions to help > filtering the overview of calendar items in the calendar screen(s), as > per function getDefaultWorkEffortExprList in WorkEffortServices.java. > > [case] > Calendars are applied in various business domains to serve specific > purposes. We can consider the following: > > - personal calendar > - manufacturing calendar > - maintenance calendar > - project calendar > - etc. > > We have only the first two defined and we have hardcoded the filtering > conditions (based on the workEffortTypeId). > > [suggestion] > > 1. We should remove the hardcoded filtering based on the workEffortType > 2. We should remove the hardcoded definitions > 3. Association of CALENDAR_TYPE to the WorkEffort records should be > based on a mapping. > > [discussion] > What are your thoughts on this? Should we have the mapping (item #3) > in an existing entity, and which one should that be? What are the > aspect to consider when refactoring this. > > I love to hear from you. > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ >
