On a clean d7.35 install w/ drush en -y pm (PM --> 7.x-2.x-dev 2015-Mar-20 )

I check module list and PM is enabled. I check db and see these tables

field_data_pm_billing_status
field_data_pm_date
field_revision_pm_billing_status
field_revision_pm_date

I disable PM base module, then uninstall it. When I check the db these tables remain.

I've a patch I'll attach to this issue.

CommentFileSizeAuthor
#2 Complete_PM_base_db_uninstall-2457119-9745973.patch511 bytesdbt102

Comments

dbt102’s picture

dbt102 commented

This patch leaves a clean db.

dbt102’s picture

dbt102 commented
StatusFileSize
new Complete_PM_base_db_uninstall-2457119-9745973.patch511 bytes
dbt102’s picture

dbt102 commented
Status: Active » Needs review
d34dman’s picture

d34dman commented
Status: Needs review » Needs work

Hi dbt102,
Thanks for reporting the bug.

Those two fields are shared between various pm content types. So it should be the responsibility of individual projects to take care of it, instead of pm.

Also we should be using field_delete_instance. It could be possible that the webadmin could have "re used" the field somewhere else. If you set the second paramter to TRUE, it would delete those tables if no body else is using the field.

This could be a bug if one of our sub project (pmissue/pmtimetracking ...) is not calling field_delete_instance in uninstall. If those fields are being reused, then what you saw is the expected behaviour.

So can you elaborate on which all modules were enable and then disabled and uninstalled please?

dbt102’s picture

dbt102 commented

Hi D34dMan,

Thanks for looking at this issue. There were several things I noticed in terms of unexpected behaviors when I fully installed (enabled all submodules then created nodes using all content types), used, then tried to fully uninstall PM in an existing site (on my local_dev). To better understand what was going on (what the issue really was) I decided to setup a new PM basic install.

To do this I setup a new site D7.35, with just two additional contrib modules (admin_menu and module_filter). Then I loaded PM using the Drush command 'drush en -y pm' . So this got me setup quickly, and installed PM 7.x-2.0

I also setup a 2nd local install so I could compare pm 7.x-2.0 to 7.x-2.x-dev . For this I setup a new site D7.35, with the same two additional contrib modules (admin_menu and module_filter). This time I cloned PM into sites/all/modules and then, using drush added in all the PM module dependancies. Then I enabled only the PM base module.

So at this point I had two separate fresh (no content) sites with PM 2.0 on the one, and PM 2.x-dev on the other.

On the PM 2.0 site, I checked to make sure that the PM base module was already enabled during the "drush en -y pm" install, and it was. Then I checked the db to see what PM fields were enabled thus far. Those are the 4 listed in this issue. So I disabled the PM base module, then uninstalled it, and checked the db again, and those fields were still there.

On the PM 2.x-dev site, I enabled just the PM base module, checked it the same way, and the results were the same.

I realize those two fields are shared between multiple sub-modules, and I saw other kinds of issues there, but I thought it easiest to start with what I assumed would be expected the expected 'normal' behavior.

d34dman’s picture

d34dman commented

Thanks for the detailed report. It is indeed a bug, pm core module is not supposed to create any field. Assigning this issue to myself as fixing this requires a different approach (cleaning up install file). Thanks a lot dbt102. Would commit a fix to dev soon.

d34dman’s picture

d34dman commented
Assigned: dbt102 » d34dman

  • D34dMan committed 64b88a8 on 7.x-2.x 
    Issue #2457119 by dbt102: PM uninstall doesn't clear db fix. Removing...
d34dman’s picture

d34dman commented

This should be fixed in latest Dev ( as per commit in #8 )

dbt102’s picture

dbt102 commented

Nope. That commit, IMHO, made matters worst. (sorry, don't mean that to be critical)

To test your new commit, I moved my old PM directory to the trash, dropped the db and reinstalled my 2.x-dev test site. Then I cloned PM again, and enabled only the PM base module. When I did this, I got the message that the dependancies would be installed first, and I noticed that one of those dependencies listed was the PM permissions module. When enabling was complete, I rebuilt the permissions (as per notice).

Then, when I checked the db, there were no pm related entries. So I tried to disable the modules, but could not because they were both greyed out.

  • D34dMan committed 9dadff7 on 7.x-2.x 
    Issue #2457119 by dbt102: PM should not depend on PM Permission.
d34dman’s picture

d34dman commented
Status: Needs work » Needs review
dbt102’s picture

dbt102 commented
Status: Needs review » Reviewed & tested by the community

Ok that looks better ...

I did a 'git pull' from local pm2.x-dev than was able to delete both pm_permissions and pm_base. The uninstalled them OK. Then checked the db. That was clean.

Nice job. Changed status to rtbc.

d34dman’s picture

d34dman commented
Status: Reviewed & tested by the community » Fixed

Already committed, thanks for testing. you are awesome!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.