I think your questions have answered my questions ;) Let me think this over rather than harass you guys more.
Thank you very much, Logan From: "falkb" <fbrettschnei...@baumer.com> To: "Trac Development" <trac-dev@googlegroups.com> Cc: "falkb" <fbrettschnei...@baumer.com>, "RjOllos" <rjol...@gmail.com>, lander...@clacorp.com Sent: Tuesday, February 7, 2017 10:38:33 AM Subject: [BULK] [Trac-dev] Re: Development on SimpleMultiProject Hi Logan, Logan Anderson wrote: > What controls the feature where an owner is assigned to a component? My > understanding was that this was closely tied with functionality within SMP, > am I mistaken? This is supported by standard Trac. Each 'component' can have an 'owner' in a standard Trac. SMP only adds the mapping of a component to projects. > Or perhaps I am confused and it is just that SMP currently relies on the > current design of component as its own table? Yes, 'component' is an own table of standard Trac. Since SMP adds a table of projects, it also manages an own mapping db table that holds the information which component is used in which project. > For original Trac to support the field 'project', that would currently > dictate a new table in the DB called 'project', correct? Yes, that's the idea of it. A db table holding the names of projects and an ID for each project. > What other functionality is reliant on 'component' having it's own table? How > significant of a change would it be to alter this? Not sure what you mean. All components are hold in a standard Trac db table, already. What change are you talking about? > Is there a design reason we chose to give component its own table? Each resource type of Trac should have its own table, just a list of which instances exist. Why do you doubt that? > Could this instead come from a table where all fields and values are a > composite key similar to the design for certain other tables? Not sure what you mean. > The plugin I was writing was designed to be capable of assigning ownership to > any/all fields and their values similar to how the component ownership > currently works. But I was asked to look into a better solution as it would > conflict with the existing mechanism for configuring ownership for a > field/value. I was told SMP had been considering such a change in the future > to add this functionality to 'project'. Beyond that, I may be completely > mistaken on my original question. This is me attempting to do discovery. > Sorry if I was waaaay off. Please, define your term 'ownership'. Standard Trac already provides to set an owner for each component. Is it that what you mean? Or do you mean permissions for access? SMP provides to set permissions for its projects, which means you can restrict a project to a user group, in a way only the allowed users can see the project and its resources (like tickets for instance). CU, F@lk -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-dev+unsubscr...@googlegroups.com . To post to this group, send email to trac-dev@googlegroups.com . Visit this group at https://groups.google.com/group/trac-dev . For more options, visit https://groups.google.com/d/optout . -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-dev+unsubscr...@googlegroups.com. To post to this group, send email to trac-dev@googlegroups.com. Visit this group at https://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
