[Trac-dev] Development on SimpleMultiProject

[Logan Anderson]

Hey guys,

This is my first time pinging the list so forgive me if this is in bad form or something. I'm looking to do some development work on SimpleMultiProject but I wanted to reach out and figure out the current status. It looks like this has been fairly quiet for a while and if I understand correctly it even appears the maintainer has stepped back from active development beyond hot fixes.

Does anyone have word on what's going on here? I'm just looking for an entry point on adding some new capabilities and I don't want to step on toes or duplicate effort.

I am a system administrator working into my first active development role so any suggestions/direction is appreciated.


Thanks,
Logan

[falkb]

Hi,
The state of SimpleMultiProjectPlugin is "good enough" for our company,
that's why there aren't planned further resources for more development.
Even in my spare time I don't really have time for it any more. I'd very
appreciate if the community kept developing on it.

My advice is to extend the official Trac by another standard ticket field
"project", and then this plugin could be simplified a lot because custom
fields are harder to handle. It really makes sense since I'm very sure most
use cases for Trac have more than 1 project, at least when used in
companies. I very recommend to put this new dimension "project" into
official Trac and extend timeline, projectplan, milestone, version and
newticket form for that additional ticket field. It's actually very easy.
The use case of having multiple Trac instances which needs to be combined
to a new meta Trac webinterface should be put on top of this, but having
the ability for multiple projects in one Trac instance should be default.
This feature together with an in-place editor of the ticket field viewer (I
mean without a separate "Change ticket" button) could be a real break
through for a new Trac version... ;-)

CU, ***@lk

[RjOllos]

Post by falkb
Hi,
The state of SimpleMultiProjectPlugin is "good enough" for our company,
that's why there aren't planned further resources for more development.
Even in my spare time I don't really have time for it any more. I'd very
appreciate if the community kept developing on it.

Do you have some preferences on the process for the community to continue
developing it? For instance, I might consider it to be valuable to have
Logan submit a few patches. I would be happy to help with committing those
patches if you give them a quick review and don't have time. After a few
patches are submitted, if they are up to quality standard maybe the
patch-submitter would be given commit access?

The Trac project has a guide to submitting patches. I've been intending to
revise it to describe how to work from GitHub or BitBucket.
https://trac.edgewall.org/wiki/TracDev/SubmittingPatches

- Ryan

[falkb]

Post by RjOllos
Do you have some preferences on the process for the community to continue

developing it?
I have full confidence if you guide it a bit in the way you suggest. I just
wish it'll still be cool if I update somewhen. :)
CU, ***@lk

[RjOllos]

Post by RjOllos
Do you have some preferences on the process for the community to

continue developing it?
I have full confidence if you guide it a bit in the way you suggest. I
just wish it'll still be cool if I update somewhen. :)

Thanks! So the path forward for anyone that wants to contribute is to
submit some patches and I'll try to give you some feedback. If the patches
look good we'll give you commit access.

I have some ideas on how to better support your request for a "project"
field without explicitly adding the field to Trac. I'll reply on that when
I have more time to investigate.

- Ryan

[Logan Anderson]

My initial design probably doesn't conform well and I was asked to reach out and develop a solution which would match the current Trac development path.

Initially I wrote my own plugin for managing ownership of whichever fields (in my case account, project, component) via a new table 'ownership' where conceivably any field could have an owner applied to a value. This plugin also allows fallback to the ownership of the previous field (eliminating generic owner Trac or no owner) when a component/project/etc is not selected. This also allowed me to add Account managers and Project managers to the CC list easily. However, I noted that the current design is for each field (so far only 1, component) to be given its own table in the DB. I have had discussion back and forth with those on my team with regards to the merit of different DB designs.

As far as I can currently tell, it appears that my plugin would contradict/break the upgrade path where a future enhancement would add a table called project which matches the design of the component table. Is it preferable I continue forward with the existing structure? Are there other dependencies on components being assigned their own table? Or could it be a logical change to use an 'ownership' table (or other name) which would build on depth where each field and value/option is given its own row in a single table? I am relatively new to developing formally and even more new to developing Trac, so I am uncertain just how deeply the dependency on component having it's own table runs as well as if there is a point I am missing about DB design which makes this inherently a better design.

Do you guys have opinions/preferences on which approach is better?


Thanks for your responses guys!



From: "RjOllos" <***@gmail.com>
To: "Trac Development" <trac-***@googlegroups.com>
Cc: ***@clacorp.com
Sent: Sunday, February 5, 2017 3:41:12 AM
Subject: Re: Development on SimpleMultiProject

Do you have some preferences on the process for the community to continue developing it?

I have full confidence if you guide it a bit in the way you suggest. I just wish it'll still be cool if I update somewhen. :)
CU, ***@lk




Thanks! So the path forward for anyone that wants to contribute is to submit some patches and I'll try to give you some feedback. If the patches look good we'll give you commit access.

I have some ideas on how to better support your request for a "project" field without explicitly adding the field to Trac. I'll reply on that when I have more time to investigate.

- Ryan

[falkb]

Post by Logan Anderson
As far as I can currently tell, it appears that my plugin would

contradict/break the upgrade path where a future enhancement would add a
table called project which matches the design of the component table.

I don't get that at all, please, describe in other words.

SimpleMultiProjectPlugin just adds a db table for all projects, and
furthermore it adds several db tables for mapping, that is milestone to
projects, versions to projects, components to projects. This shouldn't have
to do with any other permission plugins.

