Posted by bcmiller0 on December 1, 2010 at 12:37am
11 followers
| Project: | Password policy |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | ctools exportables |
Issue Summary
Like to have password_policy(s) be exportable (work with ctools) , so they can be exported/imported and also used with features module.
This is only a start at that and very beta, but working toward making the schema for a policy and role enabling of a policy be exportable.
This allows for storage and editing of a policy from an exportable or feature, but still has some work to make the module read it from the exportable (convert from db calls to using ctools_export_load_object).
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| password_policy_ctools.patch | 4.93 KB | Ignored: Check issue status. | None | None |
Comments
#1
mis-placed paren on schema for password_policy_role schema.
#2
this is working for us in production as a faux-exportable. Still could use some work, but as a first pass allows the policy to be exported.
#3
Committed to master. Marking needs port cause I'm going to try merging in #985374: Drupal 7 Port and might clobber this patch in the process.
#4
I think I saved it all in conflict resolution.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.
#6
That patch only allowed the privacy policy to be exported. For this ticket to be closed in my opinion, we need to put the loading part in here as well. When I export and create a new site, none of the privacy policies show up.
#7
subscribe
#8
You're right, we're not making use of
hook_default_password_policy()in the loading process. Unfortunately it looks like this will need some work to refactor the loading operation into something more CTools-friendly.#9
Loading part is missing in 7.x Version, too: #1250296: Exported Password Policy does not import on install.
Other modules have the same problem: #1357588: follow-up for import (needs to be optionally available when ctools is enabled)
#10
Can I recommend just changing the pid to a varchar instead of auto inc, and not add a new field. It might make using the ctool load function easier.
I do not see any reason why you need both a id and a name field.
#11
subscribe
#12
How does this actually work at the moment?
what do I have to do to get the "faux-exportable" functionality working. I put my password policy in a feature but now I can't figure out how to get it to appear on my staging site.
#13
Even just making a policy, putting it in a feature on my site then clicking "delete" within the same site (should be revert?) doesn't bring back the settings that I saved.
I'm very confused as to how this is supposed to be functioning.
#14
The export is only one part of the functionality. With ctools you only have to add an export part to the schema array in hook_schema. For this module the export works.
Know you have to implement the import part. I'm working on a patch for the apachesolr module (#1357588: follow-up for import (needs to be optionally available when ctools is enabled)). It's work in progress. As I said before I think it's the same problem here. Have a look at this and perhaps publish a first patch for this module.
#15
I've been having a look into the load side of things.
Hoping that replacing the function that loads by id with one that loads by name and uses the ctools load function will work, provided that i turn the object returned by ctools into the array format that the rest of the pp module expects...
Had some limited success using the ctools_export_ui but nothing worst posting here as a patch yet.
#16
The fundamental change is really to move loading to a machine name-based method. This is probably the fundamental step to integrating CTools.
#17
yeah, that's basically what i thought, the function that saves the roles associated with each policy needs to be updated to store the machine name of the policy as well as just the pid too.