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ž Bradač wrote:
>> On 20. Feb, 2013, at 16:47, Olemis Lang wrote:
>> 
>>> On 2/20/13, Apache Bloodhound <bloodhound-dev@incubator.apache.org> wrote:
>>>> #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
>>>> ---------------------------+-----------------------------------
>>>> 
>>>> Comment (by matevzb):
>>>> 
>>>> 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 ...
>>> 
>>> ... 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 ticket
>> for the permission schemes.
> 
> +1 for populating permissions from "default values" (trac.db_default.get_data())
> 
> In my opinion that would also apply for other resources (components, versions, milestones...) that are product scope specific. All of these should be populated when adding a new product.
> 
> IMO the actual code that populates these resources should be implemented as a part of the admin module (in contrast to multiproduct.model.Product) as we might want to add additional logic in there in the future.
> 
>>>> 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?
> 
> In my opinion we should be talking about 3 separate operations - migrate, close and delete.
> 
> One is product migration, in this case all the resources in a specific product would be migrated (merged with) to another product. This would merge all resource of the product that's been migrated with the resources of the product the product is being migrated to. We haven't discussed this yet and is in my opinion out of scope at the moment.
> 
> The other operation would be product 'close' that would mark a specific product closed. This would keep all the resources within that products scope, no data would actually get deleted from the database. As a consequence one couldn'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.
> 
> The third one is product deletion. I don't think we need product deletion as an actual operation. If we actually decide to implement it, it should be rather drastic operation, resulting in all product resources being removed.
> 
> Cheers,
> Jure
>