add 'sub-project/tranche' field to projects

Some project occur not only over long periods of time, but also in phases or 'tranches'. It would be helpful if we could add a variable to help keep track of different sub-projects or tranches

https://crossculturalconsult.com/en/admin/projects/project/?o=-1

Please refer to this field as Sub-Project / Tranche

Adding a "sub project/tranche" field as an arbitrary text field is not a problem and will just take a few minutes. Is that what you are asking for here? I don't think so...

If the project has phases, they need to have some meaning beyond a simple text field.

Presumably the project may be 'broken down' into a series of smaller projects. Thus a project has a one-to-many optional relationship with other projects - a super_project/sub_projects relation.

If there are sub projects, the from_date and to_date of the super_project are defined as the earliest from_date and latest to_date of the sub_projects. Super_project many-to-many fields (cccs_subthemes, cccs_subsectors, ifc_subthemes, and ifc_sectors) would need to include all of the sub_project relations.

Attempts to set these fields directly through a form interface on a super_project would need to be prevented by making them read_only. The super_project fields are really caches but as the data is 'read often, write rarely', it will make sense to implement them such that when a project is saved, its super_projects (if any) are automatically updated.

The CVProject would remain unchanged although ideally it should be enhanced to constrain the from_date and to_date such that they are within the from_date/to_date of the linked project (at least when set).

Where we aggregate projects (by theme, by sector, etc.), we probably want to exclude sub_projects so that only root_super_projects are listed (that is, super_projects that are not sub_projects). The project page can link to sub_projects and link to its super_project (if any).

Is the super/sub_project relation one-to-many? One-to-many implies a strict hierarchy such that a sub_project can only have one super_project (which would be the implemented relation). I can conceive of projects where one would really want many-to-many. For example, if I'm servicing both our cars, the 'service corrolla', and the 'service kluger' project might share a 'clear car port' sub_project. Many-to-many is more complex but may be a better reflection of reality.

Overkill?

If not, there is quite a bit of work here but I can probably accomplish it in under a day.

Presumably the project may be 'broken down' into a series of smaller projects. Thus a project has a one-to-many optional relationship with other projects - a super_project/sub_projects relation.

Correct. Projects should have a one-to-many relationship, but the names of sub-components might not be unique. For example:

Tangguh LNG Project
- Social Impact Assessment
- Lender's Due Diligence M&E Visit
Weda Bay Nickle
- Social Impact Assessment
- Cultural Heritage Management Plan
SMI
- Cultural Heritage Management Plan
- Lender's Due Diligence M&E Visit

These shared named have no relationship to one another. They simply described sub-project component activities.

If there are sub projects, the from_date and to_date of the super_project are defined as the earliest from_date and latest to_date of the sub_projects.

Currently the dates for the project are drawn from the consultant CVs. We don't know that much information about non-CCCS projects (and being able to differentiate CCCS vs non-CCCS projects is why I opened issue #39 a while back). At the moment, we are largely guessing about the dates for any project. Thus, if a consultant wishes to add a 'sub project component' for a date that is earlier or later than the current given date range, that master project should automatically push back or forward its date range vaules. In other words, the consultant CV entries should dictate, to a large extent, the attributes of any given project.

Super_project many-to-many fields (cccs_subthemes, cccs_subsectors, ifc_subthemes, and ifc_sectors) would need to include all of the sub_project relations.

Correct. If a consultant chooses to add in a sub-project, then the values assigned for theme, sector, etc within the sub-project would affect the description of the master project. This is actually a fairly critical bit of clarification, as some sub-project components may appear quite different than the main project description. By seeing that someone was working on a 'cultural heritage assessment' for a mine, I can easily understand why that mine would have the thematic designation of 'social protection', whereas I could not readily understand that otherwise.

Where we aggregate projects (by theme, by sector, etc.), we probably want to exclude sub_projects so that only root_super_projects are listed (that is, super_projects that are not sub_projects). The project page can link to sub_projects and link to its super_project (if any).

Assuming that a sub-project is automatically updated / inherit sub-project values, then yes, exclusion is fine. Thus, presentation of CCCS project experience would should only 1 'Weda Bay' project, not 5. Within each "consultant CV" line, however, sub-projects are critical. In 2009 I was working on WBN BFS-ESHIA. In 2011, I was working on WBN FTMP-LS. These are 2 "different" gigs (separate managers, separate topics, etc) all under the context of one development project (a nickle mine).

I don't use github email notifications; their notification system is cool (Its accessible at the top of the github page) and collates my notifications by repository. As well as keeping things organised, this saves concerns about edits to comments ;)

Project naming

Allowing different projects to have the same name is a big change. We're saying that a project is to become uniquely defined by its super_project and its name. We're also implying that the sub_project's name must be unique among its siblings.

Thus moving a sub_project could result in its name becoming invalid (or the operation being prevented until it is renamed). From the modelling perspective, keeping the project name unique is much simpler but we can use super_project/name.

If we reference a sub_project we'll need to use a display name that comprises of its super_project name (which may itself be composed of its super_project name...) as well as its own name to disambiguate it (e.g. in a CV list). This could result in very long 'unambiguous names' (necessitating a project abbreviation field?).

Date extending

I will give the CV date entry precedence but this may have (rare) confusing impact: If a CV references a super_project and sets a date that extends the current date range then the first or last matching sub_project date will need to be modified. The actual affected sub_project cannot be determined reliably. This wont be a problem if we force CVs to only reference 'leaf' projects (projects with no sub_projects) but that might feel too arbitrary. In practice I don't think this will be a problem.

CV referencing projects

I was assuming a CV can reference any project and this will be displayed as is. Thus a user may reference a super_project or a sub_project (including multiple sub_projects of the same super_project).

Terminology and precis

A project may be a 'super_project' of other projects.
A project may only have one super_project.
A project that does not have a super_project is known as a 'root_project'
A project that has a super_project is known as a 'sub_project'.
A sub_project that is not a super_project is known as a 'leaf_project'
Project lists are generally restricted to listing root_projects.
CVs may continue to list any project.
Presentation of a project may include links to its super_project and sub_projects as appropriate.
A project name is now unique only among its siblings. This includes other root_projects or other sub_projects as appropriate.
A project must have an abbreviation.
A project's 'unambiguous_name' uses its chain of super_project abbreviations for disambiguation (e.g "WedaBay/Social Impact Assessment").
CV project presentation will use the project's unambiguous_name.
An attempt to move a project such that its name would become invalid will be prevented.

_PLEASE NOTE: Not every project (root) will have a sub-project (leaf). _

Project naming

Allowing different projects to have the same name is a big change. We're saying that a project is to become uniquely defined by its super_project and its name. We're also implying that the sub_project's name must be unique among its siblings.

We are not allowing different projects to have the same name. We are allowing projects to have child projects (components). These components may have the same/similar names, but they only exist within the context of one project.

Thus moving a sub_project could result in its name becoming invalid (or the operation being prevented until it is renamed). From the modelling perspective, keeping the project name unique is much simpler but we can use super_project/name.

We would never move a sub project. A subproject only exists within the context of a project. We would not, for instance, move the Weda Bay "Social Assessment" component to Tangguh. The "Social Assessment" for Tangguh is always and only for Tangguh.

If we reference a sub_project we'll need to use a display name that comprises of its super_project name (which may itself be composed of its super_project name...) as well as its own name to disambiguate it (e.g. in a CV list). This could result in very long 'unambiguous names' (necessitating a project abbreviation field?).

I am not sure where this would come into play. I am more concerned about how the consultant would choose to add in a sub-project when none is defined. Let's say, for instance, that we started by creating the project "Weda Bay Nickel" for my CV. A couple of years later, we now have 3 contracts with "Weda Bay Nickel" (a mining project in indonesia). Now when I am adding in information to my CV, I cannot pick 3 times "Weda Bay Nickel" and add 3 different contract ID values and 3 different time periods. I have to tell the system that I want to define a sub project. How to manage the additions of sub-projects effectively, to me, seems more challenging than whether or not we use an acronym to abbreviate the parent project somewhere.

Date extending

I will give the CV date entry precedence but this may have (rare) confusing impact: If a CV references a super_project and sets a date that extends the current date range then the first or last matching sub_project date will need to be modified.

Both the CVs (and the sub projects) need to end up changing the super. CVs should modify sub-projects (where given), and sub-project, in turn would extend the date range of the project. Everything should trickle back from the CVs, which is where consultants will be adding new data into the system.

[I am expecting that in most cases, the definition of new new sub-projects will occur when consultants are adding records to their CVs.]

If you look at the dates the consultants were working on 2 different sub-projects in the current data, one might have been on the project in 2002 and another in 2004. Some projects go on for 50 years. Without looking up the details, in such a situation, the date range should be drawn from the consultant CVs, and should read 2002-01-01 to 2004-12-31. These ranges would start from the consultant date range, affect subproject, then affect super. Where 3 consultants have different values for subproject, then the oldest and most recent values extend the range.

The only 'trick' is allowing us to set a range for super manually, and having this range extend automatically if a values outside of whatever it is set at is entered into the system.

The actual affected sub_project cannot be determined reliably.

Why not? If a consultant chooses and existing sub-project (I was working on WBN BFS-ESHIA) then it is 100% clear what the actual sub-project is.

This wont be a problem if we force CVs to only reference 'leaf' projects (projects with no sub_projects) but that might feel too arbitrary. In practice I don't think this will be a problem.

This makes no sense to me. The whole point of this is to allow consultants to disambiguate which aspects / component of a parent project they were working on. What I think should happen is that first a consultant selects a project, and if that is all that they're worried about, then fine. If the consultant wishes to add a sub-project, there should be some "add" button allowing them to do so, just like they can add a new project. If the consultant chooses a project that already has sub-projects, then they should be presented with options saying "choose one of these or add a new one"

CV referencing projects

I was assuming a CV can reference any project and this will be displayed as is. Thus a user may reference a super_project or a sub_project (including multiple sub_projects of the same super_project).

I don't entirely follow you here. Currently there is no distinction, so we have multiple entries at times for "projects" that actually belong together. Weda Bay Nickle is one example, but I saw a few others where consultants were talking about "scoping missions" and "appraisal mission", but there were for the same project. The whole point of this is to eliminate those forms of "duplication".

Terminology and precis

A project may be a 'super_project' of other projects.

A 'project' is always a 'super', but may have children (sub-project components / tranch)

A project may only have one super_project.

A sub-project components (or tranche) may only belong to one project, the names of sub-project components are usually very standard and therefore the same sub-project component name may be used in numerous projects.

A project that does not have a super_project is known as a 'root_project'

Ok, but then all projects are 'root' projects, and no sub-projects can be root projects

A project that has a super_project is known as a 'sub_project'.

A sub-project is a sub-project, and it belongs to a "root project"

A sub_project that is not a super_project is known as a 'leaf_project'

Ok. A sub-project is a "leaf project" and a project is a "root project"

Project lists are generally restricted to listing root_projects.

By "lists" I assume you mean sector, theme, etc. In this case yes. CVs, however, will need to deal with "leaf projects"

CVs may continue to list any project.

Yes, CVs will need to deal with "leaf projects"

Presentation of a project may include links to its super_project and sub_projects as appropriate.

yes.

A project name is now unique only among its siblings. This includes other root_projects or other sub_projects as appropriate.

This depends on how we enforce naming. Root project name will always be unique. Sub projects (when entered by consultants) will very likely be entered using similar names (Social Impact Assessment) following common names of interventions in the field of 'social development.' We could enforce a re-name that adds a value derived from the related root project name. Thus "Weda Bay Nickle" (root) "Social Impact Assessment" (leaf) becomes 'WBN Social Impact Assessment' (re factored unique leaf).

A project must have an abbreviation.

No. But it would be handy to be able to define abbreviations for projects

A project's 'unambiguous_name' uses its chain of super_project abbreviations for disambiguation (e.g "WedaBay/Social Impact Assessment").

For a sub-project (leaf), yes

CV project presentation will use the project's unambiguous_name.

ok.

An attempt to move a project such that its name would become invalid will be prevented.

there will never be a case to move a sub project "leaf". it depends on its parent project. [I suppose there could be a rare case where someone creates a duplicate project and sub project, then adds in a ton of material to a sub project that we want to transfer over to the other root. we could deal with such a case when the time comes, but i expect that the quickest route would be just to copy the database table values across the leafs and then to delete the unwanted duplicate]

I think we need to talk about this. I think you are viewing the sub_project as somehow fundamentally different to a project with no possibility of it having further sub_projects. I was viewing this as a change to that allows any project to be a sub_project such that there could be an arbitrary tree of projects. I was not introducing a new object type, I was thinking of extending the project type.

Both solutions are feasible and have their pros and cons so I think a discussion will be the best next step.

We spoke about this on the phone; we agreed to try to have the sub-projects as movable, and to define some sort of prefix (like wbn for weda bay nickel). Please carry this one forward when you have time.

Reviewing this and aiming to make it as simple as possible:

I've added a 'sub-project/tranche' field (subproject) to CVProject. This links a sub-project entity that just has a name.

The admin user may specify an optional sub project on the CVProject (or add a new one and specify that - the add new form is a bit clunky because of our potentially huge project names but I've left it at the defaults for now: adding the sub-projects under the project in admin is quick and easy).

The sub-project is displayed when appropriate

on the CVProject detail under the CV
under the project details
in the associate list under the projects.

I note that there is potential for a user to want to associate more than one of the sub projects with their CV. This should be done by adding another CVProject entry - that way all the dates and stuff will make sense - this is why I've kept it so simple for now.

I've deployed this to live (because of the priority) and merged it into my local staging so it will appear in staging on the next staging deployment.

Sorry for making the discussion more complex than it needed to be and thanks for your patience.

I think this should do the job without making things too complicated for you or for Marcus. Close if you are happy (we can add more features for the sub-project etc. as future issues if and when you need them).

Hi Paul; meet Min. Min will be helping us to continue our work on the CV database while we focus you on the Document Manager and GitWeb.

Min: Please read through this exchange. We remain a bit far away from our target, which is to allow the creation of child project that can work to extend the parent.

A parent should:

1) be able to stand as an independent unit 2) be able to accommodate changes made in children (date range; categorization; attribute tags)

A child should:

1) be counted within the parent 2) be able to extend the parent (date range; categorization; attribute tags) 3) contain fully independent information (all associated data fields)

cccs-web / core