Profile Document - Validation (grr)

HCL Domino Domino Forum
1

Almost all set to start using Profile documents (a great feature I’ve never added to date).

Problem is, evidentally profile documents enforce all of the features of the form they are created from, INCLUDING FIELD VALIDATION.

Very annoying, I can’t remove my validation from my master form and I really really don’t want to move my validation into a formula at QuerySave or whatnot (not to mention I don’t think this would do anything for me anyhow)

So either I need a way to bypass validation (of course this will now be a administrative hack I have to apply on all my databases, not fun) or maybe I’m doing all this wrong?

Thanks a million to anyone who can help.

2

Subject: Profile Document - Validation (grr)

I’m confused. Why would you want to use the same form to create both regular documents (for which you’d want the validations) and profile documents (for which, apparently, you don’t). Since this is not normal, experiencing this conflict isn’t normal, either.

Perhaps the answer to “maybe I’m doing all this wrong?” is Yes…Just what are you trying to do?

3

Subject: RE: Profile Document - Validation (grr)

Well,

I’m using this for storing default values for now, as you can imagine however, not all fields need default values, however some of these fields still need validation.

I know what you’re going to say probably, which is “just put in anything” However since the user will be the one changing these default values (instead of going to me every time) I preferably don’t want to have to say “yea, you’ll need to put something in those fields for validation but really they aren’t needed at all” - I know it could be worded much differently, but still, I hate “stepping around” design flaws.

So my approach could still be wrong, but I do have a valid reason for this.

4

Subject: RE: Profile Document - Validation (grr)

Sorry, still don’t get it. Why use the same form? There just ain’t no need, as they say. If it needs to look the same, then copy the user form. If it doesn’t need to look the same, then create a new form that is more obviously for the profiles.

5

Subject: RE: Profile Document - Validation (grr)

I’m responding to all 3 posts:

First of all, to the 2 other suggestions, with how particular my managers are about the databases aesthetics really stand out, a big no-no is a button, and as for storing the last value, while probably 99% foolproof, I think it could lead to errors all the same, better the more experienced users edit the profile and not risk the newbies from creating 100 invalid documents.

Stan,

My understanding of profile documents is you get 1 per form and is forever associated with that form (even the command to edit the profile document uses the formname)

But you are saying I can create a separate form, and have it’s profile associated to a separate form? I may be making it much more complicated than it has to be.

Maybe I have the whole concept wrong, I’ll do my research…

6

Subject: RE: Profile Document - Validation (grr)

Yes, you get one profile doc per profile form (unless it’s also uniquely keyed, as a user profile would be), but the profile form you use doesn’t have to have anything at all to do with a “regular” Notes form. You can use @GetProfileField to get the information from a profile document for use on an ordinary, run-of-the-mill, document-creating kind of form for use in Default Values, Input Validation, etc.

7

Subject: RE: Profile Document - Validation (grr)

And again: If you’re using only @getprofilefield and @setprofilefield, you don’t even need to create a form. (And if you do create a form, it will never be used, and its validation code will certainly never fire.)

“a big no-no is a button”

If you’re not using a button to launch the profile form, then what does launch it, and couldn’t that code use @setprofilefield instead?

“My understanding of profile documents is you get 1 per form and is forever associated with that form (even the command to edit the profile document uses the formname). But you are saying I can create a separate form, and have it’s profile associated to a separate form? I may be making it much more complicated than it has to be.”

Yes, you are, and I think I see how. It looks like you think that a profile document must be based on a form that has been used to create a regular, non-profile document, and that it can only be used to store defaults for the fields in new instances of that normal data document. You seem to think that if you have code in a form that uses @command([editprofile]; formname), then that code must use the current form name as the formname argument. And that’s completely incorrect. The faster you disabuse yourself of that misconception, the sooner you’ll be more comfortable with profile docs.

