Closed trbmcginnis closed 5 years ago
looks good, great PR, love the depth and clarity of ur description i feel proud and so happy.
but just want to clarify ... If projects have END dates in the future, we don't want to display them in the projects search view? That seems like any ongoing project? Also very possible that I don't understand what actualenddate
means but seems worth clarifying for future issue revisiters
looks good, great PR, love the depth and clarity of ur description i feel proud and so happy.
but just want to clarify ... If projects have END dates in the future, we don't want to display them in the projects search view? That seems like any ongoing project? Also very possible that I don't understand what
actualenddate
means but seems worth clarifying for future issue revisiters
So the only place that these dates show up is on the projects list as a date right next to the project title. They are only there to (1) give users an "idea" of when the most recent activity on the project was and (2) to order the projects by most recent activity (aka lastmilestonedate
). If a project has a milestone where the actualenddate
is in the future, the date for the next most recent milestone will be chosen as that display date, so honestly the difference won't be that large.
1) Some projects have future milestone dates. In order to avoid these future dates from showing up on the projects list, I added this to the WHERE clause on
dcp_milestoneproject
table in materialized view:AND mm.dcp_actualenddate::date <= CURRENT_DATE
This way, any milestone dates that are less than or equal to the current date (in the past or the present) will be included in the materialized view.
2) I also changed the selection of milestones from
dcp_milestone.dcp_name
todcp_milestone.dcp_milestoneid
, because milestone IDs are more reliable3) I then re-added the
dcp_name_index
tonormalized_projects
, as this index is removed when the materialized view is dropped and then re-created.I did this index creation in a separate migration to make it cleaner/easier to remember for future updates, and to make it easier to run. I was having trouble getting the materialized view to run before creating the new indices when they were in the same migration--there's probably a way around this rather than creating a whole new migration--but creating a new migration seemed like the best solution.
Closes #511
NOTE: This is live on staging db but we need to run migrations again once this is merged into master for it to be live on production db.