Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Migrate all custom fields declared by pmtask to field_api based fields. Also declare a field that other could use to reference pmtask.
Fields to be migrated are:
Status: DRAFT (not yet agreed upon field types and name.)
- currency to pmtask_currency (select list)
- pricemode to pmtask_pricemode (select list)
- price to pmtask_price (text field)
- durationunit to pmtask_durationunit (select list)
- duration to pmtask_duration (text field)
- body to body (migration code pending)
- datebegin/dateend to pmtask_date (date)
- organization_nid/title to pmorganization_ref (entityreference)
- project_nid/title to pmproject_ref (entityreference)
- parent_nid to pmtask_parent_ref (entityreference)
- assigned_nid/title to pmperson_assigned_ref (entityreference)
- billable to pmtask_billable (check box)
- billed to pmtask_billed (check box)
Fields needed to be declared by pmproject but not used.
- pmtask_ref
- pmtask_parent_ref
Points to be discussed:
- Use of date field.
- Merging billable & billed to single field (select list).
====================
CHECKLIST
1) Migrate schema to field api
☐ 1.a) Corresponding field_base definition created for all fields.
☐ 1.b) Corresponding field_instance definition created for all fields.
☐ 1.c) field_base and field_instance created on install
☐ 1.d) field_base and field_instance created on update
☐ 1.e) All field_base defnition agreed upon
☐ 1.f) All field_instance defnition agreed upon
2) Migrate Data
☐ 2.a) All data migrates properly
3) Permission
☐ 3.a) Remove entries in hook_permissions, hook_node_access_records and hook_node_grants
☐ 3.b) Set site variables in install & update routines to handle permissions by pmpermission module
☐ 3.c) Migrate old permission names to new one
☐ 3.d) Rebuild permission message shown to user
4) Views
☐ 4.a) Main listing view adjusted
☐ 4.b) Remove obsolete handlers
☐ 4.c) Document the missing Handlers
5) Token
☐ 5.a) Migrate Tokens
☐ 5.b) Remove obsolete/unsupported tokens
☐ 5.c) Document the missing Tokens
6) Theme
☐ 6.a) Remove unused theme functions and files.
7) Node
☐ 7.a) Remove obsolete codes to handle database updates for CRUD operations
☐ 7.b) Remove custom theme function for rendering the nodes
☐ 7.c) Adjust breadcrumb criterion in hook_node_view to effect node edit/full page view mode.
☐ 7.d)
NOTE: Mark it (copy paste) as done with these symbol -
☐ TODO
☑ DONE
☒ IGNORE
References:
#1915320-30: Move to a Field API based approach
#1997488-10: Tips for Migrating from Storm to PM
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | MissedUpdate.PNG | 15.76 KB | juliangb |
Comments
Comment #1
Raphael Dürst CreditAttribution: Raphael Dürst commentedAnd here's a patch for pmtask_ref.
Comment #3
dbt102 CreditAttribution: dbt102 commentedPatch installed cleanly. Update completed OK.
Checked out the database.
In the table field_config I can see the entry with the field_name pmtask_ref and I can see the tables field_data_pmtask_ref and field_revision_pmtask_ref.
Comment #4
D34dMan CreditAttribution: D34dMan commentedI think i know why the test are failing. The doesn't have the new dependency 'entityreference' that is declared in them which have been introduced due field_api patch.
Comment #5
D34dMan CreditAttribution: D34dMan commentedfeature/pmpeson branch handles PM Task migration now. Please test.
Comment #6
juliangb CreditAttribution: juliangb commentedAdding link to parent issue.
Comment #7
juliangb CreditAttribution: juliangb commentedI've just refreshed my test site from the latest in the feature/pmperson branch in git.
One comment so far - the view doesn't work as it expects a table called pmtask.
Working otherwise.
Comment #8
juliangb CreditAttribution: juliangb commentedQuestion - in the pmtask code the update_last_removed is updated to note that we've removed updates.
However. I believe this could lead to warnings if users are updating from previous versions of PM before they ran these.
Do we need to force users to follow all updates in turn, or could the user go straight from (example) alpha1 to feature/pmperson?
Comment #9
D34dMan CreditAttribution: D34dMan commentedCorrect.
It should not cause,
1.) I have created field_base and field instance definition of the one that was use by pm.
2.) In the migration code, should migrate respective field only if the respective columns in the table have non empty values. This way it should automatically populate the fields of the node if they are not empty ( maybe we could use isset here ?)
My idea is that the user should be able to update from any version. I feel its possible through current method. Let me know if there are any design flows, we could work upon that.
Comment #10
juliangb CreditAttribution: juliangb commentedMakes sense.
I think there is a use case where this falls down, but I will test first to ensure I've fully understood how those core functions work.
Comment #11
D34dMan CreditAttribution: D34dMan commentedThe field base and field instances are created only if they are not present already. Further the fields those where present earlier where such that the empty values where illegal values. For example the date value couldn't be a zero as well as the list values. The issues which has not been addressed in migration are the tokens and migration of permission configuration.
Comment #12
juliangb CreditAttribution: juliangb commentedI've just been testing this.
I tried checking out 7.x-1.0-alpha1 then upgrading directly to the feature/pmperson HEAD. Whilst the migration script accepts this, the Drupal core refuses to apply updates because it says that updates have been missed.
It is a simple change that is required, and relates to the update_last_removed hook. I'm going to do it now.
Comment #13
D34dMan CreditAttribution: D34dMan commentedI am sorry i couldn't understand the issue.
Glad that you have a fix with you.
Comment #14
juliangb CreditAttribution: juliangb commentedI'm now moving on to testing in the hope that we can agree that parts of the changes in feature/pmperson are done, until eventually we agree that the merge can take place. I propose to use the status of each individual ticket to track that part.
#todo Default view needs fixing.
Comment #15
D34dMan CreditAttribution: D34dMan commentedComment #16
juliangb CreditAttribution: juliangb commentedHere's my review of PM Task. Let me know if you want me to clarify and of the pendings.
Status of - pmtask
☐ 1) Migrate schema to field api
☒ 1.a) Corresponding field_base definition created for all fields.
☒ 1.b) Corresponding field_instance definition created for all fields.
☑ 1.c) field_base and field_instance created on install
☑ 1.d) field_base and field_instance created on update
☒ 1.e) All field_base definition agreed upon
☒ 1.f) All field_instance definition agreed upon
☐ 2) Migrate Data
☒ 2.a) All data migrates properly
☐ 3) Permission
☑ 3.a) Remove entries in hook_permissions, hook_node_access_records and hook_node_grants
☒ 3.b) Set site variables in install & update routines to handle permissions by pmpermission module
☒ 3.c) Migrate old permission names to new one
☒ 3.d) Rebuild permission message shown to user
☐ 4) Views
☒ 4.a) Main listing view adjusted (fields and access permission)
☑ 4.b) Remove obsolete handlers
☒ 4.c) Document the missing Handlers
☐ 5) Token
☒ 5.a) Migrate Tokens
☒ 5.b) Remove obsolete/unsupported tokens
☒ 5.c) Document the missing Tokens
☑ 6) Theme
☑ 6.a) Remove unused theme functions and files.
☑ 6.b) Remove hook_theme declaration if required
☑ 7) Node
☑ 7.a) Remove obsolete codes to handle database updates for CRUD operations
☑ 7.b) Remove custom theme function for rendering the nodes
☒ 7.c) Adjust breadcrumb criterion in hook_view to effect node edit/full page view mode.
☐ 8) Other
☐ 8.a) Solve and remove any TODO flags
Comment #19
juliangb CreditAttribution: juliangb commented