PMOrganization: Migrate to field_api based fields.

Aren't there also a lot of fields which we could declare with pm and then just use instances of these for the different pm content types?
I'm talking about fields like price and duration which are used by a lot of pm content types.

I made a list with all fields which occur in more than one pm module:

• pricemode (organization/project/task/ticket)
• price (organization/project/task/ticket)
• currency (organization/project/task/ticket)
• datebegin (project/task/ticket)
• dateend (project/task/ticket)
• durationunit (project/task/ticket)
• duration (project/task/ticket) (also timetracking, but not exactly the same)
• billable (project/task/ticket/timetracking/expense)
• billed (project/task/ticket/timetracking/expense)
• email (organization/project)
• www (organization/project)
• phone (organization/project)
• assigned_nid (project/task/ticket)
• assigned_title (project/task/ticket)
• amount
• tax1 (expense/invoice)
• tax2 (expense/invoice)
• total (expense/invoice)

Maybe we could also handle the TYPEcategory, TYPEstatus and TYPEpriority fields differently.

Edit:
Also, instead of using checkboxes for billed and billable, we could use a dropdown with the values not billable, billable and billed (I don't think there is a usecase, where something is billed but not billable).

Could I propose that we start with pm note? I think the selection of fields is simpler and a good place to demonstrate a proof of concept.

I just looked, what fields in pmnote we could migrate, but the only fields are organization_nid, project_nid & task_nid.

But if we want to declare the entity references in their respective modules (organization_nid in pmorganization, ...) we can't really start with pmnote.
And there are no other fields to convert in pmnote.

So, I guess we have to start with pmorganization, even if it is a pretty big one.

#6 is pretty much what I was thinking.

The challenge is to split this functionality into distinct chunks that make sense, but also allow us to start testing.

I think once we start testing patches there will be things that we realise that will help guide the change across the remaining modules.

Ok, that makes sense.

Then we should start by creating the entity reference fields for organization, project and task.
After that, we can start migrating pmnote.

Should we open a new issue for the reference fields?

I created a field for pmorganization_nid.
I named it pmorganization_ref since it is a entity reference.

It's actually pretty easy. After reinstalling pm & pmorganization the field appears correctly in the database in the field_config table.

I also added a dependency for entityreference to the pm module.

Edit: Useful information for creating entityreference fields: Adding entityreference fields programmatically

Yes, but it should also be in hook_install, otherwise the field won't be created for people who newly install the module. They won't run an update.

The test seems to be failing because entityreference is not enabled in setUp().

I added it in the pm & pmorganization test, the other modules might still fail the test.

Also added the field to hook_update_N.

Strange, if I run the tests on my local installation, they pass the tests.
I don't know what's causing the tests to fail...

This is the testbot's fault - it caches dependencies and so doesn't pick up the new dependency in this patch.

Let's review manually, and once we get to wanting to commit we can commit the dependency then test the patch, to show it passes on d.o. too.

I tried applying patch. In terminal, usually when I run the ' git apply ' patch command it comes back and tells that the patch applied cleanly. It did not do that for this patch. After aplying it just came back to command line, so it seemed work...

@dbt102 Could you try git apply -v [filename]? It will give more details about whether it was ok or not.

Ok, I removed the entityreference from setUp() in the tests and ran them again.

They all passed with this patch.

Had to install Entityreference module and enabled both of them, and this had a dependency on Entity module as well, so enabled both of them.

After I had the additional dependencies loaded then update.php completed OK.

Testing.... seems to work OK. Created new organization and filled in all fields and saved OK.

Edit: This per patch in comment #14

This patch doesn't actually change anything at the functionality of pmorganization at the moment, it only creates the field at installation/update.

But to see if it really worked, you can check out the database.
In the table field_config you should see an entry with the field_name pmorganization_ref and you should also see the tables field_data_pmorganziation_ref and field_revision_pmorganziation_ref.

OK ... Thanks ... I see them all

As julian wrote in #17, it's because the dependencies are cached and you have to commit the depencency first.
In the patch in #13 I added the modules to the testcase and it didn't work.

I was testing this today with the intention of creating field instances and testing moving data between them, but after successfully applying the patch I did not see these fields on the "existing fields" drop down on the "manage fields" page of a content type.

Are these fields only usable if we create field instances in code?

The next steps for these patches are really to implement specific instances of them. I'm happy to commit a dependency when we're close to being ready.

I just tested this myself.

I guess, "Add existing field" only shows fields with existing instances.
But when I created an instance of pmorganization_ref in pmproject, the new field showed up on pmproject and was also available in other content types (e.g. pmtask).

I only had to add this code and it already worked:

$instance = array(
  'field_name' => 'pmorganization_ref',
  'entity_type' => 'node',
  'bundle' => 'pmproject',
  'label' => 'Organization NID',
  'widget' => array(
    'type' => 'options_select'
  )
);
field_create_instance($instance);

#20: 2041659-pmorganization_ref-17.patch queued for re-testing.

Patch failed. (Did you know that it would?) Here is terminal output...

ubuntu:$ git reset --hard
HEAD is now at b493b60 Add date dependency to dev

ubuntu:$ git pull origin
Already up-to-date.

ubuntu:$ git apply -v 2041659-pmorganization_ref-17.patch
Checking patch pm.info...
error: while searching for:
configure = admin/config/pm
files[] = pm.test
dependencies[] = views

error: patch failed: pm.info:5
error: pm.info: patch does not apply
Checking patch pmorganization/pmorganization.install...

This patch won't apply because the dependency has already been committed to the .info file.

NB: Project tests are still failing due to cached dependencies: https://drupal.org/project/pm/testing-status

I'm going to give this some more time before trying to get some help to refresh them.

Opened issue #2059443: Rebuild Project Management 7.x-1.x dependencies to try to get the testing issue fixed.

Project tests issue is fixed, so test results are through. This patch no longer applies unfortunately as reported in #31.

I'd suggest we commit the relevant dependencies to 7.x-1.x so that the testbots can be happy - that will speed our own reviews.

Here's a functional review based on testing the patch - not yet read through the latest code:

1. On running update.php, no descriptions are shown for any of the 3 updates due to be run (I thought these were there before).
2. I don't think the customer provider, and active flags should be in a single field - they are quite different so I think they should be separate. I think active should be a separate yes/no.
3. Could the human name of the fields not be prefixed with "Organization"? That should help with sharing fields across content types where possible, which then helps with views etc.
4. Could the order of the fields (in the edit view) be the same as before? Name should be top, note should be bottom.

Further testing of this, I got some issues where looking at other node content types having done this migration caused errors to come up. The reason was that the pmorganization table didn't exist anymore.

I'll test update descriptions again. They were definitely missing when I expanded the fieldset, not sure why.

Flags/tags - i'm open to different views, but it sounds like being able to do a binary filter would be helpful.

By the way, is it most helpful for me to continually test the feature/pmperson branch providing frequent comments on anything I see - is there anything else that would be helpful for me to do?

OK, I will continue to test pmperson, pmteam and pmorganization only for now.

Good point on anything that we can do to avoid doing things multiple times. Perhaps we should have a general rule that given the immense nature of these changes we will try to mimic the existing custom fields as much as possible with the field api, and then if anything doesn't make sense, open an issue to potentially change later (for example, the realisation that teams can contain organisations, which doesn't make sense to me). That way we should keep the reviews relatively technical only.

By the way, I committed the necessary dependencies to 7.x-1.x, so once the -dev releases regenerate these tests should pass.

Add link to parent issue.

@D34dMan

On line 168 of pmorganization/includes/pmorganization.migrate.inc there is a reference to an undefined variable $oid.

We may have discussed this previously (if so, I apologise), but could we quickly run through the functionality provided by the organization members field? A summary of what it replaces, and anything it drives would help me review.

Done (near enough). Remaining tasks will be created as separate issues.