Resource client bug and possible questionable behavior?

Mike Bell mbell at
Thu Dec 6 08:27:26 PST 2001


I did notice that swing takes the liberty of resizing the window and thus
shrinking the input text boxes to an unreasonable size.  It's about right for a
"complaints box" but I think we want it larger for anything else. If you grab the
corner of the widow and increase the size a little then the boxes increase to a
normal size. It looks like it all depends on the screen settings of the machine
you display it on.  I can change any of the labels, screen sizes, position,
modality, font or darn near anything else. Just let me know what works best for
you. Also I think the help button taks about date format as well so you may want
changes to that as well.



John Shott wrote:

> Bill and Mike:
> I did a bit of work with the resource client and noticed a couple of things:
> 1. The window that is used for the "Replace Project", "Replace Account", and
> "Replace All Accounts" menu items comes up (for me at least) with zero width
> boxes for the fields member/project/account (whichever is needed), old ?, new
> ?, and effective date.  It's barely wide enough to click and not wide enought
> to see any typing.  Also, the label on the effective date should read
> something like:
> "Effective date (mm/dd/yy)" because, I think that may be about the only format
> that it accepts.  I had originally thought that it was only my NT remote
> client that was displaying this zero width behavior ... but this was running
> on a Sunray.
> 2. If I process a "Replace Project" with an effective date of 11/01/01 and
> then inspect the "works_on entries for the old project, they show an edate (as
> they should) of 11/01/01.  However when I check the bdate of the new project
> int he works_on entries, it seems to show up as "Now" ... since this was a
> project that I did just create "now" in the "New Projects window", it
> certainly seems that the new project shoudl have now as its bdate (I think),
> but I'm wondering whether it should have "now" or "11/01/01" at the point at
> which it becomed effective.  I can sort of make arguments each way ... and
> maybe this is the planned behavior ... but, to be honest, it wasn't what I was
> thinking would happen:  My guess would have been that the project entry itself
> would have a bdate of when it was actually created ... which I think is most
> reasonable.  But the bdate in the works_on table, I would think, represnets
> the time when taht works_on entry became effective (which was effectively
> "back dated to 11/01/01") even though the project didn't technically exist
> until a few moments before "now".
> In any event, I  think that this change should have resulted in a few entries
> in the adjustments table for this month.
> Member florando should have some adjustments of type eq_activity that change
> charges from 2DHZ443 to 2DHZ444.
> Member maxy should have some adjustment of type training that change from the
> same two numbers for some training that occurred during november (actually, it
> looks like there was only one such event during november ... although there
> may be some december events that also got adjusted, I  suppose.
> I haven't actually checked the ajustment table to doulbe chekc these things
> ... I'll try to do that in the morning.
> Talk to you tomorrow,
> John

More information about the coral mailing list