swpugh Posted January 17, 2014 Posted January 17, 2014 Hi all, Couple-days-lurker, first-time-poster here, definitely toward the novice end of the spectrum. I am working on a job tracking system (where each job is a "shot") and am building a layout for adding tasks to a shot. I want to be able to assign multiple people to the task, and so currently have a portal in my layout which references a "person" table. Each row contains "person::fullname" and "person::tempCheckbox", which I intended to use for temporary storage of, you know, whether they're checked or not. Is such a field in the "person" table safe if there's a good chance that multiple users will be adding tasks at the same time? Right now it's just me working with this in development mode but eventually that won't be the case. I've read somewhere that *global* values are user-specific, but I've no idea how to stitch a global field into this Relationship Graph pudding of mine...any pointers? Many thanks, Steve
comment Posted January 17, 2014 Posted January 17, 2014 Each row contains "person::fullname" and "person::tempCheckbox", which I intended to use for temporary storage of, you know, whether they're checked or not. Actually, I don't know what that means. Going by your description, you should have four tables arranged as: Jobs -< Tasks -< Assignments >- People It is possible to do without the Assignments table and assign multiple people to a task by checking them in a checkbox; however such simplification carries a price: most significantly, you won't be able to record anything about the assignment itself (e.g. date, role, performance evaluation. etc.). It's strictly an on/off affair - and once you turn it off, it vanishes without leaving a trail. 1
swpugh Posted January 17, 2014 Author Posted January 17, 2014 Hi there, thanks for your reply! I've created a Task assignments table and stitched it in between tasks and people as you indicated -- I don't have plans yet for fleshing that table out but do like the ability to do so later on, so thanks! I am still looking for a way to easily anywhere from one to five or six people to a given task (and generate those Assignment records), and still like the idea of presenting the whole crew (10-20 names) with checkboxes next to each. Is a portal pulling names from my People table still the best way to go, and if so am I safe in using a field in that table for "checked or not checked" without some other user accidentally stepping on my checkbox data if they happen to try adding people to a task at the same time? Many thanks again - every time I get frustrated by the number of different ways that a cat can be skinned in FM, I get reminded how helpful the community is. I hope I'm not being too newbish ;-) Best, Steve
comment Posted January 17, 2014 Posted January 17, 2014 I am afraid I still don't understand the role of the checkbox here. In order to assign a person to a task, you need to create a new record in the Assignment table, containing (at least) the assigned person's PersonID and the task's TaskID. If you like, you can show all people in a portal (on the layout of Tasks), and assign them to the current task by clicking them (with a script creating the necessary assignment record as a result of the click). I suggest you take a look at the demos posted here: http://www.fmforums.com/forum/showpost.php?post/246136/ and here: http://www.fmforums.com/forum/showpost.php?post/233965/
swpugh Posted January 17, 2014 Author Posted January 17, 2014 Aha! I was thinking that I would need to use the checkboxes as a means to keep track of who'd been selected, and then make their assignment records all at once when the user clicks "accept" in the window. I'd mentally checked out of the fact that I could do so with a script triggered by clicking on them. Thank you for shedding light on that, and for the links which I'm about to go check out now. Best, Steve
comment Posted January 17, 2014 Posted January 17, 2014 You can use conditional formatting to indicate who's been selected. I don't think the demo shows that, because IIRC it predates the feature.
eos Posted January 18, 2014 Posted January 18, 2014 Hi there, thanks for your reply! I've created a Task assignments table and stitched it in between tasks and people as you indicated -- I don't have plans yet for fleshing that table out but do like the ability to do so later on, so thanks! Here's an example that creates/removes assignments on each click, and uses conditional formatting in several ways to indicate an existing assignment. I am still looking for a way to easily anywhere from one to five or six people to a given task (and generate those Assignment records), and still like the idea of presenting the whole crew (10-20 names) with checkboxes next to each. The selection portal shows all people, but it's trivial to add a filter to the portal or the relationship itself, so the user can dynamically filter the list by typing. CreateJoinFromPortal_eos.fmp12.zip
swpugh Posted January 18, 2014 Author Posted January 18, 2014 Wow - thanks, y'all, I can honestly say that I've learned a lot this afternoon! Thank you for your advice and especially for your samples - I'm very much a "poke around and see how this works" kind of learner, so that's much appreciated. Have great weekends, I'll be back haunting the forums next week! Best, Steve
swpugh Posted January 18, 2014 Author Posted January 18, 2014 @eos - I believe that I've set my portal and relationships up to mirror yours, and so far I can create the assignment just fine. However, when I alt-click to remove an assignment, not only is the TaskAssignment (People|Tasks in your example) record deleted, but the actual Person record is also deleted! I am stumped, because even stepping through in debug I am *clearly* only calling a Delete Record just after executing the Find within my TaskAssignment table. None of the relationships have "Delete Records in this table when a record is deleted in the other table" checked, either. I had been tripped up by not having a Cartesian join between my Tasks table and a People TO, once I saw that in your example yet another lightbulb went off. But this weird delete issue has me stumped, I want to say that I've looked through everywhere I can think to look but obviously I'm missing something. Does anyone have any ideas? Best regards, Steve
eos Posted January 18, 2014 Posted January 18, 2014 Whatever happened to “next week”? You obviously caught the FM bug … Does anyone have any ideas? Not as such, since you already ruled out that "Delete Records in this table…” is the culprit; but you could leave a second window with the People TO open in the background, and while stepping through the debugger, take note at what point the People record is deleted. Of course, it would also be helpful to see your script.
swpugh Posted January 18, 2014 Author Posted January 18, 2014 Heh...no rest for the wicked, right? Strangeness abounds -- I opened a second window and tested, and found that if I remove the task assignment for a person *while their record is shown in that second window*, their People record will not be deleted. However, removing the task assignment for a Person not shown in that window will delete their Person record as well. Showing the Person table in Grid view, records get deleted as well. Weird! For some reason I cannot copy/paste my script code, if I can clean up the DB itself to post I'll do that or find a place to dump a screencapture of the script. Thanks again for your help! Best regards, Steve
swpugh Posted January 19, 2014 Author Posted January 19, 2014 Grrr. Rather confounding, because this morning Person records are being deleted whether they're the currently-selected record in my Person layout or not. Could I have a mungled Relationship somewhere? I've posted a screencap of the relationship layout here: http://imgur.com/QHEqI23 I hate being enough of a database wrangler in previous lives to know what I want to do but being enough of a FM newb to know that I'm just not doing it right. Grr.
eos Posted January 19, 2014 Posted January 19, 2014 The screenshot isn't too helpful, since we can't look into the relationship definitions. None of the relationships have "Delete Records in this table when a record is deleted in the other table" checked, either. I suggest you make sure about that by generating a Database Design Report and checking the relationships. The fastest method AFAIK is to create the XML version of the DDR and search for cascadeDelete="True". If it's not that, then I think it can only be your script. For some reason I cannot copy/paste my script code, if I can clean up the DB itself to post I'll do that or find a place to dump a screencapture of the script. Thanks again for your help! You cannot copy the script code as text (without a plug-in), but you can print it by pressing ctrl-P (I guess; Mac user here). Then use your favorite Windows method of printing to a PDF, and post the PDF or copy and paste the code. Or – optimally – post your file here (a clone should do). Compress it, and use More Reply Options to upload and attach it.
Lee Smith Posted January 19, 2014 Posted January 19, 2014 You aren’t creating new records in Find Mode, are you?
swpugh Posted January 19, 2014 Author Posted January 19, 2014 Hi Lee, I am not -- my current testing route is to create a batch of Person records in Browse mode on my Person layout, then assign/remove tasks in my Task layout. Doing so causes the TaskAssignment record and the corresponding Person record (but not the corresponding Task record) to be deleted. Deleting the TaskAssignment record groovy and expected, the Person record distinctly ungroovy and not expected. Many thanks, Steve
swpugh Posted January 20, 2014 Author Posted January 20, 2014 Wow. EOS, I owe you a beer and I owe the community a big, fat "mea culpa". I was looking at the wrong relationship when I so enthusiastically declared that "Delete records when..." was unchecked. Thank you for pointing me toward the Database Design Report, which I had not used before now and which has pointed out my errant checkbox. Self-throat-punching will commence after work today. Frustratingly, Steve
Recommended Posts
This topic is 3959 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now