David, Thanks for your insight on my comments. Please see my comments inline :-
On Sat, Jun 28, 2008 at 4:12 PM, David E Jones <[EMAIL PROTECTED]> wrote: > > On Jun 28, 2008, at 12:42 AM, Ashish Vijaywargiya wrote: > > I have NO idea what the point of the WorkEffort.statusChangeNote field is, >>> so please do share your thoughts on what that field will be used >>> >> >> >> >> for and why it is on the WorkEffort entity (as opposed to, say, the >>> WorkEffortStatus entity). >>> >> >> >> The idea of introducing the field in WorkEffort entity(statusChangeNote) >> was >> to put the reason of WorkEffort Status change. >> And if user changes the Status again then we would like to maintain the >> Old >> Status Note provided in statusChangeNote field. >> So from the code snippet shown below from the file >> WorkEffortSimpleServices.xml, we are putting the old value from >> WorkEffort.statusChangeNote field in the WorkEffortStatus.reason field. >> > > I see where you're going with this now. > > Why not just have the reason on the WorkEffortStatus entity for each time > it is changed? I can't think of a reason why we would need, or want, it on > the WorkEffort entity since the field there would describe the last status > change, and status changes are what the WorkEffortStatus entity is all > about. > The reason of keeping the field(statusChangeNote) in WorkEffort entity was that you don't directly update the values in the WorkEffortStatus table. If you update the value for the "status" in the WorkEffort table then the changed value will also gets saved in the WorkEffortStatus table for maintaining the History of status. I am confused that how should we maintain the value in the WorkEffortStatus.reason field.Because the value in WorkEffortStatus comes on changing the value in WorkEffort table.Please let me know your thoughts on this so I will get the better insight on the scenario of keeping only the "reason" field in WorkEffortStatus table. > > > +<set from-field="lookedUpValue >> >>> >>> .statusChangeNote" >>> field="newWorkEffortStatus.reason"/> >>> >> >> >> >> From the next time I will propose the changes on the Dev mailing list >> first >> and wait for some time for any feedback from the community members and >> then >> after finalizing the discussion if occurs in b/w the members I will put >> the >> code in the trunk. >> > > For now, should we revert this? > I have reverted all Data Model related changes in rev 672707.But I kept the "reason" field as it is in WorkEffortStatus table. > > We should at least get rid of the WorkEffort.statusChangeNote. For the > WorkEffortStatus.reason field, we might want to discuss it first... for > example: do we want a free-form text entry box (which the current field > would support), or do we want a drop-down to select among pre-configured > reasons, for which we'd want to have a field like "reasonEnumId". Suppose we have created the 10 reason for this status change and while keeping the Project in "Hold" or "Cancel" status some other reason come infront of us , say it as 11th reason.So what should we do in that case ? I like it to be text field but will go with the community decision. -- Ashish > > -David > >
