Problem/Motivation

The styling for the Views bulk action form is limited and can lead to confusion when presented along side other form elements. For example, on the administration content listing page (/admin/content) the bulk action form is presented beneath the exposed filter form and confusion can exist between the fields and apply buttons for the two forms.

Before:

Current bulk action form on admin content page

Proposed resolution

Add a wrapper mechanism and some simple block styles to the bulk action form wherever it appears in the Seven theme (both for views bulk operations and hardcoded bulk operations like the comment list).

Maybe in the future

An enhanced version is possible that 'joins' the Views table header visually with the bulk action form, adding an additional pointer arrow to the 'select' checkbox column. This approach would not work when the View doesn't use a table display, so we discarded this for now.

Proposed bulk action form on admin content page - enhanced version

Remaining tasks

Reviews.

User interface changes

Change of Views bulk action form styling background and border, see proposed resolution.

API changes

No changes. Adding #bulk_operations element.

Data model changes

None

Files: 
CommentFileSizeAuthor
#73 2785051-73.patch5.27 KBpk188
#72 vbo-filters.png71.51 KBckrina
#63 improve_usability_of-2785051-63.patch2.87 KBtarekdj
#60 vbo.png53.16 KBtarekdj
#60 improve_usability_of-2785051-60.patch1.89 KBtarekdj
#59 interdiff-54-59.txt1.19 KBtameeshb
#59 2785051-59.patch5.34 KBtameeshb
#54 interdiff-improve_usability_of-2785051-50-54.txt3.71 KBtkoleary
#54 improve_usability_of-2785051-54.patch5.39 KBtkoleary
#50 improve_usability_of-2785051-50.patch4.21 KBlauriii
#50 interdiff.txt917 byteslauriii
#50 mobile-after.png28.71 KBlauriii
#50 mobile-before.png28.55 KBlauriii
#48 Screen Shot 2016-10-06 at 12.29.35 PM.png76.71 KBtkoleary
#45 Content | drupal 8.3.x 2016-10-05 16-50-22.png88.02 KBGábor Hojtsy
#41 interdiff.txt2.64 KBlauriii
#41 improve_usability_of-2785051-41.patch4.13 KBlauriii
#30 views_bulk_action_form-2785051-30.patch1.87 KBkjay
#30 interdiff-2785051-26-30.txt732 byteskjay
#27 Screen Shot 2016-10-01 at 2.47.06 PM.png157.66 KBtomatkins
#27 views_bulk_action_form-2785051-26.patch1.74 KBtomatkins
#25 Screen Shot 2016-10-01 at 08.36.58.png98.01 KBkjay
#22 views_bulk_action_form-2785051-22.patch1.39 KBmarameodesign
#22 interdiff-2785051-14-22.txt452 bytesmarameodesign
#20 screenshots.jpg1001.23 KBmarameodesign
#14 views_bulk_action_form-2785051-14.patch1.84 KBkjay
#12 views_bulk_action_form-2785051-12.patch1.8 KBkjay
views-bulk-action-form.patch1.35 KBkjay
proposed-bulk-action-form-on-admin-content-small-screens.png38.46 KBkjay
proposed-bulk-action-form-on-admin-content-enhanced.png83.55 KBkjay
proposed-bulk-action-form-on-admin-content.png62.86 KBkjay
current-bulk-action-form-on-admin-content.png98.68 KBkjay

Comments

kjay created an issue. See original summary.

ifrik’s picture

Status: Active » Needs work

Thanks kjay,
and thanks for presenting it at weekly UX meeting.

This looks like a good approach to visually separate these two sets of fields and buttons - and not only for the one core admin page for which the problem got noticed, but for any custom view with a bulk operation (with or without exposed filters).

The exposed filters can be any number of fields, followed by the Apply (or Filter) button underneath it. This will always look different depending on how many or which filters are displayed.
The bulk operation in contrast always consists out of the label, the dropdown list and the button.
So the proposed solution of displaying these three items in a box - and in one line on screens that are big enough - works fine.

The proposed enhanced version with the little arrow to point to the tick boxes themselves, could further improve usability of the bulk operations as such - but it removes the gap between bulk operations and the list/table of items underneath it and thereby has a number of possible knock-on effects. For example: where does the "Show all columns" link go on a smaller screen.he one core admin page on which it was noticed, but solves the problem in general for any other custom view with a bulk operation.

