Hi Ifo,
I agree it would be good to get it in early. The previous incarnation of
bloodhound felt like it suffered a bit from the 'shoehorning in' of supporting
multiple trackers.
Adding in a table and the initial api to allow for this is not likely to be
hugely difficult. Most of the work is making sense of the division that it
brings which to a large extent is about allowing some level of independence of
administration with split permissions being a particular focus.
One thing that I am not sure I have yet suggested to this list is that I am
interested in making it possible to host trackers on multiple servers while
being able to provide a unified view from the frontend. I don't think of this
as a replacement for the ability to host multiple projects from one server but
more of a complementary feature.
I am not sure there is much of a demand for issue tracking as a federated
service but I think it is worth exploring at some point.
As always, I would be happy to hear what others think.
Cheers,
Gary
On Wed, 20 Feb 2019, at 12:34 AM, Ifo Ikede wrote:
> Hi there,
>
> I am loving what i have seen so far, and i look forward to be able to the
> new improvements of the project ..
>
> Any suggestions of how best to account for the multi-project aspects, as
> the Api is laid out ..
> I am thinking of that is flushed out in the beginning, that would
> (theoretically ) reduce the amount of refactoring that would be needed when
> the multi-product features are added.
>
> cheers ,
>
> Ifo
>
> On Tue, Feb 19, 2019 at 4:29 AM Gary Martin <[email protected]> wrote:
>
> > Hi.
> >
> > Just a quick heads up. I'm going to be refactoring the api a bit shortly.
> > I'll be moving the api under an api/ path and trying to make use of a few
> > more features of the django rest framework.
> >
> > There may of course be a need for a further refactoring events to allow
> > for the multi-product like feature to be built in.
> >
> > This is roughly what I am looking at for the immediate changes (ignoring
> > the details of the available methods on each):
> >
> > * api/
> > * api/users/
> > * api/users/<userid>/
> > * api/groups/
> > * api/groups/<groupid>/
> > * api/ticketfields/
> > * api/ticketfields/<fieldid>/
> > * api/tickets/
> > * api/tickets/<ticketid>/
> > * api/tickets/<ticketid>/ticketevents/
> > * api/tickets/<ticketid>/ticketevents/<eventid>/
> >
> > The user and group models will at least initially come from
> > django.contrib.auth.models. We'll need to look at authentication again to
> > ensure that we are able to support this in a flexible manner.
> >
> > I am also not completely sold on the need for the ticketevents to be on a
> > subpath of the tickets but it might be helpful if it is a closer match to
> > the mental model of how tickets are structured.
> >
> > Cheers,
> > Gary
> >
>
>
> --
> ------------------------------------------------------
> Ifo Ikede
> Creating Wealthy, Healthy and Healing communities
> http://eblog.ifomation.com (401) 314-8436 [email protected]
> --------------------------------------
> p.s . Want free leads? you can get free unlimited free leads forever
> <http://ifomation.xyz>from http://ifomation.xyz
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
--
Cheers
Gary
