Clean up the contact forms listing UI: Allow to set the default category and weights on the listing page

+1 to both!

> We should just implement this as a variable 'contact_category_default'

I don't think we need to change the data storage, just the UI.

There's another UX issue #1477704: Replace "Selected" dropdown with checkbox in category edit form

EDIT and about storage #1588422: Convert contact categories to configuration system

Initial working patch. Probably we needs tests.

Looking good!

Will need some extra help text to explain what dragging them accomplishes.

Also, is 'selected' the one that's selected by default in the contact form? That maybe needs explanation too.

Suppose fix for contact_help could go in follow-up, I'm not do good in English to write help texts.
Let's get more reviews from usability team

Looks good, I am not sure we want a "selected" column - maybe it should be labeled "Default".

Changed Selected to Default we are already changing this option in #1477704: Replace "Selected" dropdown with checkbox in category edit form to checkbox with text 'Make this the default category.'

EDIT related #1588422: Convert contact categories to configuration system

Can this get code review, Dave Reid maybe?

#7: 599770-contact-sorting-7.patch queued for re-testing.

re-roll

Here's a new patch, now ordering is enabled only when there's more then one category on site.
Probably it's possible to move form building into list controller... but not for now.

I agree this UI badly needs to be cleaned up. Also, better issue title.

But, hm. I agree we should not attempt to do this in a generic/abstract way just yet, but I do think that the new form code should be added to the CategoryListController override class... (?)

To do so, we'll probably have to use drupal_build_form() instead of drupal_get_form(), but that shouldn't be a big deal.

I found similar implementation in #1787942-41: Allow assigning layouts to pages but Gabor used drupal_get_form()

We've actually started with a generic implementation in #1855402: Add generic weighting (tabledrag) support for config entities (DraggableListController) already.

That patch is still waiting for #80855: Add element #type table and merge tableselect/tabledrag into it to land, but it looks like the generic implementation will boil down to a few lines only. Therefore, it might make sense to do that first?

Should wait for #1855402: Add generic weighting (tabledrag) support for config entities (DraggableListController)

Related to default UI which similar to #1803638: Improve default language change process (ui and help text)

Added screenshot

I don't think we should postpone this patch for #1855402: Add generic weighting (tabledrag) support for config entities (DraggableListController)

This form is not a default case and could be refactored later for default table-drag

Following, and noting that it seems that adding non-default categories doesn't actually show them in a selection on the contact form. I added a new category, 'info', but didn't make it default, and no selection showed up on the contact page at all. I deleted the 'website feedback' default category, then the contact page said "You need to add a category" (something like that). I set the new 'info' category as default, and the form showed up again without an error. I don't know if whatever small bug caused this behavior could be fixed with this patch...

New patch build on top of FormInterface now this form is alterable by name 'contact_category_list_form'

@geerlingguy selection of contact category was droped but please file new issue to fix message in contact_site_page() or provide a fallback to first category if no category marked as default.

No, please don't combine FormInterface into EntityFormControllers in these issues. That's what #1913618: Convert EntityFormControllerInterface to extend FormInterface is for.

I got FormController and ListController confused :) Sorry

added route conversion here

and remains... related #1938386: Convert contact_category_* pages to a new-style Controller

fix yml

#26: 599770-contact-sorting-26.patch queued for re-testing.

#26 looks pretty nice for me
happy thankspushing )

It appears that we've completely lost the ability to select contact categories on the site wide form is missing. This should be postponed on #1997692: Create contact form block as that patch mandates the ability to have the ability to not have a default contact category. This is important functionality if you want to make people choose one!

I think this is a great improvement in UI so let's find a compromise here.
While we can bikeshed about tabs/splitbuttons for UI the administrative sreen really lacks ability to re-order items!!!

So let's leave default as is, because we always have state when default category deleted

Do not allow personal category to be selected as default

Fix test

