Disabling "Allow Creation..." at the fly

[Ugo DI LUCA]

(make sure you download the updated files...1 post down)

Hi,

Here is how I dynamically switch from a portal with relationship set to "Allow creation of related records" to a scripted method.

There are some times when this kind of tip could really be useful. At least, I know when and why to use it

Thanks and keep telling me if there are other methods...

[color:"red"] Edited Important The file is working fine, but there are some "validate by calcs" in the related file sets to return error messages. These messages by-pass the classic FM alert when you enter a text field in a date field or in a "hour" field....So do not try to enter a text field in a date field, and it will be fine.

Plus, do not try to enter the first record (left) in portal as this is the auto-enter Child_Id and cannot be modified. Start with the text.

Glad to already have had some return on this even if this was some "user errors"

Disablig Rel Set.zip

[Ugo DI LUCA]

Hi,

Don't blame me for that. It's on my bad habits to post samples before I got all "problems" solved.

With this one, you can switch with more confidence (you'll be alreted for any prior empty related record created accidentally).

Here are some reasons why this tip could be helpful

- You want some users to be able to create related records, other could just browse the records (no need for Access Privilege)

- You want some of your datas to be entered automatically, implementing lookups in the related file when the record is created....and some other to be scripted depending on some criteria (the Customer category is one for me - Some products would get their prices from a separate Product database when scripted -)

- More flexibility when using a line item shared by multiple dbs (I had the problem in this old post (one of my first-sorry if it's confusing. I now know why noone answered to this one even if it is now solved with the Multi-line Item solution.

Disablig Rel Set.zip

[cjaeger]

Hi Ugo,

unfortunately, this technique does not really work as it allows the creation of empty records.

why not use 2 layouts with 2 different portals, one allowing, one disallowing record creation? (in FM 5 or lower)

or -

why not use access privileges allowing creation of records only when global is set? (in FM 5.5 or up)

[Ugo DI LUCA]

Hi cjaeger,

Yes it allows creation of an empty record, and that is why included in the second attachment is a calculation to identify this record.

In this updated sample, you will notice that when entering a record in a portal with restricted entries, the user is prompt to use the script instead (or to unlock). As I said, this is not only a "Access Privilege" tip. There are other reasons why we could prefer to switch from a portal to a set of globals, independantly of the access privileges.

Anyway, this calc is used when scripting an entry.

When identified, the user is alerted to either

- use the empty record

- delete it.

In my real files, this calc will be used within the Interface scripts (navigation) in order to prevent any empty record to be attached to the Main file.

[cjaeger]

>There are other reasons why we could prefer to switch from a portal to a set of globals, independantly of the access privileges.

I understand that. I often use a set of globals duplicating the record in order to review &check the entire record before it is entered, using a "submit" button to actually create/modify the record's in question. Especially with portals which have more than 100 rows I find it a lot easier if the user can submit into fields which are above the portal (all portals visible to the user do not allow record creation directly in this case).

[Ugo DI LUCA]

Hi cjaeger,

Sometimes, the easiest things are just the best tips. I hadn't considered "Privileges" as the first request for this tip, but reconsidering your suggestion, here is how to do it.

Considering both "Privileges" and "NeedMoreRecords" situation, let's control the entry in fields using a script (each field in portal is a whole button).

I'm not updating the sample as it needs to stay simple (IMHO), but I'll let each member decide upon its own needs...

3 conditions global locker

- 0---> "Allow creation of Related records"

- 1---> not "Allow creation of Related records" based on Privileges (Browse only)

- 2---> "Allow creation of Related records" [color:"red"] with the globals on Some system situation (wich was again my first concern ) or based on the proper user choice (wich was my second concern), with another menu ( choice 2 for Globals, choice 1 would lead to g_locker = 0)

Then :

Attach this script to each field :

If (some system situation require use of globals)

---If(acces privilege is OK)

---Set (g_lockerkey, 2)

---End If

---If (access privilege is not OK)

---Set (g_lockerkey, 1)

---End if

End If

If (not some system situation)

---If (access privilege is OK)

------If (User choosed set of globals - (choice 1))

---------Set (g_lockerkey, 2)

---------End If

------If (User choosed Portal)

---------Set (g_lockerkey, 0)

---------End If

------End If

---End If

End If

If(g_lockerkey = 0)

---Go to field (related)

End If

If (g_lockerkey = 1)

---If(Is Empty (field related)

---Show Message " You don't have authorization to create records"

---End If

---If (not is Empty (field related)

---Go to field (related) - The calcs defined in the Related file using the Validate by calc in "Define fields" will prevent any modification

---End If

End If

If (g_lockerkey=2)

---Perform script (go to set of globals)

End If

The script is not easy (may be I'll need to check this back), but the technique is OK.

As it "always" happen that someone would accidentally enter a new row, I'll keep the "check for empty related record" script either :

- in the "interface navigation" scripts

- in the "create new record using global fields" script

Hope this make sense

Thanks.