Restrict Modification based on DATE

[ab42 0]

I would like the ability to restrict modification on a field or maybe block the record from being modified if its not dated today.

 

For example: I want to be able to add or edit any records keyed today but restrict any modifications to any other records without today's date.

 

Any suggestions????

[ab42 0]

Please disregard. I Solved my own problem.

[Prith 0]

I have a question similar to yours. I have a portal showing records from a related table. In one layout, I want to be able to enter records into that table through the portal and in another layout, I want to just view the records and hence not allow any modification of the records. I actually tried making another relationship to this table and unchecked "allow creation of records in this table via this relationship" and used this to view the records through the portal. But this still allows me to modify records.

 

How can I go about this?

 

Thank You.

 

Prith

[Maarten Witberg 4,753]

if you want to lock a field from user entry in a particular layout, select the field and go to menu bar-> format-> field format and uncheck allow user entry.

 

kjoe

[Prith 0]

thanks kjoe.

you are always there with answers, arent you.

[Maarten Witberg 4,753]

feel free to let me know if it annoys you

 

kjoe

[LaRetta 0]

Hi Prith, Another thing that works well ...

 

On the portal you want to disallow entry, just place a transparent rectangle on top of the entire row, with a simple script attached of:

 

Commit Record/Request (if 7) or Exit Record Request (if prior to 7).

 

In this way, you don't have to restrict at the field level because, even restricting at the field level, they can still click the portal and it'll turn black and look ugly. And you can use the same relationship/portal.

 

Oh, and working with transparent rectangles (particularly in portals where placement must be precise) can be a bugger. Keep the rectangle colored until you get the placement exact because it can be difficult to see exactly where it is; and also it is difficult to grab (you must grab the edges only if it's transparent).

 

LaRetta

[Maarten Witberg 4,753]

nice one, LaRetta. 's like when you go to the hardware store with this problem in your head about this thing you're trying to fix only the part you need has been out of production for like, 15 years and then you come home with this widget that is meant for something completely different but does the job excellently well. well fm's like a good hardware store full of handy widgets and you are the one that knows where to find em.

 

kjoe

[LaRetta 0]

Hi kjoe! As Andy would say ... ROFLMAO!!!!

 

None of my widgets are original, although I hope in my career I discover a few all by myself.

 

I swear if I'd have stayed with 6, I'd have discovered a fix for portal pop. A friend once said, "But LaRetta, many great Developers have tried to solve that!" And I said, "So? What's your point?"

 

Nothing ever wonderful would be discovered if everyone thought someone else had tried everything. And even a blind hog can find an acorn once in a while. Hey Harry, are you out there? This is where you're supposed to jump in! Not sure why this made me think of you, Harry!

 

err, I meant having the 'sayings' made me think of you ... not the blind hog part.

 

Happy widget-hunting, kjoe!

 

LaRetta

[Maarten Witberg 4,753]

I swear if I'd have stayed with 6, I'd have discovered a fix for portal pop

well, I guess it's up to Tom and me then...ok, up to Tom then, because I have no idea what portal pop is....

 

kjoe

[Bush 0]

Loretta, a question about your solution:

 

Why the "commit/exit" script? Wouldn't the existance of the transparent rectangle be sufficient in its own right to preclude entry into a field and not black-ify the layout?

[LaRetta 0]

Hi Ted,

 

A transparent rectangle alone will not stop entry into the fields. Even if the rectangle is on top, if the fields below allow entry, FM will allow a User to enter them (it ignores overlaid graphics).

 

Even if you turn off entry into fields, the portal will turn black and stay black (with transparent rectangle on top) and Users will assume they have the ability to work within the portal when, in fact, they can not. It is confusing and they will continue to try ...

 

With Exit Record or Commit, one click and it clears itself (portal unblackens), so is very clear to them that the portal can not be entered. It is simpler than changing field behavior on every field - particularly if there are several fields to work with and it is clearer to the Users.

 

LaRetta

[Bush 0]

Excellent. Thank you.

 

Followup question: Does the layout change sufficiently in FIND mode that they'd be able to enter those fields to perform a find in them?

[LaRetta 0]

Hi Ted,

 

Prith wanted Users to 'only view the records' and I've used this many times. But I've never allowed a find in a portal nor do I use a portal to create records. I have always provided Users with a Find layout in which I place all fields (including related fields) directly on the layout (no portal necessary) because it is too easy for Users to be confused on whether they are in Find or Browse (when on regular layouts) and they can accidently change information (thinking they are entering Find criteria).

 

Here is what tickles me, Ted, and why I'm so glad you asked this question ...

 

A few assumptions (and mis-assumptions) I made as I considered your post:

 

1) Find Mode does not stop other scripts from activating.

 

2) Scripts act on the current table layout (or file) - even if they reside in a portal so entering Find mode should not stop the Commit.

 

When I read your question, my thought was that the script would prohibit entry into the fields in Find mode; that the Commit script would activate. But a startling thing has occurred instead ...

 

The transparent rectangle did indeed prohibit entry into the fields while in Find Mode - even if the portal field's behavior was set to allow entry for Find! But it was not because the Commit script activated because it didn't activate (at least there was no observable script flash)!!! :eek: The presence of the overlaid rectangle itself prohibited entry - at least that's my hit on it!!!

 

I find this behavior perplexing and quite interesting. I have never observed a graphic itself stopping entry into an 'enterable' field and I have never observed a script refusing to activate while in Find Mode! Tickles me, it does ... and I hope others can provide clarity on the principle behind this unexpected (at least to me) behavior!!

 

There must be a logic behind it but it eludes me and it's probably something obvious! Thank you Ted, for asking such a wonderful question!

 

LaRetta

[LaRetta 0]

Attaching the Commit directly to the field - removing the rectangle - the script will not activate (or allow entry into the field) either, so it's not the rectangle itself.

 

Hey kjoe, by the way, portal pop is that annoying thing people with versions less than 7 have to deal with (smile) where, when you leave a portal it pops back to the top. That's fixed in 7, Tom.

 

LaRetta

[Maarten Witberg 4,753]

hey kjoe, by the way, portal pop is that annoying thing...

oh that. Yeah it really itches.

I tried working around that once in a multi filter by using reverse order sort and then when inserting a new portal row, trying to get that to the top row. and getting the cursor to blink in the first field of the top row.

never succeeded either. the sort was always in the way of the navigation steps somehow. So the sort order did get reversed but the new row was always at the bottom where it got lost, sad and alone. I gave up and have been quite happy since.

but it is yet another item on the slate for upgrading i do admit.

 

kjoe

[LaRetta 0]

Debug shows no script is activated when I have the Commit in a regular script. And I, errr, haven't updated this system with 7.0v2 yet. I'll feel silly if that's the problem. :rolleyes:

 

I guess I'll wait for other ideas. I'm out of them ... for now.

 

LaRetta

[Maarten Witberg 4,753]

LaRetta:

Oh, and working with transparent rectangles (particularly in portals where placement must be precise) can be a bugger.

i have put this neat trick to work. to get precise placements I used the "size" panel to copy the exact values of the field size to the rectangle size. Curiously enough with autogrid off, placement was then a breeze, zoomed to 300%

 

kjoe