BTW: If original Trac supported the standard field "project", no additional
mapping tables would be necessary, instead we would just extend the
standard tables of milestone, version and component by a new column
"project".

CU, ***@lk

[Logan Anderson]

That's probably because my understanding is limited AND I am mixing the systems I am talking about.

I wrote my own plugin. I realize that the component table is part of Trac core. My initial question pertained to SimpleMultiProject but I may be quickly getting off topic. Again, partly because my understanding is limited and partly because I have other members of my team pointing me five different directions. This is part of why I have reached out to you guys to set me straight.

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?

Or perhaps I am confused and it is just that SMP currently relies on the current design of component as its own table?

For original Trac to support the field 'project', that would currently dictate a new table in the DB called 'project', correct?

What other functionality is reliant on 'component' having it's own table? How significant of a change would it be to alter this?

Is there a design reason we chose to give component its own table? Could this instead come from a table where all fields and values are a composite key similar to the design for certain other tables?

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.





From: "falkb" <***@baumer.com>
To: "Trac Development" <trac-***@googlegroups.com>
Cc: "RjOllos" <***@gmail.com>, ***@clacorp.com
Sent: Tuesday, February 7, 2017 2:37:46 AM
Subject: Re: Development on SimpleMultiProject

Post by Logan Anderson
As far as I can currently tell, it appears that my plugin would contradict/break the upgrade path where a future enhancement would add a table called project which matches the design of the component table.

I don't get that at all, please, describe in other words.

SimpleMultiProjectPlugin just adds a db table for all projects, and furthermore it adds several db tables for mapping, that is milestone to projects, versions to projects, components to projects. This shouldn't have to do with any other permission plugins.

BTW: If original Trac supported the standard field "project", no additional mapping tables would be necessary, instead we would just extend the standard tables of milestone, version and component by a new column "project".

CU, ***@lk

[falkb]

Hi Logan,

Post by Logan Anderson
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.

Post by Logan Anderson
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.

Post by Logan Anderson
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.

Post by Logan Anderson
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?

Post by Logan Anderson
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?

Post by Logan Anderson
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.

Post by Logan Anderson
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, ***@lk

[Logan Anderson]

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" <***@baumer.com>
To: "Trac Development" <trac-***@googlegroups.com>
Cc: "falkb" <***@baumer.com>, "RjOllos" <***@gmail.com>, ***@clacorp.com
Sent: Tuesday, February 7, 2017 10:38:33 AM
Subject: [BULK] [Trac-dev] Re: Development on SimpleMultiProject

Hi Logan,

Post by Logan Anderson
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.

Post by Logan Anderson
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.

Post by Logan Anderson
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.

Post by Logan Anderson
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?

Post by Logan Anderson
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?

Post by Logan Anderson
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.

Post by Logan Anderson
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, ***@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+***@googlegroups.com .
To post to this group, send email to trac-***@googlegroups.com .
Visit this group at https://groups.google.com/group/trac-dev .
For more options, visit https://groups.google.com/d/optout .

[falkb]

Hi Logan,
don't hesitate to ask when you've got questions. We always support
developers who want to contribute to the Open Source community. It's
important to keep it going. :-)
Good luck with your patching the SMP plugin!

Post by Logan Anderson
I think your questions have answered my questions ;) Let me think this
over rather than harass you guys more.
Thank you very much,
Logan
------------------------------
*Sent: *Tuesday, February 7, 2017 10:38:33 AM
*Subject: *[BULK] [Trac-dev] Re: Development on SimpleMultiProject
Hi Logan,

Post by Logan Anderson
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.

Post by Logan Anderson
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.

Post by Logan Anderson
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.

Post by Logan Anderson
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?

Post by Logan Anderson
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?

Post by Logan Anderson
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.

Post by Logan Anderson
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).
--
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
<javascript:>.
Visit this group at https://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/d/optout.

[Logan Anderson]

If/when I come up with something of value, I will definitely contribute. I appreciate all your support and I look forward to being an active member of the community.

Thanks guys :)


From: "falkb" <***@baumer.com>
To: "Trac Development" <trac-***@googlegroups.com>
Cc: "falkb" <***@baumer.com>, "RjOllos" <***@gmail.com>, ***@clacorp.com
Sent: Tuesday, February 7, 2017 5:03:17 PM
Subject: Re: [BULK] [Trac-dev] Re: Development on SimpleMultiProject

Hi Logan,
don't hesitate to ask when you've got questions. We always support developers who want to contribute to the Open Source community. It's important to keep it going. :-)
Good luck with your patching the SMP plugin!
CU, ***@lk

On Tuesday, 7 February 2017 19:15:45 UTC+1, Logan Anderson wrote:


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" < ***@baumer.com >
To: "Trac Development" < ***@googlegroups.com >
Cc: "falkb" < ***@baumer.com >, "RjOllos" < ***@gmail.com >, ***@clacorp.com
Sent: Tuesday, February 7, 2017 10:38:33 AM
Subject: [BULK] [Trac-dev] Re: Development on SimpleMultiProject

Hi Logan,

Post by Logan Anderson
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.

Post by Logan Anderson
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.

Post by Logan Anderson
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.

Post by Logan Anderson
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?

Post by Logan Anderson
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?

Post by Logan Anderson
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.

Post by Logan Anderson
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, ***@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+***@googlegroups.com .
To post to this group, send email to ***@googlegroups.com .
Visit this group at https://groups.google.com/group/trac-dev .
For more options, visit https://groups.google.com/d/optout .