Re: Looping Search
This WebDNA talk-list message is from 2006
It keeps the original formatting.
numero = 66795
interpreted = N
texte = Yep... Suffice to say I didn't want to over-complicate the actions based on the need. Without a doubt we track numerous other pieces of data in regards to modifications including relational mod dates for historical reporting, author based mod history to associate changes with people, and selective logic to associate other actions with not only a staff ID but the current-@-date staff supervisor based on the time/date stamp as it relates to the action as compared to the historical mod data mentioned above. The big point being that by keeping the record in tact you will find that your ability to relate historical stuff is increased exponentially or even may come in to existence where it never existed. You will also find this is true for things like building/room assignments and reassignments, resource allocation for staff, even team assignment if/when you start grouping people together. Then all the activity and actions you record can be associated with Time & Space relationships based on your date tracking for mods. So -- DON'T DELETE :-) Status Flagging is the key to everything above and much more :-) Alex HTH On 4/6/06 10:04 AM, "devaulw@onebox.com"
wrote: > That is interesting and important for references in other tables. You could > have the field for "inactive_on" and "created_on" as dates to get a sense of > timing too. If the person_id is used elsewhere and still active (i.e. the > record could be updated), you will need to factor in reassignment for those > values in your business logic. Alex's method at least preserves the > relationship until the reassignment is made. I would recommend not deleting, > updating the subordinates and inactivating the record with a date field. > > It sounds like a transactional approach might also work. I know there was a > transactional scriptfor webdna designed at www.genericaddress.com but I never > looked at it. > > Back on the data structure, I just read last night about the "acts_as_tree" > model method in Rails. That seems like it would work really well to handle the > self-referential tree structure originally set out. Of course, you'd have to > be using Rails first. > > > -----Original Message----- > From: Alex McCombie > Sent: Thu, 06 Apr 2006 09:30:47 -0400 > To: "WebDNA Talk" > Subject: Re: Looping Search > > In similar situation with staffing we handle it a bit differently. > > If someone 'leaves' their record stays in tact but is flagged as inactive. > Then in your search you could use that flag to keep relationships and > intelligently code around the inactive user. > > This becomes critical in many ways keeping all sorts of items across > countless tables from being orphaned due to their original association with > a no inactive staff. > > The inactive label gives you the infinite flexibility to show relationships > clearly labeling the inactive staffer, or generate error reports about staff > associations with that inactive record, or creating interfaces to reassign > associations with a replacement staff. Even allows for temporary > relationships based upon some pre-defined logic. > > In our world.... NEVER delete the staff record. Historical association is > critical and should NEVER be lost. > > HTH > Alex > > > > > > On 4/6/06 8:22 AM, "Clint Davis" wrote: > >> Thanks Bill. The threaded bulleting board analogy is exactly what I was >> thinking. The reassignment scenario seems like the best approach. >> >> >> On 4/5/06 4:40 PM, "devaulw@onebox.com" wrote: >> >>> This seems alot like a threaded bulletin board. >>> >>> So the problem is how to re-assign subordinates in the hierarchy when a >>> supervisor disappears. >>> >>> One way might be to prevent deleting 2 until it's subordinates are >>> re-assigned >>> (i.e. throw up an error until the user fixes the condition). Not very >>> friendly since it lacks an intelligent default. >>> >>> Another way is to reassign the subordinates upon deleting 2 via a default, >>> i.e. 2 has a supervisor and when 2 is deleted, automatically assign everyone >>> who reports to 2 to 2's supervisor. I think that's what you were proposing. >>> Seems like a good solution too. Get 2's supervisor, search for anyone with >>> 2 >>> as a supervisor, replacefounditems with 2's supervisor. >>> >>> If an entry already has a missing supervisor [lookup =notfound], it needs to >>> be flagged and a supervisor assigned. >>> >>> Bill >>> >>> >>> -----Original Message----- >>> From: Clint Davis >>> Sent: Wed, 05 Apr 2006 15:10:58 -0500 >>> To: "WebDNA Talk" >>> Subject: Re: Looping Search >>> >>> I *do* have a field in the database where each person's immediate supervisor >>> is listed. Right now, Person 1 is hard coded into the page. A [search] for >>> anyone whose immediate supervisor is Person 1 yields the Person 2 listing >>> and so on down the chain. This works unless someone at the top is removed: >>> if Person 2 left, Persons 3, 8, and 11 would have to be reassigned to Person >>> 1 as their immediate supervisor, or the whole chart would break. >>> >>> >>> On 4/5/06 2:57 PM, "Pat McCormick" wrote: >>> >>>> Why not just have a field for immediate supervisor for every Person? >>>> A demotion simply means changing the supervisor field. Or i guess it >>>> could also mean coming to a stop. (get it? demotion? anyone?) >>>> >>>> >>>> On Apr 5, 2006, at 2:24 PM, Clint Davis wrote: >>>> >>>>> I need to setup and org chart like this: >>>>> >>>>> Person 1 >>>>> -----Person 2 >>>>> ----------Person 3 >>>>> ---------------Person 4 >>>>> ---------------Person 5 >>>>> ---------------Person 6 >>>>> ---------------Person 7 >>>>> ----------Person 8 >>>>> ---------------Person 9 >>>>> ---------------Person 10 >>>>> ----------Person 11 >>>>> ---------------Person 12 >>>>> ---------------Person 13 >>>>> ---------------Person 14 >>>>> >>>>> All of these people have a record in the personnel database with a field >>>>> for >>>>> their immediate supervisor. Can this be done with a [loop]'ed [search] >>>>> versus >>>>> my current nested [search]es? I don't want it to break if Person 3 gets >>>>> demoted, for example. >> >> >> >> >> ------------------------------------------------------------- >> This message is sent to you because you are subscribed to >> the mailing list . >> To unsubscribe, E-mail to: >> To switch to the DIGEST mode, E-mail to >> >> Web Archive of this list is at: http://webdna.smithmicro.com/ > > -- > Alex J McCombie > Adventure Skies Interactive (ASI) > Alex@Adventureskies.com > > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://webdna.smithmicro.com/ > > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://webdna.smithmicro.com/ -- Alex J McCombie Adventure Skies Interactive (ASI) Alex@Adventureskies.com ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
Yep... Suffice to say I didn't want to over-complicate the actions based on the need. Without a doubt we track numerous other pieces of data in regards to modifications including relational mod dates for historical reporting, author based mod history to associate changes with people, and selective logic to associate other actions with not only a staff ID but the current-@-date staff supervisor based on the time/date stamp as it relates to the action as compared to the historical mod data mentioned above. The big point being that by keeping the record in tact you will find that your ability to relate historical stuff is increased exponentially or even may come in to existence where it never existed. You will also find this is true for things like building/room assignments and reassignments, resource allocation for staff, even team assignment if/when you start grouping people together. Then all the activity and actions you record can be associated with Time & Space relationships based on your date tracking for mods. So -- DON'T DELETE :-) Status Flagging is the key to everything above and much more :-) Alex HTH On 4/6/06 10:04 AM, "devaulw@onebox.com" wrote: > That is interesting and important for references in other tables. You could > have the field for "inactive_on" and "created_on" as dates to get a sense of > timing too. If the person_id is used elsewhere and still active (i.e. the > record could be updated), you will need to factor in reassignment for those > values in your business logic. Alex's method at least preserves the > relationship until the reassignment is made. I would recommend not deleting, > updating the subordinates and inactivating the record with a date field. > > It sounds like a transactional approach might also work. I know there was a > transactional scriptfor webdna designed at www.genericaddress.com but I never > looked at it. > > Back on the data structure, I just read last night about the "acts_as_tree" > model method in Rails. That seems like it would work really well to handle the > self-referential tree structure originally set out. Of course, you'd have to > be using Rails first. > > > -----Original Message----- > From: Alex McCombie > Sent: Thu, 06 Apr 2006 09:30:47 -0400 > To: "WebDNA Talk" > Subject: Re: Looping Search > > In similar situation with staffing we handle it a bit differently. > > If someone 'leaves' their record stays in tact but is flagged as inactive. > Then in your search you could use that flag to keep relationships and > intelligently code around the inactive user. > > This becomes critical in many ways keeping all sorts of items across > countless tables from being orphaned due to their original association with > a no inactive staff. > > The inactive label gives you the infinite flexibility to show relationships > clearly labeling the inactive staffer, or generate error reports about staff > associations with that inactive record, or creating interfaces to reassign > associations with a replacement staff. Even allows for temporary > relationships based upon some pre-defined logic. > > In our world.... NEVER delete the staff record. Historical association is > critical and should NEVER be lost. > > HTH > Alex > > > > > > On 4/6/06 8:22 AM, "Clint Davis" wrote: > >> Thanks Bill. The threaded bulleting board analogy is exactly what I was >> thinking. The reassignment scenario seems like the best approach. >> >> >> On 4/5/06 4:40 PM, "devaulw@onebox.com" wrote: >> >>> This seems alot like a threaded bulletin board. >>> >>> So the problem is how to re-assign subordinates in the hierarchy when a >>> supervisor disappears. >>> >>> One way might be to prevent deleting 2 until it's subordinates are >>> re-assigned >>> (i.e. throw up an error until the user fixes the condition). Not very >>> friendly since it lacks an intelligent default. >>> >>> Another way is to reassign the subordinates upon deleting 2 via a default, >>> i.e. 2 has a supervisor and when 2 is deleted, automatically assign everyone >>> who reports to 2 to 2's supervisor. I think that's what you were proposing. >>> Seems like a good solution too. Get 2's supervisor, search for anyone with >>> 2 >>> as a supervisor, replacefounditems with 2's supervisor. >>> >>> If an entry already has a missing supervisor [lookup =notfound], it needs to >>> be flagged and a supervisor assigned. >>> >>> Bill >>> >>> >>> -----Original Message----- >>> From: Clint Davis >>> Sent: Wed, 05 Apr 2006 15:10:58 -0500 >>> To: "WebDNA Talk" >>> Subject: Re: Looping Search >>> >>> I *do* have a field in the database where each person's immediate supervisor >>> is listed. Right now, Person 1 is hard coded into the page. A [search] for >>> anyone whose immediate supervisor is Person 1 yields the Person 2 listing >>> and so on down the chain. This works unless someone at the top is removed: >>> if Person 2 left, Persons 3, 8, and 11 would have to be reassigned to Person >>> 1 as their immediate supervisor, or the whole chart would break. >>> >>> >>> On 4/5/06 2:57 PM, "Pat McCormick" wrote: >>> >>>> Why not just have a field for immediate supervisor for every Person? >>>> A demotion simply means changing the supervisor field. Or i guess it >>>> could also mean coming to a stop. (get it? demotion? anyone?) >>>> >>>> >>>> On Apr 5, 2006, at 2:24 PM, Clint Davis wrote: >>>> >>>>> I need to setup and org chart like this: >>>>> >>>>> Person 1 >>>>> -----Person 2 >>>>> ----------Person 3 >>>>> ---------------Person 4 >>>>> ---------------Person 5 >>>>> ---------------Person 6 >>>>> ---------------Person 7 >>>>> ----------Person 8 >>>>> ---------------Person 9 >>>>> ---------------Person 10 >>>>> ----------Person 11 >>>>> ---------------Person 12 >>>>> ---------------Person 13 >>>>> ---------------Person 14 >>>>> >>>>> All of these people have a record in the personnel database with a field >>>>> for >>>>> their immediate supervisor. Can this be done with a [loop]'ed [search] >>>>> versus >>>>> my current nested [search]es? I don't want it to break if Person 3 gets >>>>> demoted, for example. >> >> >> >> >> ------------------------------------------------------------- >> This message is sent to you because you are subscribed to >> the mailing list . >> To unsubscribe, E-mail to: >> To switch to the DIGEST mode, E-mail to >> >> Web Archive of this list is at: http://webdna.smithmicro.com/ > > -- > Alex J McCombie > Adventure Skies Interactive (ASI) > Alex@Adventureskies.com > > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://webdna.smithmicro.com/ > > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://webdna.smithmicro.com/ -- Alex J McCombie Adventure Skies Interactive (ASI) Alex@Adventureskies.com ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Alex McCombie
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Banners and sort of random display (1997)
Online reference (1997)
WCS Newbie question (1997)
SendTo more emails (1998)
Error Log.db --however (1997)
WebCatalog2 Feature Feedback (1996)
RE: Automatic Forwarding using WebCat (1997)
List Last Word (2002)
[Q] Novice's question (1997)
[delete] problem (1997)
Missing Cart Information (2003)
can WC render sites out? (1997)
The beginning (1997)
Stopping bad HTML propagation ? (1997)
New Problem (1997)
Pull Down Search (2000)
Database Updates (1997)
Setting up WebCatalog with Retail Pro data (1996)
WebCatalog + Linux + ODBC + Oracle ! ? (2000)
Secure server question (1997)