The two related issues to this are #2471010: Label for Content and User bulk operations does not fit the action and #2561115: Rollback: Use 'Filter' for exposed filter button text in new views and new installations (instead of 'Apply') that both deal with changing the wording of the buttons.

kjay: I set it to "Needs review" as you said you wanted to test further that the CSS does not introduce any errors anywhere.

YesCT’s picture

Issue tags: +VDC
yoroy’s picture

Status: Needs work » Active
Parent issue: » #2721807: Design for filters and bulk operations
yoroy’s picture

Status: Active » Needs work
smaz’s picture

I've just tested this with the latest 8.3.x dev, on 3 views:

  • Content listing
  • User listing
  • Custom view with a path starting /admin/

It worked well in all three places. I also checked the other views provided by core (Custom block library, files etc.) but they didn't use VBOs.

As Ifrik said, I think the advanced version may have implications with hidden columns etc., so it might be best to stick to the simple version for now.

For the patch:

+/**
+ * Theme the Views bulk actions form to improve usability.
+ * As used on /admin/content
+ */

This should be in an @file block, and have a blank line before the start of the CSS:
https://www.drupal.org/node/1887862 under 'File comments'
As an example, look at core/themes/seven/css/panel.css

It also doesn't need the following comment, as it's used in several places by core + any additional views with VBO created by the user/other modules.
* As used on /admin/content

kjay’s picture

Thanks smaz

Revised patch attached as per your suggestions

smaz’s picture

+/**
+ * @file
+ * Theme the Views bulk operations form to improve usability
+ */
+

Tiny nit pick: Needs a . after the word 'usability'.

https://www.drupal.org/node/1354#files

Will try and do some cross browser testing.

Gábor Hojtsy’s picture

Adding tag to indicate we need cross-browser testing.

Gábor Hojtsy’s picture

+++ b/core/themes/seven/css/components/views-bulk-operations.css
@@ -0,0 +1,33 @@
+  float: left;
+  margin-right: 10px;
...
+  float: left;
+  margin-right: 10px;
...
+  float: left;

Need an RTL counterpart to these, see how other CSS in core does RTL:

[dir="rtl"] .same-selector-as-earlier {
/* RTL override */
}

tkoleary’s picture

Issue tags: -cross browser compatibility

@kjay

This is a nice improvement. We should get it in to 8.3.

Is there a new patch?

kjay’s picture

New patch attached does the following:

  • Full stop on comment as per @smaz's suggestion in #8
  • RTL counterparts added as per @Gábor Hojtsy's suggestion in #10
  • Added a breakpoint at 600px to refine the vertical alignment of the form fields on larger screens
smaz’s picture

I'm guessing the RTL additions need to be cross browser tested?

I've just tested the latest patch, it needs a little more work around the ~600 - 620px breakpoint range.

At 615px, the 'Apply to selected items' button jumps to the line below, but at 607px it jumps back inline.

At 600px > ~595px, the 'Action' label sits above the select list, and the apply button floats to the top right corner. This looks odd/out of alignment, it would be better if it sat inline with the select list.

kjay’s picture

Thanks @smaz

This is an issue caused by word sizing and so will be subject to language differences. The breakpoint is working as intended I believe.

I've improved a little in the attached patch by avoiding the select list from floating earlier than it needs to and by kicking in a bit later.

cheers

Keith

smaz’s picture

Status: Needs work » Needs review
ifrik’s picture

I'm tagging this with "Novice" and "needs screenshots" for the mentoring sprint at DrupalCon Dublin.

AndreaD’s picture

Assigned: Unassigned » AndreaD

I am assigning this to my-self, and looking at this issue.

AndreaD’s picture

Assigned: AndreaD » Unassigned
marameodesign’s picture

Assigned: Unassigned » marameodesign

I'll give it a shot!

marameodesign’s picture

FileSize
1001.23 KB

Here's a bunch of screenshots.

Looks functional to me, but considering the filter button is on 100%, I'd probably put the "Apply to selected items" to 100% as well

tomatkins’s picture

Hi Marameodesign, I have been working on a simular issue - https://www.drupal.org/node/2521808 - and we may want to meet over solutions? Im in the general Sprint at Drupalcon Dublin - are you still here today?

