Before a conversion from delete/remove services to expire services takes place, the associated entities need to be checked to correct those that don't have from and thru fields.
Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OEM - the unendorsed OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Wed, Aug 2, 2017 at 8:37 AM, Taher Alkhateeb <[email protected]> wrote: > I agree with the suggested naming convention and proposed work. > Naturally it should be done carefully and slowly. > > With that being said, since this discussion is getting traction, I > would suggest that If you are willing to make the effort towards > naming all these services then you might as well consider unifying > them. I was going to start a thread later on suggesting to unify all > services in a new component (similar to datamodel) that maybe we can > call service-library with a similar structure to datamodel. > > The reason why I interject in this thread specifically is because it > seems the effort is extensive enough that we might as well make it > bigger to unify and isolate services from the components consuming > them. So you rename + move in one shot. > > I don't know if this makes sense to you or you find value in it. So I > thought I'd throw it in the pot and see everyone's inclinations. > > On Wed, Aug 2, 2017 at 9:33 AM, Rishi Solanki <[email protected]> > wrote: > > +1 for the proposal with some caution (as suggested by Paul) on picking > an > > entity as candidate which won't have the delete service with it. > > > > Some basic steps I could think of we should follow in the effort. Please > > feel free to add more check points. > > > > 1) Identify such entities, where we have to remove the delete/remove > > services. > > 1.1) To make an entity as candidate to fall under this, it should > maintain > > the status or manage from date and thru date. Like Party and WorkEffort > > will have enable/disable flag and statuses. So we can consider them to > > follow the pattern mentioned in this thread. May be other entities which > > won't have these attributes could fall, but I think it is easiest way to > > count any entity IN. > > 2) Check all occurrences and check what could be the side effect in the > > process/workflow and how we can handle them. > > 3) Once we remove/change all occurrences, remove/change the delete/remove > > service for the entity. > > > > > > Just FYI all, Related discussion started by Suraj in other thread as > > "Proper record maintenance in marketing component" which tells we should > > add from date and thru date in some entities. So if community agree on > that > > point then we could consider those entities as well for improvement. > > > > > > > > > > -- > > Rishi Solanki > > Sr Manager, Enterprise Software Development > > HotWax Systems Pvt. Ltd. > > Direct: +91-9893287847 > > http://www.hotwaxsystems.com > > www.hotwax.co > > > > On Wed, Aug 2, 2017 at 11:33 AM, Swapnil Mane < > > [email protected]> wrote: > > > >> +1 for using 'expire' service for all the possible places. > >> > >> IMO, In ERP systems, we should not delete any information/data. Because > >> data is the real asset for the any organization. Helping in taking the > >> business decision. > >> > >> Thanks, Jacques and Deepak for sharing this. > >> > >> > >> - Best Regards, > >> Swapnil M Mane > >> www.hotwaxsystems.com > >> www.hotwax.co > >> > >> On Tue, Aug 1, 2017 at 8:04 PM, Jacques Le Roux < > >> [email protected]> wrote: > >> > >> > Hi, > >> > > >> > After a 1st discussion with Deepak at OFBIZ-9185, we had another at > >> > OFBIZ-9543. > >> > > >> > We claim that we should not remove entities records because of > auditing. > >> > But we have at 157 services with names starting with "remove" and 538 > >> > starting with "delete" > >> > > >> > I suggest that we remove as much as possible of these services and > have > >> > only expire services for those which support expire (ie have from and > >> thru > >> > dates). > >> > > >> > For instance I was curious about deleteParty, but what it currently > does > >> > is only returning the "partyservices.cannot_delete_ > >> party_not_implemented" > >> > label. This is pre Apache era (ie there for 10+ years)! > >> > > >> > In OFBIZ-9543 Deepak rightly suggested that we keep delete services > for > >> > Assoc kind of entities. But definitely remove delete service for > entity > >> > like Party, WorkEffort, Product, etc those have n number of foreign > key > >> > constraints... > >> > > >> > What do you think, other ideas? > >> > > >> > Jacques > >> > > >> > > >> >
