Hi Tamara, et al,
If I am seeing this correctly, I fear that Ashraf's suggestion suffers from
the same problem as Gidd's, due to multiple concurrent users. Plugging the
$USER$ of one user into the master list of tasks will only work until the
next user selects that task and has her $USER$ plugged into it. This will
cause non-intuitive, flaky-looking results for the first user the next time
his master list table field is refreshed (previous task reappears after he
selects the next task to be associated).
Too bad the database can't handle this automagically by specifying the
opposite of a join. What we want is to have a view of the data that shows
only rows from Table A (master list of tasks) for which there is no
corresponding row in Table B (tasks associated with request).
The only workaround I've thought of (so far) is to have a Table C, which
contains a row for each task in the master list for each user who needs to
associate tasks with requests. That might not be workable for a large
number of such users. However, Table C could be kept synchronized with
Table A and the users via filters that fire when Table A is updated or a
user is added or dropped from those using the feature.
You could have a column in Table C into which you plug the current Request
ID when the task in a row is associated with that request. Your
qualification for the table field displaying the master list of tasks (from
Table C, not Table A) could select only the rows from Table C that match the
current $USER$ and DON'T match the current Request ID. This would also
avoid the need to clean out the column from Table C when the user bails out.
You would just need to set it for each associated task when a request is
redisplayed.
Question for you though, is it never possible to have multiple tasks of the
same kind associated with a request? If that IS a possibility, you'd need
to flag the tasks for which multiple instances are supported, and add that
to your table field qualification so those tasks don't disappear from the
"master list" table field.
Just a thought,
Doug Anderson
Mayo Clinic
Opinions expressed are necessarily my own and not necessarily those of the
Mayo Foundation.
-----Original Message-----
>From: Action Request System discussion list(ARSList)
>[mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ashraf Elrefaey
>Sent: Wednesday, December 27, 2000 12:48 PM
>To: ARSLIST@LISTSERV.VISTAIT.COM
>Subject: Re: Table fields
>
>
>Hi Tamara,
>
>To overcome the multi-user problem, you can still use Gidd's solution but
>instead of setting the 'Sent Task' to "Sent" or "Unsent", set it to either
>$NULL$ (which should be the defalt value for the field) or to the value of
>$USER$ - and in your 'Available Task' table, change the selection
>qualifiation to 'Sent Task' != $USER$.
>
>But then you have another problem, what if the user decided not to continue
>and closed the form or even closed remedy user??, He won't be able to see
>all the records stamped with his $USER$ the next time he uses the
>display-only form. So it's a good idea to add another active link that
>executes on close window and searches your 'Available Task' form for 'Sent
>Task'=$USER$ and sets the 'Sent Task' to $NULL$ again.
>
>Hope that helps,
>
>Regards,
>Ashraf Elrefaey
>Remedy Consultant
>Workflow Solutions Ltd
>* Phone: +64 4 385 2885
>* Cellular: +64 21 377523
>* Fax: +64 4 385 2911
>* E-Mail: refaey@workflow.co.nz
>1 Webpage: http://www.workflow.co.nz
>
>-----Original Message-----
>From: Tamara Strang [mailto:tstrang@VENGRP.COM]
>Sent: Thu, 28 December 2000 09:31
>To: ARSLIST@LISTSERV.VISTAIT.COM
>Subject: Re: Table fields
>
>(snip)
>
>I don't think I can set a flag in the "Available Tasks" table (schema)
since
>there could be concurrent users who need to see all Available Tasks not
>associated to their current change request. Maybe I am overlooking
>something or thinking about this too hard.
>
>(snip)
>
>---- Original Message -----
>
>From: Gidd@Home.COM
>To: ARSLIST@LISTSERV.VISTAIT.COM
>Sent: Wednesday, December 27, 2000 11:36 AM
>Subject: Re: Table fields
>
>Tamara,
>
>Sounds like you have everything in place. Add an extra selection field
>called Sent Task to each schema for your purposes. Give it a value of Sent
>and Unsent
>
>(snip)
>
>[mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Tamara Strang
>Sent: Wednesday, December 27, 2000 11:16 AM
>To: ARSLIST@LISTSERV.VISTAIT.COM
>Subject: Table fields
>
>
>Hey guys,
>
>I'm not sure if this is possible but I thought I would toss it out and see
>if anyone has been successful implementing similar functionality.
>
>I have a display only form with two table fields. The one table field on
>the left is the Available tasks table field that lists all tasks in the
>application that can be association with a change request (this is a custom
>application). The other table on the right lists all tasks that have been
>associated to the current change request. I have two buttons between the
>two tables, Add >> and << Remove. The Add >> button pushes the highlighted
>available task in the available tasks table (schema) to the associated
tasks
>to request table (schema). This all works great. The only minor problem
>is, the users would like to see the task in the available tasks table
>removed from the list if it exists in the associated tasks to request
table.
>Not sure how to accomplish this. Any ideas or thoughts? The data resides
>in two separate schemas, Available Tasks and Associated Tasks to Request.
>
>Tamara
>
>---------------------------------------------
>Tamara Strang
>Ventana Group
>
>tstrang@vengrp.com
>www.vengrp.com
>(530) 846-6640
>(530) 846-6612 FAX
Previous Topic
Index