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 >> > >> > >>
