I'm not 100% sure what you want to do here. Do you want to drag from any portal in the left hand column to "drop" a record into to any portal from the right hand column?
That does appear possible to do, but the details will rest with how you have structured your tables and relationships. What you can do is script this process so that the drag and drop essentially copies the correct ID number from the source portal row and puts it into a new record in the target portal.
I will note that a "two mouse click" selection technique will be much simpler to implement. You could click a portal row on the left so select a record and then click a portal row on the right to select the portal to which to "add" that record.
But I am making a number of possibly incorrect guesses about what you want to accomplish with this layout.
I want to drag from any portal to any other portal. Basically as a candidate goes through the process of interviewing and such, the user can just drag and drop them into the next stage of the process, instead of selecting the next stage via a more complex system of menus and windows and buttons. Drag and drop seems most intuitive and the best design for this process in my opinion.
As for how these portals are set up, all of the portals have the same relationship between the job database and the candidate database (based on the Job ID), but just have different filters (each would filter based on the value of the stage/bucket/category that the candidate is in. So when a portal row is dragged and dropped, the only thing changing is the category field to that portal row.
I'd prefer not to have a two click system... I'm going to look into other options before resorting to that.
I think that I might have figured out how to do what I want... I'll post an update once I have this figured out to benefit the community.
I want to drag from any portal to any other portal. Basically as a candidate goes through the process of interviewing and such, the user can just drag and drop them into the next stage of the process.
Unless your interview process is totally nonlinear, you won't be dragging and dropping a portal record into from any portal into just any other portal, there would be at least some logical progression from portal to portal as a interview subject progresses through the interview process.
instead of selecting the next stage via a more complex system of menus and windows and buttons.
In my previous post, I described a much simpler to implement method where you click a portal row in portal 1 and then click a row in a second portal. Just two mouse clicks, no menus, no extra windows, no visible buttons. This would not be as nice as drag and drop, but also much simpler to set up.
I can conceive of a method that works one way, you can drag from portal A to Portal B to make a portal record disappear from portal A and appear in portal B, but I'm not sure that I can make this work bidirectionally, to be also able to drag from Portal B to Portal A.
I'll have to play with a file and see what works...
Alright! Got it working on my own.
So I'll explain this to someone who may need help in the same thing
First go to http://www.excelisys.com/blog/2012/05/18/drag-and-drop-using-the-separation-model/ and take a look at their demo, I'm basis my method off of that. But if you're lazy, basically you're using a Container field as a handle for the portal row to start the click and drag from. Then you have globally defined Container drop fields, which have a calculation something like:Let ( [_trigger = Self ;$$move_bucket = "To Screen"] ;"Drop")Where _trigger just causes the field to update when anything is dragged into it WHICH happens as you in the process of dragging. This means that in the middle of dragging, the $$move_bucket variable is updated to the bucket (or category, or whatever you want to call it). This Container drop field can be positioned behind and the same size as the entire portal. Which is the modification to Excelisys's method that I figured out. This makes it so you can drag a row from another portal onto any part of the new portal.To continue, the handle container field is attached to the portal row. This is what the user clicks on to initiate the drag. It has a script trigger for OnObjectEnter which only is triggered AFTER the item is dropped. The script called by this is then passed the parameter of the row's ID and the script makes the necessary arrangements of the new bucket, which is found by $$move_bucket.Note: For this particular client he wants the Candidate database in another file other than the Job database. Because of this, $$move_bucket is a variable stored only in the Candidate file, NOT in the Job file (which is where the layout with all the portals are). This caused a bug that took me a while to squash, so if you're having issues then be aware of that.I know this probably isn't clear at all but I tried my best :D