Create an "advanced" submission interface [#1846312]

Follow up of
#1833530: Way to download "soft" dependencies
#1839262: Couple of suggestions
#1841384: Patched version of the project
#1842420: Multiple modules

It should be possible to launch an advanced submission, with following additional settings:

Textfields, for urls of multiple patches to apply after building the site
Textfields with autocomplete of projects, to add optional projects for downloading after building the site
A selectbox, with possible submission timeouts (depends on role), to make it possible to choose the time until it gets terminated

Subtasks:

Add optional modules and patches parameter to script files and implement the functionality on shellscript site
Build the advanced submission interface without destroying the simplicity of the current form
Adjust affected (sub)modules to make use of this new feature

Comment	File	Size	Author
#1	advanced.png	108.31 KB	patrickd
#1	compare.png	109.28 KB	patrickd

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

patrickd CreditAttribution: patrickd commented 21 November 2012 at 01:17

File	Size
compare.png	109.28 KB
advanced.png	108.31 KB

I've been playing around with the dropbutton form element:

Comparison between the new and the old submission buttons.

compare

Toggling the advanced options of the new submit button

advanced

The usage of the service will be minimally changed by this as the user can still just type a project,
select a version and launch a sandbox directly. Though, he can now decide to go to the advanced
submission options instead of directly launching the sandbox. That new interface would be on a separate
page such as simplytest.me/advanced and contain the normal submission form (if the user came by
clicking on "Advanced.." fields should be prefilled) plus the new form elements.

Comment #2

Deciphered CreditAttribution: Deciphered commented 21 November 2012 at 05:04

While I like the idea of a dropdown submission button, I don't think it's an intuitive solution, especially if it still required the 'Advanced' dropdown/button to be clicked after selection, and if it didn't then you'd need to add another 'Launch sandbox' button to actually launch the advanced form sandbox.

Without spending any time right this second doing a mockup, I would like to offer two additional approaches:

1. A collapsed 'Advanced' fieldset below the standard controls

Obvious downside to this one is that the original project will still be detached from the additional settings.

2. A tab/switch above the the form to switch between 'basic' and 'advanced' mode.

I would also suggest a possible third mode as well ('expert') that would allow for the use of a makefile, or the manual textentry of a makefile, but I think that's much lower priority.

Comment #3

patrickd CreditAttribution: patrickd commented 21 November 2012 at 12:32

While I like the idea of a dropdown submission button, I don't think it's an intuitive solution, especially if it still required the 'Advanced' dropdown/button to be clicked after selection, and if it didn't then you'd need to add another 'Launch sandbox' button to actually launch the advanced form sandbox.

I actually planned to leave the launch button as it is for non-javascript users.
No javascript -> two buttons: "Launch sandbox" and "Advanced.."
Javascript on -> hide both buttons, make the dropbutton visible and trigger the corresponding button when clicking on the dropbutton links

Even if not done this way, I don't want make changes for this feature in simplytest_launch directly, I'd implement a simplytest_advanced module that alters the form as needed. Therefore we can conditionally hide() the standart launch button.

Another reason why I don't want to more input elements into the submission form is that the form is within a block, what makes it more flexible but also makes problems with form_states/error handling etc..
Therefore I'd rather put it on a separate page.

Any other solution would result in making the simplytest_launch block an actual page callback.

Comment #4

YesCT CreditAttribution: YesCT commented 2 December 2012 at 19:22

I was really happy to find this issue for an advanced option. And I was happy to see that one of the advanced options might be to provide urls to patches for the site. It would be great if the patches could be applied before the site was installed. But that's more complicated, so patches applied after install would be a major step forward that would help most of the kinds of patches out there.

An example of a patch that needs to be installed before a site is launched is #1848490: Import translations automatically during installation [edit: fixed the issue number]

Is it possible to do something like set up a sandbox distribution install profile that would show up in the menu, and that would have installing the patch in th make file? (I'm not sure if things work like that.) I ask because if a group wants to do usability testing, but they want to do the testing with a patch or two applied, simplytest.me would rock for that.

I can open a followup issue to discuss these variations if this issue is just about the setup of the form and not what functionality will be under advanced.

Comment #5

patrickd CreditAttribution: patrickd commented 2 December 2012 at 19:30

With the planned implementation of "advanced options" the patch will always be applied before the site was installed (actually everything else would be much harder)

Currently patches are applied on pre-install-phase, if referenced in .make -files. (details can be found in the faq)

For your usecase it's therefore already possible to use simplytest.me with a patched core.
Just create a sandbox project, reference the patches in the .make file and launch it.

Sure it's stupid to create a sandbox for every patch ever existing, therefore "advanced options". This will hopefully ease the testing of core and contrib patches and lower the barrier for new contributors :)

Comment #6

YesCT CreditAttribution: YesCT commented 2 December 2012 at 19:38

Thanks for clarifying that.

Sure it's stupid to create a sandbox for every patch ever existing, therefore "advanced options". This will hopefully ease the testing of core and contrib patches and lower the barrier for new contributors :)

For sure!

Comment #7

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers commented 3 December 2012 at 15:24

Wow. Just wow. At this rate, simplytest.me will become a crucial tool in the development of Drupal modules and of Drupal itself :)

Rock on, @patrickd!

Comment #8

Bojhan CreditAttribution: Bojhan commented 28 January 2013 at 19:46

Why not just have a "advanced setting" fieldset? You can style it differently, but its like "Advanced search" everyone knows how that works

Comment #9

patrickd CreditAttribution: patrickd commented 5 February 2013 at 10:31

Okay then let's do it with the fieldset. this means I have to convert the launch-block to a page callback but it doesn't make a big difference in the end I think.

But there have to be done some general changes in the server and submission modules, to make sure this feature can be implemented in a good way
#1848194: Rewrite simplytest_servers cleanly, make it exportable

Comment #10

Bojhan CreditAttribution: Bojhan commented 5 February 2013 at 12:56

Ok, feel free to ping me for any UX/design work. I love this service :)

