I think you can keep the entry points and Webhook model exactly how it is now. I am thinking of just changing the admin form so that instead of one page to manage all your webhooks, you go to a Webhook admin form per app. You would still be able to have 3rd-party webhooks associated with any app.
Changing the admin pages as I described I think would actual be more natural, at least for now. We only have one type of webhook currently so a page to manage all of them isn't too useful. (We could add/restore it later). Since a user creates a webhook and associates it with a specific app, I think a per-app configuration page would be fine. Lastly, while webhooks are very cool I don't think they warrant the prominence of a left-nav menu item on the admin pages. A little more "hidden" under the tool config area would be just fine. --- ** [tickets:#4542] Implement webhooks** **Status:** in-progress **Milestone:** unreleased **Labels:** sf-current sf-8 42cc **Created:** Fri Jul 13, 2012 02:55 PM UTC by Dave Brondsema **Last Updated:** Tue Feb 10, 2015 11:25 PM UTC **Owner:** Igor Bondarenko We should have webhooks, compatible with github & bitbucket. I don't see a spec for SCM webhooks anywhere. --- Sent from forge-allura.apache.org because [email protected] is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
