incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <j...@digiverse.si>
Subject Re: [Apache Bloodhound] #404: Populate default schema on product addition
Date Thu, 21 Feb 2013 10:33:37 GMT
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


Mime
View raw message