I prefer the term "Archive" over "Close". ________________________ @jdreimann - Twitter Sent from my phone
On 21 Feb 2013, at 10:33, Jure Zitnik <[email protected]> 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 <[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 >
