{"action":"created","issue":{"url":"https://api.github.com/repos/theCrag/website/issues/1865","repository_url":"https://api.github.com/repos/theCrag/website","labels_url":"https://api.github.com/repos/theCrag/website/issues/1865/labels{/name}","comments_url":"https://api.github.com/repos/theCrag/website/issues/1865/comments","events_url":"https://api.github.com/repos/theCrag/website/issues/1865/events","html_url":"https://github.com/theCrag/website/issues/1865","id":58487121,"number":1865,"title":"Route history and maintenance, + alerts for required work (dodgy bolt etc)","user":{"login":"brendanheywood","id":187449,"avatar_url":"https://avatars.githubusercontent.com/u/187449?v=3","gravatar_id":"","url":"https://api.github.com/users/brendanheywood","html_url":"https://github.com/brendanheywood","followers_url":"https://api.github.com/users/brendanheywood/followers","following_url":"https://api.github.com/users/brendanheywood/following{/other_user}","gists_url":"https://api.github.com/users/brendanheywood/gists{/gist_id}","starred_url":"https://api.github.com/users/brendanheywood/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/brendanheywood/subscriptions","organizations_url":"https://api.github.com/users/brendanheywood/orgs","repos_url":"https://api.github.com/users/brendanheywood/repos","events_url":"https://api.github.com/users/brendanheywood/events{/privacy}","received_events_url":"https://api.github.com/users/brendanheywood/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/theCrag/website/labels/6:%20New%20Feature","name":"6: New Feature","color":"009800"},{"url":"https://api.github.com/repos/theCrag/website/labels/Content%20editing","name":"Content editing","color":"eb6420"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-02-22T02:27:33Z","updated_at":"2016-03-19T08:42:15Z","closed_at":null,"body":"Split off from #1313 and mentioning @tomkjaerolsen / @lordyavin \r\n\r\nMy latest thoughts on the route history concepts are that we could have a much simpler data model (than what is proposed in #1313) which still works, effectively making 'editorial version history' a purely thecrag concept, while making 'physical route history' the real data model change. We already have a route history set of tables for FA and FFA, Set, so the only thing we need to do is add a 'Maintenance' type for history.\r\n\r\nSo we effectively completely ignore 'edit history' and focus purely on what happened in real life\r\n\r\nName / grade |Who| Comment|Date|Type\r\n-------------|-----|-----|---|---\r\nMark's project 24-27 |mark| Mark found cleaned rock |Jun 1997|Set\r\nInto thin air 26 | mark |FA by Mark but not clean|Jul 1997|FA\r\nInto Thin Air 26 | greg|FFA by Greg  |Oct 1997|FFA\r\nInto Thin Air 26 |dreeve| Rebolting in titanium, new anchor |Feb 2014|Update\r\n\r\nSo this would involve the following changes:\r\n* [ ] Add a new history type of 'Update' (or Maintenance, or Fix, need something succinct that covers new anchors, glueing holds, rebolts, chopping bolts, removing dangerous rock etc)\r\n* [ ] 'Updates' probably wouldn't get shown in list view, only in the route detail page\r\n* [ ] Each history item currently doesn't have anything about name or grade. Adding this is more 'correct' and would really solve the other problem #1313 but is probably of limited value so leaning towards not bothering. Needs more discussion\r\n* [ ] Hand in hand with the ability to add new 'Updates' is a way to report or list these in isolation, ie something like this page on chockstsone:\r\n\r\nhttp://www.chockstone.org/Rebolting/RoutesQld.asp?Sort=Date\r\n\r\nHowever I don't see the point in making work for ourselves for no reason. I'm pretty sure there are lots of benefits to ACA specifically moving from the chockstone DB to ours if we made this feature, but there is no point doing it unless they are going to move. Sure other similar clubs will also benefit but I'd want to get at least 1 or 2 on board from the start to make sure it solves the problem properly. So need to chat to David Reeve / ACA at some point or maybe @tomkjaerolsen you could help with this? Or point David to this issue\r\n\r\n* [ ] as a bonus would be nice for climbers to flag the need for this, eg 'Needs maintenance' and then the ACA could see a list of routes which need a look. Again don't want to even think seriously about this until we have someone like the ACA on board to make sure we do this right\r\n* [ ] There is some cross over with gyms, often a gym ticking app will have a 'needs maintenance' flag for spinning holds / broken holds etc\r\n* [ ] There may be value in simply an 'Inspection' ie safer cliffs comes and tests / rebolts a bunch of stuff, some stuff is ok but it's worth marking that with a date\r\n* [ ] After each inspection or rebolt, it may be worth having a 'review date' ie if the traffic / glue / metal is expected to last 10 years then set a reminder to review it at that point\r\n* [ ] are there any requirements from government 'asset management' stuff where local climbing groups are part of management plans and need to document risk management and mitigation?\r\n* [ ] From Neil: It would be good for the original bolting type to also be recorded (if known) as this is useful info for any problems that might occur in the future. (Brendan: ie an FA could enter this when they create the route, or anyone could go back and enter data for existing routes)\r\n"},"comment":{"url":"https://api.github.com/repos/theCrag/website/issues/comments/198668774","html_url":"https://github.com/theCrag/website/issues/1865#issuecomment-198668774","issue_url":"https://api.github.com/repos/theCrag/website/issues/1865","id":198668774,"user":{"login":"davidreeve","id":17944284,"avatar_url":"https://avatars.githubusercontent.com/u/17944284?v=3","gravatar_id":"","url":"https://api.github.com/users/davidreeve","html_url":"https://github.com/davidreeve","followers_url":"https://api.github.com/users/davidreeve/followers","following_url":"https://api.github.com/users/davidreeve/following{/other_user}","gists_url":"https://api.github.com/users/davidreeve/gists{/gist_id}","starred_url":"https://api.github.com/users/davidreeve/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/davidreeve/subscriptions","organizations_url":"https://api.github.com/users/davidreeve/orgs","repos_url":"https://api.github.com/users/davidreeve/repos","events_url":"https://api.github.com/users/davidreeve/events{/privacy}","received_events_url":"https://api.github.com/users/davidreeve/received_events","type":"User","site_admin":false},"created_at":"2016-03-19T08:42:15Z","updated_at":"2016-03-19T08:42:15Z","body":"I think we need to distinguish climbing-community-facing, from land-manager-facing, aspects of any sort of climbing infrastructure maintenance system we might consider. I think the Crag is clearly community-facing, whilst within the ACAQ we are necessarily manager-facing.\r\n\r\nI suspect this means we are looking at too different things, but that is not to say there should not be communication between them.\r\n\r\nAfter a few false starts going back some years, I believe the schema that suits the land-manager-facing application has to organised on a bolt by bolt, anchor by anchor basis. Bolts and anchors have to be independent of each other, as are all the bolts on any given route. The reason for this is that maintenance often occurs piece meal... fix an odd bolt here, part of an anchor there. Thus if you want to know the status of a particular route, you need to query for all the infrastructural components that comprise it and build a report. \r\n\r\nI've attached the schema for what I'm referring to as 'bolts_on_routes' or bolts currently installed on a cliff out there somewhere. The anchor situation uses similar tables, but is more complex due to the multiplicity of components that can comprise an anchor.\r\n\r\n[Database Schema.pdf](https://github.com/theCrag/website/files/180720/Database.Schema.pdf)\r\n\r\n\r\n"}}