{"action":"opened","issue":{"url":"https://api.github.com/repos/HTBox/allReady/issues/809","repository_url":"https://api.github.com/repos/HTBox/allReady","labels_url":"https://api.github.com/repos/HTBox/allReady/issues/809/labels{/name}","comments_url":"https://api.github.com/repos/HTBox/allReady/issues/809/comments","events_url":"https://api.github.com/repos/HTBox/allReady/issues/809/events","html_url":"https://github.com/HTBox/allReady/issues/809","id":158666905,"number":809,"title":"Add initial Itinerary DB Model schema","user":{"login":"stevejgordon","id":3669103,"avatar_url":"https://avatars.githubusercontent.com/u/3669103?v=3","gravatar_id":"","url":"https://api.github.com/users/stevejgordon","html_url":"https://github.com/stevejgordon","followers_url":"https://api.github.com/users/stevejgordon/followers","following_url":"https://api.github.com/users/stevejgordon/following{/other_user}","gists_url":"https://api.github.com/users/stevejgordon/gists{/gist_id}","starred_url":"https://api.github.com/users/stevejgordon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stevejgordon/subscriptions","organizations_url":"https://api.github.com/users/stevejgordon/orgs","repos_url":"https://api.github.com/users/stevejgordon/repos","events_url":"https://api.github.com/users/stevejgordon/events{/privacy}","received_events_url":"https://api.github.com/users/stevejgordon/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-06-06T12:35:24Z","updated_at":"2016-06-06T12:35:24Z","closed_at":null,"body":"In order to persist itineraries into the database we need some additional models to define the database schema and the relationships.\r\n\r\nI'm proposing at this stage we create an Itinerary model which stores the date an itinerary is scheduled to occur. An event can have 0 or more itineraries.\r\n\r\nI propose we then have a many to many relationship between requests and itineraries. Whilst we should only allow a request to be attached to one future itinerary we may have cases where a request in itinerary 1 is not completed (home owner not available for example). In that case an org admin will need to be able to link the request to a new itinerary.\r\n\r\nI propose we leave the request linked to the original (in the past) itinerary for tracking purposes.\r\n\r\n@OhMcGoo @tonysurma @MisterJames - A few questions\r\n\r\n1. Does this sound reasonable to you all and meet the business rules? \r\n2. Would being able to create a friendly name an itinerary be a useful feature (i.e. Zone X installations)?\r\n3. When assigning volunteers as part of the team for the itinerary, would it be useful to be able to define additional properties such as the role(s) they will perform? (i.e. Installer) or should we assume that based on the task they're assigned against? I'm thinking a join table which holds this and any other information might be useful?\r\n\r\nI've started work on this locally while I experiment with an itinerary creation process. "}}
{"actor":{"display_login":"stevejgordon"}}