marameodesign’s picture

Here's a patch where I just made the button 100% for mobile devices.

lauriii’s picture

Status: Needs review » Needs work
+++ b/core/themes/seven/css/components/views-bulk-operations.css
@@ -0,0 +1,56 @@
+#edit-header {

Could we use something else than id to theme this? I suggest that we use form_alter inside Seven theme to add a classes for these elements.

yoroy’s picture

I think that's what tomatkins is doing in https://www.drupal.org/node/2521808

kjay’s picture

Thank you for helping on this issue.

Filter button sizing:

Is the consensus that the filter is our benchmark in having it's button set to 100% width? This starts to feel like a styleguide question for theme-wide consistency but could mean that instead of 100% width on any buttons, we should remove the 100% width on the select list that I added to my patch, perhaps using 100% max-width in case there are any translation sizing issues on very small screens.

Visually I think the 100% button width only really works when the screen is very narrow indeed and even then it feels like an awkward feature.

You can see from the attached screenshot that when the filter button is set to 100%, it quickly feels oversized screen size increases.

Theming the Filter or the Views bulk operation form:

@tomatkins, I wasn't aware of the duplicate issue thanks for linking this up. We discussed these two forms in a UX meeting with @ifrik who has summarised the points in comment #2.

The approach I am taking here is to do the theming on the Views bulk operation form (VBO) instead of the Views filter form. This is because there is only a 'visual isolation' issue when the VBO form is added to the page. My thinking is that by visually isolating the VBO form, we fix a potential clash with any type of form interface anywhere a VBO form might be used in the admin theme.

tomatkins’s picture

So the proposed solution you listed in #25 is similar to what @scaragucc' worked on yesterday.(We need to add him to the credit) We injected a class "form-wrapper--bulk-form to bulk_action_form_wrapper. " to the seven.theme file, and adjusted css on the form.css file. Should I post my patch to this issue or https://www.drupal.org/node/2521808?

I am currently stuck unable to make the patch file because:
The coding standards read git diff > [description]-[issue-number]-[comment-number].patch

Not sure which issue it should be posted (I am leaning toward 2785051, since that is most directly what we did), just want to get a confirmation.

second issue: when I run git diff - it shows the changes to the forms.css file but not the changes to the seven.theme file. Are .theme files are .gitignored?

On the brights side, the code is bullet proof - even on this third rebuild (I rebuilt it on separate sites because I got a little confused with documentation: but the code works perfect every time! :-)

tomatkins’s picture

So here is the work @scaragucc' and I completed yesterday. It adds border and background to the bulk action form on core/theme/seven/css/component/form.css and Implements hook_form_BASE_FORM_ID_alter() for \Drupal\BulkForm and Adds class form-wrapper--bulk-form to bulk_action_form_wrapper on core/theme/seven/seven.theme.

Please add @scaragucc' in credit and committing.

yoroy’s picture

Status: Needs work » Needs review
smaz’s picture

Status: Needs review » Needs work
+/**
+ * Implements hook_form_BASE_FORM_ID_alter() for \Drupal\BulkForm.
+ *
+ * Adds class form-wrapper--bulk-form to bulk_action_form_wrapper.
+ */
+function seven_form_views_form_content_page_1_alter(&$form, FormStateInterface $form_state ) {
+  $form['header']['node_bulk_form']['#attributes']['class'][] = 'form-wrapper--bulk-form';
+}

Not able to test, but I believe from the form ID _views_form_content_page_1:
This will only apply the class to the content listing page. In core there is also a bulk operation form on the user listing page, and it's possible for users to add bulk forms to custom views. So this class addition needs to be more generic as to anywhere there is a bulk operations form.

I can take a look at this next week if no-one gets to it before me.

Cheers

kjay’s picture

The patch in #27 provides a good refinement of the patch in #14 because it condenses down the volume of CSS. #14 uses floats as does the filter fields but #27 uses inline-block which also helps to keep layout CSS lean.

In #14 a new file for the css is added since form.css contains pretty generic CSS and it may be preferable to split this out from form.css. Maybe someone could advise on the recommended approach for that one?

I like that the 100% width on the select list at smaller screen sizes is now removed, my vote is for this approach rather than making the buttons 100% width.