+++ b/core/modules/contact/lib/Drupal/contact/CategoryListController.php
@@ -45,33 +53,140 @@ public function getOperations(EntityInterface $entity) {
+      $row['default'] = array(
...
+        '#disabled' => $entity->id() == 'personal',
+      );

AFAIK #disabled only sets the disabled attribute but does not actually prevent submitting that value. I.e. I think we should conditionally set #value. I mean something like:

if ($entity->id() == 'personal') {
  $row['default']['#value'] = NULL;
}

Otherwise looks great!

Better display nothing at all

Hmm, how about instead of
'#disabled' => $entity->id() == 'personal'
we just do
'#access' => $entity->id() != 'personal'
??

Anyway, this is super minor and shouldn't hold anything up.
If I would be a little more comfortable with contact.module I would RTBC #36 but I'll leave that to someone else.

EDIT: Fixed inverted condition

@tstoeckler thanx #37 much cleaner

Coolio, thanks @andypost!

+++ b/core/modules/contact/lib/Drupal/contact/CategoryListController.phpundefined
@@ -45,33 +53,141 @@ public function getOperations(EntityInterface $entity) {
+    $default_category = config('contact.settings')->get('default_category');
...
+    $entities = entity_load_multiple($this->entityType, array_keys($values));
...
+    $contact_config = config('contact.settings');

Can I have some injections?

Can the default setting, be something that is set on the configuration of the category? It can still be reflected in the table. But using a radio in a table has proven to be quite hard to use in previous testing.

Addressed #40, suppose better to have a factory and default both

Working on implementation of changing a default category via operalins link
@Bojhan we still have a checkbox at the bottom of contact category editing form.

right patch

There should not be links for config entities
also this should be re-rolled after #1938390: Convert contact_site_page and contact_person_page to a new-style Controller

This is looking pretty great.

+++ b/core/modules/contact/lib/Drupal/contact/CategoryListController.phpundefined
@@ -1,21 +1,81 @@
+use Drupal\Core\Form\FormInterface;
+use Drupal\Core\Config\ConfigFactory;
+use Symfony\Component\DependencyInjection\ContainerInterface;
+use Drupal\Core\Extension\ModuleHandlerInterface;
+use Drupal\contact\CategoryStorageController;
+use Drupal\Component\Utility\String;

Let's not mix up Symonfy and Drupal here.

+++ b/core/modules/contact/lib/Drupal/contact/Tests/ContactSitewideTest.phpundefined
@@ -222,15 +222,7 @@ function testSiteWideContact() {
     // Find out in which row the category we want to add a field to is.
-    $i = 0;
-    foreach($this->xpath('//table/tbody/tr') as $row) {
-      if (((string)$row->td[0]) == $label) {
-        break;
-      }
-      $i++;
-    }
-
-    $this->clickLink(t('Manage fields'), $i);
+    $this->drupalGet('admin/structure/contact/manage/' . $category . '/fields');

This is a really great improvement.

No, that is not an improvement.

That code was added there for a reason. It verifies that the Manage fields link is displayed, that was broken before.

drupalGet only verifies the routes, and doesn't actually test clicking around the UI. clickLink is important here

The both needed - to verify that link exists and accessible
Also related #1997692: Create contact form block

Draggable is in #1855402: Add generic weighting (tabledrag) support for config entities (DraggableListController) so this should be re-rolled on top of it

Added related issues

45: 599770-contact-sorting-45.patch queued for re-testing.

re rolled the patch.

The re-roll is wrong, the reason of the patch to add formInterface to list builder!

@andypost are you still interested in working on this?

Yes, and this depends on #1997692: Create contact form block

Update IS to current state
#58 shows hat tests are make sense

ContactFormListBuilder should implement FormInteface

I am removing the Needs Reroll tag as the patch in comment 58 applies to head.

The steps I took to check this were to

1.) Make a new directory
2.) in the terminal: $ git clone --branch 8.0.x http://git.drupal.org/project/drupal.git
3.) $ cd drupal
4.) $ curl -O https://www.drupal.org/files/issues/clean_up_the_contact-599770-55.patch
5.) $git apply --check clean_up_the_contact-599770-55.patch

And I received no response so this patch applies to head.

@piyuesh23 I am unassigning this task from you as I saw you were assigned it in Feb 2015. If you would still like to work on this issue just make another comment. :-)

I updated the remaining tasks to incorporate @andypost feedback in comment #61, there are some tasks in the original issue summary that I'm not sure whether they are relevant any longer. So we will need to update the issue summary.

Also we need a beta evaluation for this task. I'm going to remove the Novice tag until that is done and we're sure this is for the current version of Drupal 8.

Last working prototype is #45
it needs to be rebuild on top of DraggableListBuilder
and address comments #47

The languages admin page also has a weights + set default form, so that could do to be abstracted as a new builder class extending DraggableListBuilder.

Hi, not sure what patches I should be applying to get the the result of having the category dropdown in the contact form. Does anyone have this currently working on 8.4.3 have some quick pointers?

There is no concept of a contact form category in Drupal 8, this just has a confusing issue title, should say default *form*.

The contact_storage module provides a field type that allows to send a contact form to different recipients based on a select. And webform might provide something similar.