Since they’re invisible, the use/function/value of profile docs can be hard to grasp. Understand that they are just like regular old documents, except they don’t show up in any view. Like any other document, they can contain any data you want to put in them, for whatever reason. Common uses of database-type profile documents (as opposed to keyed, or user-specific, profile docs) are to store keyword lists for list field choices, file names of databases that need to be accessed by code in this database, database preference settings, etc. Note that none of these have to do with the default values of fields, although you certainly can do that. You can even store more than one commonly-used value for each field, and provide all the choices when entering new data.

So hopefully you understand now why Stan suggested in his first post in this thread that not only do you want another form for your profile doc to get rid of the validation formulas, you also want another form for your profile doc so that the user isn’t confused by the identical appearance as to whether he’s working on a data document or a profile document. (Also, you probably don’t want to store defaults for every field in the data form, do you?)

8

Subject: RE: Profile Document - Validation (grr)

Thank you very much guys for all your time, it does seem very clear now, I had mentally blocked that possibility (albeit obvious).

Working great too, this is going to save me alot of time even if I have to use the feature myself, saves me time from firing up Designer (and watching it crash 2 mins later).

Bruce,

Since you seem very knowledgable about profile docs and I seem very lazy to test everything, just a few questions:

  • Can I delete the form from the design after editing my profile doc, or will this delete both?

  • Your first sentence seems to indicate I don’t need a form to use those functions? How exactly does that work (I assume you’re not suggesting what I was originally doing)

I ended up creating an action menu agent (nobody around here uses the action menu except for a few custom agents) so while it’s an obscure feature, nobody will scrutinize it’s placement.

Again, Thanks, this helped me alot.

9

Subject: RE: Profile Document - Validation (grr)

“Can I delete the form from the design after editing my profile doc, or will this delete both?”

Deleting any form will never delete any document, either data or profile.

Are you thinking of using an existing profile document created with the data form, and from now on editing it with a dedicated profile form? 'Cause that won’t work due to the mismatch in form names; you should delete any existing profile document (You have to use LotusScript to do this using db.getprofiledocument and doc.remove.) and start over.

“Your first sentence seems to indicate I don’t need a form to use those functions? How exactly does that work (I assume you’re not suggesting what I was originally doing)”

Nope, I wasn’t suggesting what you were originally doing, because you were originally (and still are) using @command([editprofile]) or @command([editprofiledocument]) to open the profile document into a form for editing in the UI, and that most definitely requires that the form exists.

Exactly how it works is based on the fact that neither @get- or @setprofilefield uses a form in any way; they access a profile document directly, no form necessary. Specifically, here’s what @setprofilefield(“formname”; “fieldname”; “value”) does: It searches the current database for a profile document with “formname” in the Form item. If it finds one, it looks in that document for an item called “fieldname”. If it finds one, it replaces its value with “value”. If it finds the document, but not the item, it adds the item to the document. If it doesn’t find the document, it creates one with a Form item containing “formname”, a $UpdatedBy item containing the name of the code runner/signer (depending on whether this is front end or back end code), and an item named “fieldname” containing the value “value”. Note that no form is ever accessed in any way, and therefore doesn’t need to exist; in this case, the formname argument serves as nothing more than a unique key to differentiate this profile document from any other database-level profile documents you may choose to create in the same database.

“I ended up creating an action menu agent (nobody around here uses the action menu except for a few custom agents) so while it’s an obscure feature, nobody will scrutinize it’s placement.”

To restrict who can use that Actions menu command to run that agent, make sure to assign authorized users a role, and then check for that role in your agent code, exiting the agent with @return(@prompt([ok])) if an unauthorized user runs it.

10

Subject: RE: Profile Document - Validation (grr)

Better yet, don’t have a separate screen to set the defaults. Just design the “regular” form to store in the profile the value the user enters in each of the defaultable fields when they create a new document. That way, the form just “remembers” what values they entered last time and repeats them. Most of the time that’s the value they’ll want to use in the next document they compose.

11

Subject: or give them a button to click when they want to store the current set of field values as the defaults – then you don’t even need to create the profile form.