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 <[email protected]> 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