Other minor tweaks in the attached patch:

  • #14 introduced 1em margin top to the form wrapper, enough to further visually separate this form from items appearing before it. Without that top margin the two forms feel very closely stacked and I propose re-introducing the top margin for the VBO form wrapper
  • Slight margin-top/bottom tweak for the submit button. It makes the top/bottom padding on the wrapper tighter, better balancing it with the padding on the table header
  • A different approach to margin left/right for RTL so that it works in the same way as LTR

As pointed out by @smaz, #27 answers @lauriii's request to add styles with a class by being too specific. We want the styling to be applied in a generic way so that this feature will work with any admin page delivering a VBO form. The attached patch does not currently address that issue, I can discuss with @smaz during the week.

tkoleary’s picture

Status: Needs work » Needs review
smaz’s picture

Status: Needs review » Needs work

I've had a chance to test the patch - as expected, this now only works on the content listing page due to the hook_form_BASE_FORM_ID_alter only applying to the content listing.

I've looked at doing a form alter, but there doesn't appear to be a bulk form ID, base form ID or similar that we can use to only target these forms wherever they are used.

I had the idea of checking if the form has a node_bulk_form element, but there could be user_bulk_form etc. as it's based on $entity_type_bulk_form.

Maybe we'll need to look at doing a views hook to detect a bulk form & add a class that way. Alternatively we could keep to the ID for now, as that won't change, and look at changing to a class in a followup issue?

