I’ve got several forms that utilize dialog lists.Is there a way to make these lists user editable by the users?
For instance, we have rentals in 6 cities currently.
If I wanted to take an account in a new city, I’d have to hard code that into the forms current dialog list. normal users have no way to modify that list.
I could create a city document and create a hidden view.
I could then use that view to populate the list.
Is there an easier way?
Thanks for your time in advance.
Jim
Subject: Editable lists
No, that’s the easiest way to give users full control. But don’t forget that users will need to be able to access the keyword documents, so you’ll need to either create a user view in addition to the hidden view OR give the users an outline entry that will allow them to open the hidden view.
Subject: RE: Editable lists
Not an “easier” way per se, but a more elegant way would be to create an “Admin” document, in an “Admin” view, viewable only by admins, with fields containing keyword lists.
The benefit of this approach is especially evident in database with too many Lookup Views (I recently worked on a Db with over a hundred views) and therefore better performance with fewer searches and overheads.
Cheers,
-Mike Trivedi
President, Trivedi Solutions
mGraph: Superb Graphs of your Domino Data!
http://www.trivedi.com/mChart.html
Subject: RE: Editable lists
Great – as long as the database doesn’t need to be locally configurable. Should a new phone number for a customer company require a Help Desk ticket to resolve? And how does restricting a view to admins eliminate the view? Author access, roles and Authors-type fields can restrict who is allowed to modify the keywords; there’s no good reason to restrict this further.
Subject: RE: Editable lists
Stan, thanks for your response.
Actually, Stan, I just worked with a company on a large database which used an “Admin” lookup view for just that purpose, to reduce the number of views and prevent having to create a Help Desk Ticket to reset lookup items.
Of course a lookup view with such an Admin doc" will not eliminate the view itself; but it WILL eliminate countless lookup views, as I mentioned earlier.
If only Admins are going to edit the keyword docs, there is no need for anyone else to see it; and no need to use Author access or the other features you mentioned.
Again, I didn’t say this was the only solution, it’s merely the
more elegant one.
Cheers,
Mike Trivedi
Not an “easier” way per se, but a more elegant way would be to create an “Admin” document, in an “Admin” view, viewable only by admins, with fields containing keyword lists.
The benefit of this approach is especially evident in database with too many Lookup Views (I recently worked on a Db with over a hundred views) and therefore better performance with fewer searches and overheads.
Cheers,
-Mike Trivedi
President, Trivedi Solutions
mGraph: Superb Graphs of your Domino Data!
http://www.trivedi.com/mChart.html
Subject: RE: Editable lists
Um, no, it won’t eliminate lookup views – at least not if the views are constructed properly in the first place. If the document is subject to lookup, there needs to be a view there to look it up in. What it may eliminate is user views – but there is really no need to have separate views for local maintenance users to look at in the UI. If you don’t use Author access and Authors fields to restrict creation and modification of keywords (other than those derived from “allow keywords not in list” instances), then it doesn’t matter how you restrict the views – any Editor can modify any document regardless of whether you’ve hidden an “admin only” user view or not. Restricted access views are not a solution – they are extra views that generally serve no purpose. (The only good use I’ve ever found for them is when they are coupled with a Form Formula on the web.)
Subject: RE: Editable lists
Um, Stan, YES it’ll eliminate the lookup views. It’s really a cool way of doing lookups without having to have “separate views”
This is how it works:
Say you needed two lookup views in your app, one for all possible State abbreviations and one for area codes.
Let’s assume that both these lookup items have so many choices (over 200k) that it is not possible to include them as variables in code.
So how would you populate choices for a form field?
As you said, an “admin” view for each of these lookup values would still be a view; thereby adding to performance issues, especially in large databases.
The solution is this:
One view (only one) containing ONE document which contains two fields containing all possible lookup values.
Thus, you don’t have two views for the lookup, but ONE view with a doc containing two lookup values.
I know this is a little complicated, but if you have numerous lookup values (one database I worked with had over 40) then this is the only way to go…
Hope this helps,
-Mike Trivedi
President, Trivedi Solutions, Inc.
mChart: Superb Graphs of your Domino Data!
http://www.trivedi.com/mChart.html