Many developers do not allow editing in portals for this very reason. If a user modifies data in a portal, the parent record AND children records are locked. Which version of FM are you using? If it's 13 or 14, provide popup windows and allow the editing there.
it's a "feature" not a bug.
We're in 14. I apologize, I'm a novice user and may be in over my head so please bear with me here. Here's some more background. What we're doing is we have a production schedule that is displayed on a tablet in each of our production departments. When certain statuses change on these jobs the staff member checks off a box on the schedule. That might be for "goods received", "screens burned", "order complete". Anyway, the field they're hitting is just a checkbox. The problem is that until they leave the record no one else can check anything else displayed in that portal.
A couple questions:
Is there a way to run a script that would commit the data when they hit the checkbox and then exit the record?
Is there a way to run a script that would exit the record after a certain time of inactivity?
I will do some research on how to do a popup window like you suggested. Maybe that will have to be how it's done. Thanks.
Yes, you can run a script either via trigger, or just define the checkbox itself as a button, and a script like:
Set Field [ portal::checkbox ; not portal::checkbox ] // just toggles it
Once the commit happens, other users will be able to hit the checkbox.
Thanks for the input Beverly, I don't believe I referred to it as a "bug". I understand it is that way by design. Just looking for a workaround.
I was not calling it a bug either.
The behavior of locking records is used within those methods that are 'transactional'.
Okay, you've all got me thinking about my use of the portal for this solution. Here's a pic of what the interface needs to look like. Each day is a record that contains a portal to the jobs table. We need to have a list of days that in turn contains a list of jobs. We also need to be able to view or scroll through multiple days... a continuous list of nothing but jobs not separated by date doesn't do me any good. I don't want our users doing searches all the time. It's kinda like a kiosk. That's why I went the portal rout. Being a newbie perhaps there was a better way to achieve this. Any thoughts? Thanks again guys, I appreciate it.
Tim, that works great. Thank you.
use the portals merely as a record picker. Upon click on a portal row, load the related record's data in globals. Use a popover showing the globals and let the user take his time to do changes. Have an OK button on the popover, when it's hit transfer the data from the globals into he related record, commit and refresh with flush.
How are you setting the "base" for each portal? For instance, I see you have April 4, April 5, April 6. How do you change to April 7, 8, 9? Just asking...gathering info at this stage.
It looks to me like you are using a table based on Dates for the layout, and displaying Jobs in each portal based on a date in the job. Since the Date is then the parent, anyone editing in a portal locks the date record and the other related records (since the date record is locked.
For this, you might be better off basing a layout on the Jobs table. If when you go to that layout, you find the dates you're interested in and then sort by date (and by something in job), you'd have what you want. It would then become a Subsummary report, and it would have many advantages. One advantage would be...you'd only lock the one record you're editing (and so would everyone else).
To accomplish this, 1) create a new layout based on the jobs table, 2) in the layout, create a subsummary part when sorted by whatever field in the Job table contains the date, 3) create a script which sorts when you click a button. You could still use the method outlined by Tom Fitch, which is a great suggestion for a lot of reasons.
Do you know which Dates you'd want to be showing, in general? Would it be today + five days? Two days prior to today + 5 days? I ask because you'd want your script to find the days you're interested in.
dtcgnet, you are 100% correct on the way it's currently set up. The layout table is a set of records by date only. I just add days (records) as needed. I think the subsummary report idea makes sense... If I'm understanding it correctly. I'm going to give that a shot. Thanks much!
dtcgent, concerning which days I want showing, generally a couple weeks on either side of the current date would probably be enough. As I have it set up now it will display every date in the table which really isn't necessary. Another good idea. Thanks.
siplus, thanks for the advice. I will take a look at that solution.
Add two fields to your JOBS table. Both will be date fields. Set both up with Global storage. Add them to the top of the new layout.
Field 1: FirstDate
Field 2: LastDate
Because they are global, every user has his "own", so this will work in a multi-user environment.
Add a button next to the two fields. Call it: Submit or something like that.
A user will enter a date into FirstDate, then into LastDate, then click Submit. Submit runs a script.
The script sets $FirstDate = FirstDate and $LastDate = LastDate. Then it enters find mode, and sets the date field in your job to $FirstDate & "..." & $LastDate. Then it performs Find. Then it sorts the records by the Date field in the job and the Job Number (or whatever), which generates the subsummaries (which are just Day breaks).
One user could be looking at 3/1 to 3/8, one could be looking at 2/4 to 4/4, and so on. There are a lot of other ways, but this will work well and should last you a long time.