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.We should be able to the get the functionality from Automated Drupal SaaS with Aegir3 working here in a generic way (if it doesn't already).
The Services API provides a lot of what we need for merging everything into Aegir SaaS in a more standard way so let's try to do it here instead.
Comments
Comment #2
colanI'll be working on this in the 7.x-1.x-hosting_saas branch for now.
Comment #3
colanAfter discussing with gboudrias, we've decided that we'll create a submodule here for all of the SaaS stuff, which will house the configuration aspects.
There will be defaults that can be overridden. One of the included things, for example, will be a default Services endpoint set programmatically.
Comment #4
colanFixing title.
Comment #5
colanComment #7
colanBranch moved to the new 7.x-3.x to match the current release of Aegir (and also Services). The first alpha release will be published momentarily.
Here are some things that are left to do:
Documentation with calling examplesMoved to #2721747: Document use of the SaaS module.Transplant remaining useful code from old hook to new hook (and then delete the old hook).Validate that the node IDs entered on the admin settings form are of the correct type.Ensure that the cloned site can be installed on the platform.Moved to #2719289: Ensure that the site to clone / profile matches chosen platform.Currently, errors are only logged to the server. Return useful status codes/info instead of returning 200 OK with no data. See #2370491: Return a custom status code? for a way to do this.Moved to #2721733: Enhance SaaS error reporting.Add remaining bits from hosting_saas_utils.Add remaining bits from hosting_restapi.Verify that the current user is the SaaS user in the task-modification hook.Delete missing variables in uninstall hook.Add the 2 required permissions to the install hook so these don't require manual addition:Comment #8
colanComment #15
Yuri CreditAttribution: Yuri commentedThanks for the great work, colan. I'll test it out on my BOA box.
Comment #16
Yuri CreditAttribution: Yuri commentedIf Aegir Services is the final name for this module, need the filenames hosting_services.* also be renamed sooner or later, to prevent confusion?
Comment #17
colanI kept is as hosting_saas just because that's what it was before and to prevent DB changes, but yes, hosting_services_saas would be convention. I personally don't think it's worth the effort to switch, and I probably won't get to this unless someone convinces me it's really important. However, I'd welcome patches.
@gboudrias: Thoughts on this?
In other news, I've moved everything else in the above list to separate issues except for the hosting_saas_utils work. That will still be done in here.
Comment #18
gboudrias CreditAttribution: gboudrias at Praxis Labs Coop commentedI agree, it's not worth the switch though it would be standard.
Comment #19
gboudrias CreditAttribution: gboudrias at Praxis Labs Coop commentedI created the hosting_saas_utils_merge branch. Please review.
In short, I took the compromise route of making two tabs in the SaaS tab for the settings, as original (saas) form is a system settings form, and it seems pointlessly hard to add the dynamic for to it.
Also, I put what I could in hosting_saas.utils.inc. I don't think we need to change the function names, in fact things are probably clearer if we don't.
After some tests, it seems ready to merge, but there's a lot of subjective decisions involved so please take a look.
Comment #20
colanSounds great! Thanks for doing that.
I'll review today.
Comment #22
colanAfter some minor changes and reorganization, we just merged that branch into 7.x-3.x.
There are now 3 config forms (subtabs under SaaS):
We can now handle individual issues in their own tickets.