Allow for different sort per user

I believe you need to create a contextual filter of the User:UID, with it defaulting to the current user id if none is provided.

Currently there is no contextual filters for Draggableviews, so you have to find examples of how to write it else where.

Ok here is the start. I will leave this for someone else to finish.

I added this to Draggableviews' views/draggableviews.views.inc file:

  // draggableviews_views_data_alter(&$data)

  $data['draggableviews_structure']['args'] = array(
    'title' => t('User ID'),
    'help' => t('Add the User ID as an argument'),
    'group' => t('Draggableviews'),
    'argument' => array(
      'handler' => 'views_handler_argument_user_uid',
      //'name field' => 'name', // display this field in the summary
    ),
  );

This change the query:
draggableviews_structure.args = '[]' to draggableviews_structure.args '[\"X"]'
and added
WHERE (( (draggableviews_structure.args = 'X' ) ))

I also referenced Views' modules/user.views.inc file

To solve everything you want, I feel like this would be a custom sub-module, where it would add a uid column to the draggableviews_structure table in the database. This would only work with Native handler (not EntityAPI or FieldAPI). Then you can do multiple things, with custom GUIs and custom permissions (allow copying, allow to view others users sort view, etc).

I am leaning towards adding a UID column to the database, but haven't discovery enough use cases for this that one weighs the additional complexity it adds. In addition, it would only work with Native handler.

For the near future, the goal of this module is to provide different sort per user by using exposed or contextual filters.

Hello.

I had a similar need and I resolved the problem like this:

Added a new configuration type to Sort criteria.

User or Global
If you select user it will automaticly save your user id in table when you save your customization.
Global will bee same as the regular draggableview.

I have created a patch and i will create soon a tutorial with it.

@p_tamas - I was excited to see that you've implemented a solution to this problem but I can't seem to install the patch. Here's what I did and the resulting error (I'm fairly inexperienced when it comes to installing patches so please let me know if I've done something wrong). Any advice?

arirasekh$ patch < allow-user-to-sort_draggableviews-added-user-edit_1877662_5.patch 
patching file draggableviews.install
Hunk #1 succeeded at 53 with fuzz 2 (offset -7 lines).
Hunk #2 succeeded at 68 with fuzz 2 (offset -11 lines).
Hunk #3 FAILED at 143.
Hunk #4 FAILED at 151.
Hunk #5 FAILED at 239.
Hunk #6 succeeded at 90 with fuzz 2 (offset -181 lines).
3 out of 6 hunks FAILED -- saving rejects to file draggableviews.install.rej
can't find file to patch at input line 118
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/handlers/draggableviews_handler_native.inc b/handlers/draggableviews_handler_native.inc
|index 298f002..a42d8e0 100644
|--- a/handlers/draggableviews_handler_native.inc
|+++ b/handlers/draggableviews_handler_native.inc
--------------------------
File to patch:  

I'd welcome that tutorial you mentioned if you've made any progress on it.
Thanks!

I was able to get this working in the current dev version of the module without having to apply any patches. I added a Context/Argument of Global: Null and then set the default value to the ID of the current logged in user. After that I could tell the Draggable Views: Content field to use all arguments and it ends up saving per-user sort order data.

Seems to be working pretty well so far FWIW.

yeah thanks for this nice hint @eojthebrave it works like this perfect!

I'm pretty certain that #7 doesn't work, at least, with the current 7.x-2.2 code. I've looked at this multiple times and see no code that would indicate user info is being saved. Is it possible that the code to do this was removed in favor of something else for 2.2?

Code looks old, but too old. Should be able to re-roll. At first glance the old thing that looks gone is $query_get_old...pretty sure that is stripped out. 7204 needs to be rolled with latest update hook #.

The patch mentioned in #5 does seem to work with 7.x-2.2 code, despite a couple of patch fails. From what I can tell, the parts of the patch that fail are in the install and now a part of the db schema. My guess is that eojthebrave applied most of the patch and then used #7 to distinguish between users by utilizing the logged-in user id. Can anyone else confirm this? I think it's a little disingenuous to mark something as already fixed when it really isn't. But please correct me if there's something I'm missing here.