Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of joachim.dreimann@wandisco.com
 designates 209.85.212.174 as permitted sender)
Subject: Re: [Apache Bloodhound] #404: Populate default schema on product
 addition
References: <053.a1c93bf3c7b64d42cbd51bc0db874012@incubator.apache.org>
 <068.d85ffe78eac9cc807ae3237e716d74f4@incubator.apache.org>
 <CAGMZAuPhOmy7dC3qPh-Up_pqdy_V9ZicRsqjbJ0yYJMBV+HMBQ@mail.gmail.com>
 <27CC3605-DE24-4F6C-8F60-15E55F9E2524@gmail.com>
 <5125F801.9040705@digiverse.si>
From: Joe Dreimann <joachim.dreimann@wandisco.com>
Content-Type: text/plain;
	charset=utf-8
In-Reply-To: <5125F801.9040705@digiverse.si>
Message-Id: <B1E34A4B-2E67-45B0-A982-11DB1EAF0A65@wandisco.com>
Date: Thu, 21 Feb 2013 11:09:20 +0000
To: "bloodhound-dev@incubator.apache.org"
 <bloodhound-dev@incubator.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

I prefer the term "Archive" over "Close".

________________________
@jdreimann - Twitter
Sent from my phone

On 21 Feb 2013, at 10:33, Jure Zitnik <jure@digiverse.si> wrote:

> On 2/20/13 7:49 PM, Matev=C5=BE Brada=C4=8D wrote:
>> On 20. Feb, 2013, at 16:47, Olemis Lang wrote:
>>=20
>>> On 2/20/13, Apache Bloodhound <bloodhound-dev@incubator.apache.org> wrot=
e:
>>>> #404: Populate default schema on product addition
>>>> ---------------------------+-----------------------------------
>>>>  Reporter:  jure          |      Owner:  jure
>>>>      Type:  defect        |     Status:  assigned
>>>>  Priority:  major         |  Milestone:
>>>> Component:  multiproduct  |    Version:
>>>> Resolution:                |   Keywords:  bep-0003 multiproduct
>>>> ---------------------------+-----------------------------------
>>>>=20
>>>> Comment (by matevzb):
>>>>=20
>>>> A couple of things to consider with regards to permissions:
>>>> 1. Which "default values" should be taken into consideration?
>>>>   * the trac.db_default.get_data() ones - those populate the empty
>>>> database or
>>> IMO it's a whole new product , so it should have a whole new set of
>>> permissions created ... at least until we have a more advanced feature
>>> , namely permissions schemes (templates) . Those should be managed by
>>> Trac admins , and product (owners | admins) should just select
>>> available permission schemes from a list ...
>>>=20
>>> ... but that should be deferred until Release 3 , so better create a
>>> new ticket with a reference to #404
>> OK so the default set will be taken from trac's and I'll create a new tic=
ket
>> for the permission schemes.
>=20
> +1 for populating permissions from "default values" (trac.db_default.get_d=
ata())
>=20
> In my opinion that would also apply for other resources (components, versi=
ons, milestones...) that are product scope specific. All of these should be p=
opulated when adding a new product.
>=20
> IMO the actual code that populates these resources should be implemented a=
s a part of the admin module (in contrast to multiproduct.model.Product) as w=
e might want to add additional logic in there in the future.
>=20
>>>> 2. When deleting a product, the permissions (and possibly other data)
>>>> related that specific product should be deleted from db as well.
>>> IMO they should be moved somewhere else rather than deleted i.e. just
>>> like moving tickets when closing milestones .
>> Right, should the user be "forced" to move them to another product or did=
 you
>> have something else in mind?
>=20
> In my opinion we should be talking about 3 separate operations - migrate, c=
lose and delete.
>=20
> One is product migration, in this case all the resources in a specific pro=
duct would be migrated (merged with) to another product. This would merge al=
l resource of the product that's been migrated with the resources of the pro=
duct the product is being migrated to. We haven't discussed this yet and is i=
n my opinion out of scope at the moment.
>=20
> The other operation would be product 'close' that would mark a specific pr=
oduct closed. This would keep all the resources within that products scope, n=
o data would actually get deleted from the database. As a consequence one co=
uldn't use the product prefix of the closed product in the future but I don'=
t see this as a big drawback. The product would show up as inactive in admin=
 panel and would not show up in dashboard.
>=20
> The third one is product deletion. I don't think we need product deletion a=
s an actual operation. If we actually decide to implement it, it should be r=
ather drastic operation, resulting in all product resources being removed.
>=20
> Cheers,
> Jure
>=20