You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Employee and project entries suffer from a potential conflict between timestamps and their related "labels":
Employees: NPI Employee and On Leave
Projects: State
These labels should ideally be "auto-updated" by the system, deduced from the timestamps. (As opposed to the current solution, which requires manual updating. Alternatively, they could be dropped – they are, after all, redundant. However, they do make very useful filters.)
Example situation:
An employee can be set as "currently employed" by adding a "hired" timestamp, but the NPI Employee field could indicate the opposite, until manually updated. Same vice versa, and the same type of conflict exists for On Leave, as well as projects and their state (planned, active, etc.).
The current system effectively forces editors to continuously monitor all these timestamps/statuses manually, and manually update the entries. Furthermore, such updates must be done at very specific times (the exact times specified in the timestamps).
The text was updated successfully, but these errors were encountered:
Yes, states like "planned" for completed projects (common) is awful...
These are "planned" just now...
N-ICE2015: Physical oceanography | project
N-ICE2015: Logistics | project
N-ICE2015: Atmosphere | project
N-ICE2015: Outreach | project
N-ICE2015: Ecosystem dynamics in a high-Arctic pack ice environment | project
cnrdh
changed the title
Potential conflict on timestamps and their related "labels" in employee and project entries
Schema modifications needed for project and person
May 4, 2017
Employee and project entries suffer from a potential conflict between timestamps and their related "labels":
NPI Employee
andOn Leave
State
These labels should ideally be "auto-updated" by the system, deduced from the timestamps. (As opposed to the current solution, which requires manual updating. Alternatively, they could be dropped – they are, after all, redundant. However, they do make very useful filters.)
Example situation:
An employee can be set as "currently employed" by adding a "hired" timestamp, but the
NPI Employee
field could indicate the opposite, until manually updated. Same vice versa, and the same type of conflict exists forOn Leave
, as well as projects and their state (planned
,active
, etc.).The current system effectively forces editors to continuously monitor all these timestamps/statuses manually, and manually update the entries. Furthermore, such updates must be done at very specific times (the exact times specified in the timestamps).
The text was updated successfully, but these errors were encountered: