Changing Project's Organization should be done in a batch process [#2239025]

Problem/Motivation

Changing Project's Organization needs an update on all the other entities that references it. This could potentially be time-consuming update. If there exists a lot of tasks/tickets under the project and a timeout occurs before the whole thing is converted, it would lead to a very unpredictable state.

Proposed resolution

Following idea comes to my mind.

1) Disallow direct changing of Organization in Project and provide a separate form for the same
2) Trigger a batch process on node submission.

Remaining tasks

Task not started

User interface changes

To be discussed

API changes

None

Comments

Comment #1

juliangb CreditAttribution: juliangb commented 14 April 2014 at 08:32

I agree that this could be useful longer term, but is it actually as critical as you've suggested?

I would have thought that whilst the node relationships would be messed up initially, making another change would then just settle it down. I'm not sure whether there are PM installations yet big enough for this to be a problem.

On a test of a PM installation with ~500 PM nodes, I just tried this and the update happened relatively instantly. Perhaps my server is fast enough?

Comment #2

D34dMan CreditAttribution: D34dMan commented 14 April 2014 at 09:27

I have not yet ran into this issue, but it does exists theoretically, and due to recent migration to field_api, it would occur sooner than it would have.

Maybe i am being paranoid...

Field API migration would bring tighter integration into drupal at the cost of performance. For example earlier almost all of the updates that triggered due to organization change where carried out by direct "database" manipulation. Now we would have to use "API's" to do the same. Also almost all the extra fields where stored in a single row in custom pm tables.

For example lets consider a project's organization changes.

1.) Hunt for all the nodes that references pmproject, then keep on recursively hunting for the nodes that references them.

2.) Once all the nodes are collected in the above step. Load the node and do a node_save(). This should adjust the permission.

Now this node_save() could also invoke other "hooks" in the system.

This could be tackled after we have migrated fully to fields api. Until then we wait for reports.