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.While I agree that "Platform access control" should be re-factored to match the new, profile-centric logic, because now the first choice in the form is profile and not platform, I'm afraid it is impossible to "limit the choice of install profiles to those on available platforms".
You can have the same profile (default, openatrium etc.) used in more than one platform. Even the "default" profile alone, due to its availability on all platforms (usually) makes it impossible to limit anything here without further confusion for users.
We could limit visibility of profiles only when the profile is unique and available on exactly one platform, but this doesn't resolve the problem from the UX point of view, because there are still profiles (like default) available on more than one platform, which effectively blocks possibility to make it fully intuitive.
I think also, that until we will find a solution to this problem (like lock, which properly hides the locked platform), we could disable this feature (Platform access control) since it creates now more problems (support requests) than resolves. In short: it doesn't work, or works only partially, which is even more confusing, like in this example:
1. Create two D7 platforms using alpha7 and beta1.
2. Use "Platform access control" to allow access for any client other than you for alpha7.
3. Check the Create Site form - it will now correctly limit available platforms, when you click on Standard, Minimal or Testing and you will see only beta1 available.
4. Now use "Platform access control" to allow access for any client other than you also for beta1.
5. The result? Create Site form still displays all 3 install profiles for D7 platforms, but when clicked, they show "No valid choices" error for platform.
BTW: turning on/off hosting_ignore_default_profiles variable doesn't make any difference in this case.
See also:
http://drupal.org/node/883412
http://drupal.org/node/899764
http://drupal.org/node/725952
http://drupal.org/node/897982
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | hosting-hide-profiles-937490-4.patch | 2.72 KB | sfyn |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedThe feature is
a) only available if the Clients feature is enabled (and it is disabled by default)
b) is disabled / set to 'allow all' when adding new platforms by default
Is it thus really that invasive? You have to enable two things to use it (and thus for it to be a problem).
I don't mind removing it, but the issue of how to prevent one client from deleting/locking another client's platform remains.
Comment #2
omega8cc CreditAttribution: omega8cc commentedIt is not "invasive", but it generates too many support request, since we have Clients feature enabled by default and people keep asking why it doesn't work as expected etc.
And the main problem is even not about clients locking access to platforms, it is because the logic is now inverse - and it breaks the site creation form, because the list of available install profiles doesn't match permissions set on platforms.
I know it is now "correct" because the install profiles is an application and the site is an app instance, while platform itself isn't an app, but still, it is now confusing, because limiting access by platform no longer works as expected.
Comment #3
anarcat CreditAttribution: anarcat commentedPlatform access control is not yet deprecated, as far as I know. So I'm changing the title of this issue: you are requesting that we remove or disable (?) platform access control.
For the record, I disagree with removing the feature: as miguel is saying, it's disabled by default and actually works, although it breaks things.
Comment #4
sfyn CreditAttribution: sfyn commentedHiya.
I disagree with this too. So I wrote a patch. Here it is.
That said, after my morning spent wading through the code for this, I do think it should be refactored considerably.
On the create site form specifically I think we should change how the js works considerably, to deliver a form already including only those options, profiles and platforms, available to the user. Then our js just has to hide the appropriate platforms when choices are made.
I depend quite heavily on the platform access in uc_hosting. I would be sad if it went away.
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedAnarcat committed this and I confirm it works.
Thanks for the patch - I don't mind hacks here that fix it, the whole access control thing is already a hack anyway :)
I agree that we should revisit the js that loads the form to make it more elegant, at a later date. And under this whole problem is that platform access control needs to be refactored to proper access control (permissions, roles mapped to platforms etc)
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commented