The UI for managing items in a queue needs to be implemented as a Field widget.

Comments

JohnnyX’s picture

I'm searching for a nice UI for og admins to add/ remove users to (own) groups. For example a widget which show own organic groups to add/ remove users at users profile/ info?
The way group -> group tab -> add members is to long and doesn't looks good...

Could it be done with entityqueue module?

barraponto’s picture

Does it sound like a good idea to leverage Draggable Views?

jojonaloha’s picture

Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new13.03 KB

Attached is an initial patch that creates a new widget called entityqueue_dragtable. It displays a draggable table with the entity labels and links to remove items, along with an entityreference field to add additional items to the queue.

There are a couple things that still need work or I don't quite like yet about this implementation:

  • As far as I can tell, you can't limit field widgets to a certain entity type. IE: we can't restrict use of this widget to only entityqueue_subqueue entities. This means the remove link either can't be a link or it should only be displayed when the field is attached to an entityqueue_subqueue.
  • Clicking "Add item" takes you back to the list of entityqueues, I am working on trying to get it to use an #ajax callback to add the item and update the table instead.

Also, should the patch also contain an update script to update all existing fields to this new widget? I noticed even though the field is locked when you try to edit it, you can still change the widget, so that makes me wonder if we should update to the new widget, but only if the widget hasn't been changed.

amateescu’s picture

The first item from your "don't like" list is essential :)

That's why this issue is called "port the widget to Entity reference", not to *Entityqueue*. The idea was that this widget should be a generic one that can be used by all entity reference fields. This basically means that the "remove field item" menu callback doesn't need to be tied to entityqueue and it just needs a generic path.

About the second point, yep, that's also an important part of the "experience" :)

I don't think we need to provide an upgrade path for existing subqueues, it's easy enough for everyone to switch to the new widget.

Anyway, really nice progress here!

amateescu’s picture

Priority: Normal » Major
Status: Needs review » Needs work

Setting to NW based on the comment above.

jojonaloha’s picture

The idea was that this widget should be a generic one that can be used by all entity reference fields. This basically means that the "remove field item" menu callback doesn't need to be tied to entityqueue and it just needs a generic path.

I was thinking that as well. In that case, would this make more sense as a patch to Entityreference, or even a small module like entityreference_dragtable?

I'm going to continue working on it as a patch to entityqueue for now, and if we decide to break it out it should be fairly easy to port to one of those options once it is made more generic.

jojonaloha’s picture

Status: Needs work » Needs review
StatusFileSize
new15.71 KB

Ok, this patch makes the widget generic and adds the ajax callback to the add item button so that you stay on page until clicking save.

There are a few things that could be improved still, but I think this is very workable and IMO the remaining items would be nice improvements, but not a deal-breaker.

  • A notice is added to the page when you add new items to the queue that indicates that the form still needs to be saved. This message is currently being duplicated when you add a second item.
  • Similarly, if you move items around, add an item and then move items again the message that is added by tabledrag.js is duplicated. I think this is because the whole table is replaced and tabledrag loses any state it has set for the table.
  • New items added don't get a "remove" link because otherwise the menu callback will not be able to remove them because they have not yet been saved to the entity. It would be nice if instead they got a remove link that just removed the row?

I think follow-up issues can be created for these things once this one is complete.

amateescu’s picture

I think the only dealbreaker is the third point, as it would be hard for users to know how they can remove that item. Do we have a 'Cancel' operation that would mitigate this problem?

jojonaloha’s picture

Yeah, it is a little odd that there is no remove link for new items. I'm thinking that instead of a link that it should be a button. This would also help this scenario:

- Added a new item
- Clicked a remove link for a pre-existing item
- Click confirm remove button
- They are redirected to the edit page again, but their unsaved changes are lost

Instead every item would have a remove button, and the same scenario would be:

- The add a new item
- Click a remove button, which ajax submits form, just like add item button
- Their changes are not lost

amateescu’s picture

Every item having a remove button++ :)

jojonaloha’s picture

This patch removes the menu callback that was added in the last patch to remove items and replaces the remove link with remove buttons. In order for Drupal to set the correct $form_state['triggering_element'] the button names must be unique, so their names contain the field name and the delta.

amateescu’s picture

Assigned: amateescu » Unassigned
Status: Needs review » Fixed
Issue tags: +Needs followup

Gave this patch a quick spin and it looks awesome! The double (and sometimes triple) warning can be a bit distracting, but it's not worth holding up the patch for it :)

Committed to 7.x-1.x. Nice work!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.