Comment #11

patrickd CreditAttribution: patrickd commented 5 February 2013 at 13:11

Glad you think so :)
If you have an idea how to put an fieldset in that isn't too much ugly, I'm open for it ;-)

Comment #12

patrickd CreditAttribution: patrickd commented 8 February 2013 at 12:45

Status:

Active

» Fixed

A selectbox to choose the time kind of overloaded the UI, I left it out for now.

Beside that, IT'S IMPLEMENTED! YAY! :-)

Comment #13

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers commented 8 February 2013 at 13:20

patrickd++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Comment #14

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers commented 8 February 2013 at 15:31

Status:

Fixed

» Active

The one thing that's missing: the ability to create URLs that would prefill this, like e.g. http://simplytest.me/project/spark/8.x-1.x.

Well, that + the ability to checkout a *specific revision* from a project, because a patch might apply to the tip of the branch today, but not tomorrow; linking to a specific revision would solve that problem :)

Comment #15

patrickd CreditAttribution: patrickd commented 9 February 2013 at 15:13

I'd have no problem on adding queries to prefill the patches textfields

like http://simplytest.me/project/spark/8.x-1.x?patch[]='http://......patch'&patch[]='http://....patch'&patch[].........

But I'm afraid that presetting a revision would be an overkill on the site of simplytest.me, I'd rather depend on the patch getting rerolled first^^

Comment #16

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers commented 9 February 2013 at 15:17

#15: Principally, I completely agree. However, the reason I have in mind is simply one of "being able to reproduce history". If we can map a patch to a specific (i.e. known to work) revision of the code base the patch is rolled against, then it is possible to easily demonstrate the state of a patch five hours, five days or even five years from now. The latter may be hyperbole, but the two former examples are valid and sometimes even vital in evaluating issues :)

That being said, presetting a revision is obviously ten times less important than the ability to preset a patch :)

Comment #17

patrickd CreditAttribution: patrickd commented 9 February 2013 at 15:31

Status:

Active

» Fixed

IMHO the efforts to implement this are higher than the advantages we get, at least at the moment

I created a follow up issue so we don't forget about this, but I don't think I'll get this done soon,
#1912870: Possibility to specify a specific commit