incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matevž Bradač <mate...@gmail.com>
Subject Re: [Apache Bloodhound] #404: Populate default schema on product addition
Date Wed, 20 Feb 2013 18:49:26 GMT

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.
OT: we really should start working on ticket relations, lots of incoming tickets
have some sort of relation to existing ones. =)

>>   * the permissions from the global scope in db (where product='')
>> 
> 
> -1

Agreed, especially when considering the schemes above.

> 
>> 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?

> 
> -- 
> Regards,
> 
> Olemis.

Thanks.

--
matevz
Mime
View raw message