tkoleary’s picture

  1. +++ b/core/themes/seven/css/components/form.css
    @@ -222,6 +222,38 @@ textarea.form-textarea {
    +  background-color: #f7f7f7;
    

    This is not a color from the style guide. The closest is "Eggshell #2" which is #f5f5f2. It should be still sufficiently different from the table head background (#ebeae4) to avoid confusion.

  2. +++ b/core/themes/seven/css/components/form.css
    @@ -222,6 +222,38 @@ textarea.form-textarea {
    +  border: 1px solid #e6e4df;
    

    Given that the element following will always be table head we should follow the pattern of no left and right border established there.

  3. +++ b/core/themes/seven/css/components/form.css
    @@ -222,6 +222,38 @@ textarea.form-textarea {
    +  margin-bottom: 1em;
    

    The 'enhanced' design in the summary shows no margin bottom. We should go with that.

scaragucc'’s picture

@tkoleary

The 'enhanced' design in the summary shows no margin bottom. We should go with that.

@tomatkins and I added the bottom margin because the enhanced version ignores the "Show All Columns" text to be above the table. We thought until that was discussed that we would implement the simpler version.

@smaz Is having an array with the likely form IDS and checking the current form ID against that array via in_array() a possibility?

smaz’s picture

@smaz Is having an array with the likely form IDS and checking the current form ID against that array via in_array() a possibility?

I don't think so - because the user can create custom views with bulk operations, we won't know what those IDs will be and the theming will break on anything the user creates. It also means that any new views in core that have bulk operations added will require an update to the hook - that feels like defeating the point of using a re-usable class, to have php that requires changing every time :)

I should have some more time to look at what hook we can use later today.

tkoleary’s picture

So I just tested using drupal data attributes with wildcard as selector and it is working. The wildcard asterisk denotes "data attribute contains this". For reference see this article.

div[data-drupal-selector*="bulk-form"] {
    background-color: #f5f5f2;
}

Assuming the Drupal data attribute for bulk operations always contains "bulk-form" which I believe it does, this gives us a pretty clean way to get at just what we need.

One other thing that occurred to me is that we should use the .button--small class for submits like this one that we wrap in a container.

tkoleary’s picture

Just checked Caniuse on the wildcard attribute selector and it's all green.

scaragucc'’s picture

@tkoleary Nice! I'm only sad I didn't think to look at that. Can you create your own view with VBO and see if your selector catches it?

tkoleary’s picture

Can you create your own view with VBO and see if your selector catches it?

We don't actually have configurable views bulk operations in core yet, slipped my mind. But I have tried this out with instances of bulk form in /content and /people, where it works. Doesn't work with comment which is legacy. :/

lauriii’s picture

Assigned: marameodesign » lauriii

I'm working on making this work more widely

lauriii’s picture

Assigned: lauriii » Unassigned
FileSize
4.13 KB
2.64 KB

This patch attaches the variation class we have used to theme this for all bulk operations

lauriii’s picture

Status: Needs work » Needs review
tkoleary’s picture

    +++ b/core/modules/comment/src/Form/CommentAdminOverview.php
    @@ -100,10 +100,7 @@ public function buildForm(array $form, FormStateInterface $form_state, $type = '
    -      '#open' => TRUE,
    

    Can we make '#open'=> FALSE? Then we could add a small bit of js to open it if items are selected. This would go a long way to simplifying this UI.

  1. +++ b/core/themes/seven/css/components/form.css
    @@ -222,6 +222,38 @@ textarea.form-textarea {
    +  background-color: #f7f7f7;
    

    Per #33 this should be #f5f5f2

  2. +++ b/core/themes/seven/css/components/form.css
    @@ -222,6 +222,38 @@ textarea.form-textarea {
    +  border: 1px solid #e6e4df;
    

    Per #33. This needs to be: border-top: 1px solid #e6e4df; border-bottom: 1px solid #e6e4df;

tkoleary’s picture

Status: Needs review » Needs work
Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

Updated the issue summary with screenshot and generally in terms of content. The content admin one does not seem to wrap as intended though:

Chrome 53 on Mac Sierra here.

Gábor Hojtsy’s picture

Issue tags: -Needs screenshots
tkoleary’s picture

@gabor @laurii

Looks like the fix for that is targeting the classes instead of just the inputs:

.form-wrapper--bulk-form .form-item,
.form-wrapper--bulk-form .form-actions {
    display: inline-block;
}

I would also suggest adding removing margin from items in this wrapper:

.form-wrapper--bulk-form .form-item,
  margin: 0;
  display: inline-block;
}

And using padding instead to reduce the height of the container to match the height of the table header:

.form-wrapper--bulk-form {
    padding: 6px 12px;
}

Which should look like this:

tkoleary’s picture

Accidentally duplicated

lauriii’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
28.55 KB
28.71 KB
917 bytes
4.21 KB

#43.1: Yes, if we convert the element to details element instead of container. It would be nice to keep this as simple as possible at this patch and maybe leave that for a follow-up.

I didn't implement #48.2 & #48.3 yet because I wasn't quite sure what was meant to be achieved by this and removing the margin between elements makes it more difficult to see what is happening on the mobile:

Before #48.2 & #48.3:

After #48.2 & #48.3:

tkoleary’s picture

@laurii

I didn't implement #48.2 & #48.3 yet because I wasn't quite sure what was meant to be achieved by this and removing the margin between elements makes it more difficult to see what is happening on the mobile:

I see. This makes sense. But wouldn't we only need margin bottom to maintain space between items that break? eg

.form-wrapper--bulk-form {
    padding: 6px 12px 0;
}
.form-wrapper--bulk-form .form-item,
  margin-bottom: 6px;
  display: inline-block;
}
tkoleary’s picture

Issue tags: -Dublin2016 +sprint

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tkoleary’s picture

Rather than add another special snowflake I tried to extend the reusable .container-inline and .panel classes already in core. This should actually make the .container-inline class more responsive and re-usable in Seven and subthemes of Seven.

wturrell’s picture

(slightly off-topic)

As we already duplicate the Apply to Selected Items submit button at the top and bottom of the table, could we duplicate the Action dropdown as well (and use JS to keep them in sync?) i.e. adds convenience for users who are near the bottom of the list who don't want to scroll all the way up to the top again because they usually choose the action after selecting the nodes.

tkoleary’s picture

@wturrell

That's an interesting idea, but I think it would be a different patch since it is a significant increase in scope. Also, if we are going to put more effort in here the additional feature that would have the most positive impact would be to conditionally show the actions only when table rows are actually selected as you'd see commonly in applications like gmail.

Gábor Hojtsy’s picture

I think that could be a very good followup once this lands or an independent patch.

Manuel Garcia’s picture

Status: Needs review » Needs work

Drive by review, only coding standards nitpicks

  1. +++ b/core/themes/seven/css/components/container-inline.css
    @@ -0,0 +1,40 @@
    +    width: 100%;  ¶
    +  }
    +}
    

    Extra space, No newline at end of file

  2. +++ b/core/themes/seven/css/components/form.css
    @@ -127,7 +127,6 @@ label[for] {
    -
    

    Not needed.

  3. +++ b/core/themes/seven/css/components/form.css
    @@ -221,6 +220,16 @@ textarea.form-textarea {
    +/* ¶
    + * Styles the bulk operations form. ¶
    

    Extra spaces

  4. +++ b/core/themes/seven/seven.theme
    @@ -186,3 +190,12 @@ function seven_form_node_form_alter(&$form, FormStateInterface $form_state) {
    +  $element['#attributes']['class'] = array('form-wrapper--bulk-form', 'panel', 'container-inline');
    

    Let's use short array syntax.

tameeshb’s picture

Status: Needs work » Needs review
FileSize
5.34 KB
1.19 KB

Fixed from #58 and :

git apply --index improve_usability_of-2785051-54.patch 
improve_usability_of-2785051-54.patch:98: trailing whitespace.
    width: 100%;  
improve_usability_of-2785051-54.patch:117: trailing whitespace.
/* 
improve_usability_of-2785051-54.patch:118: trailing whitespace.
 * Styles the bulk operations form. 
warning: 3 lines add whitespace errors.
tarekdj’s picture

A completely different approach that should work for all vbo actions.

vbo preview

Gábor Hojtsy’s picture

@tarekdj: how does this work with grid views (eg. as combined with #2834729: Create an MVP for adding and re-using Media) or list views? It would be fabulous if this could be made to work for those cases :)

tarekdj’s picture

@Gábor Hojtsy : Humm, didn't handle it. Let me see what I can do.

tkoleary’s picture

@ tarekdj

Interesting, but it would also have to take in to account places where core injects an element between the bulk form and table header. eg. "show row weights". This could be handled by either moving those links or by making sure that the arrow nub always positioned with the bulk form tools.

Also, in the case of grid view, the down arrows could suggest (incorrectly) that all items in that column were selected. I's suggest having the down arrow in the table view but simply removing it in the grid view.

tarekdj’s picture

@tkoleary In #63 the arrows are simply hidden on medium screens. See the table case

tkoleary’s picture

@tarekdj

Oh, I see. That works.

tkoleary’s picture

@tarekdj

I'm not seeing the arrow tab in chrome.

Also I'm noticing regressions from previous versions but it's hard to see what's been changed because there's no interdiff.

When you are working on a patch please start with the last submitted patch, make your changes, and then provide an interdiff (git diff previous-patch > interdiff-previous-patch-new-patch.txt) so we can see what was changed.

wturrell’s picture

I don't see any arrows either.

Comparing patches 54 and 63, two obvious regressions in #edit-header:
- lack of margin-bottom: 10px; for .panel.form-wrapper--bulk-form means both shaded areas crash into each other
- the background colour in 54 was lighter (#f8f8f8)

Re: @tkoleary's earlier reply to me (#56) about hiding the actions until something has actually be selected - I think that's a good idea, but it's important there's a fixed height placeholder present even when there's no dropdown or buttons (perhaps with some help text). That way the rest of the page won't shift down when someone selects the first item. This isn't an issue for Gmail because they have other things in that top bar at all times. (Aside: interesting how Gmail don't offer any sorting by columns at all, even in advanced search, yet no-one seems to complain about it.)

ckrina’s picture

Status: Needs review » Postponed

Although it's great how this issue is moving forward, I'm afraid the design used here is not considering how it plays with the design for filters in this other issue: #2521808: Visually encapsulate the content listing filter to distinguish it from the 'add content' action link. So I'd like to pospone it until both filters and Views bulk action form play well together in one design. There's actually an issue for that: #2721807: Design for filters and bulk operations. We could talk about this on next Usability meeting.

tomatkins’s picture

When is the next Usability meeting so I can participate/follow up with progress and see if the the current fix can be implemented?

yoroy’s picture

Thanks @tomatkins, I'll let google do the timezone thing, here's the calendar for ux meetings: https://calendar.google.com/calendar/embed?src=jhj7p0u7link8vvjdqqsqr5qt...

ckrina’s picture

Issue summary: View changes
Status: Postponed » Needs work
FileSize
71.51 KB

Since the design has already been integrated with filters in #2721807: Design for filters and bulk operations, I think this issue can continue.

pk188’s picture

Status: Needs work » Needs review
FileSize
5.27 KB

#59 failed to apply. Re rolled #59.