How to do this in Notes

Hi, I suggets you to create a configuration docs with users and roles so they can modify the access from this document and not from the Access Control List.

Then, create a script like this example i've found, but adapted to your problem, selecting only the subcategories as per notes user and then performing the appropiate selection formula. give me more details i'll give you som further help:

Sub Click(Source As Button)
Dim uiw As New NotesUIWorkspace

Dim uiview As NotesUIView
Dim uidoc As NotesUIDocument

Dim view As NotesView
Dim one As String
Dim two As String
Dim doc As NotesDocument
Dim formula As String
doc.Form = "Finance"


one=uiw.Prompt(Prompt_OKCANCELEDIT,"Geef de start datum in","Start Datum (DD/MM/YYYY) ","")
two=uiw.Prompt(Prompt_OKCANCELEDIT,"Geef de eind datum in","Eind Datum (DD/MM/YYYY) ","")

formula = | SELECT datum > [| & one & |] & datum < [| & two &|] & doc.Form = Form |

Set uiview =uiw.CurrentView
Set view =uiview.View
view.SelectionFormula = formula

Call uiw.ViewRebuild

End Sub

Although that technically works, it violates just about every best practice concerning document security and view design.  It's a good example of what can be done, but not good in an enterprise environment.

fredniels answer is as Bill-Hanson stated definetely the wrong way...
it would actually require users to have designer rights (so they could modify the selection formulas on views, unless it's private views), so very bad

then it would mean that the seletion formula would change for every user which would mean each user changing it would change it for the other connected users to.

but to enhance Bill-Hansons proposal:
you could indeed, there I agree with fredniel, create configuration documents to setup a kind of "default" access, authors and readers, for the category/subcategory combinations.

ie. in the config doc you would have fields:
category/subcategory (or multiple values if required) and defaultReaders/defaultAuthors (but those fields would simply be "names" fields not real readers/authors fields

in your main documents you would then have 3 fields, actually 6, 3 per readers and 3 per authors (here only the readers are listed, apply the same scheme for authors):
defaultReaders: computed names field with values from config doc
additionalReaders: editable names field
docReaders (the way I usually name real readers fields): computed reader field: @trim (   @unique( defaultReaders : additionalReaders ) )

same for authors...

that way you give a "default" setup but you allow authors to give other users read or author access

you could even setup roles in the ACL and add those roles to certain config docs so you could easily use ACL grous assigned to those roles to modify basic access:
ie: [marketing], [engineering],[administration]  to give those roles read and/or author access to the relevant categories

importang:
author fields DO act as reader fields to! so if a user is in an author field but NOT in a reader field he anyway will see the document and be able to edit,
the general db access would then be: authors for everyone (in order that they can at least create documents)

if the whole thing is JUST about readers forget the part about the authors and simply apply it for readers but be aware of the fact that you should add a default as well (usually [Designer] : [Servers] and/or [Admin]) otherwise it can occur that no-one can see documents anymore under certain circumstances!

need more info:
>  The user has requsted that the application be designed so that documents of each subcategory be visible to some users but not others and that they can modify that access on their own (without using the ACL). (Note that each category can have completely different subcategories.)

By visible do you mean not accessible at all just not seen in the view? What kind of access do additional users get?
(For a feel of the magnitude:  How many users?  How many roles?)

I think you need to look in the Designer help, especially the topic 'Application Design'.  Review the subtopic 'Creating a workflow application' also in Topic 'Application Management', review subtopic 'Application design element security', articles about readers and authorts fields.
Remember that to enforce access, normal users should have Author acces to the database.

Very handy references:
Lotus Notes client help, Domino Designer Help and Administration Help. You should peruse these, to get a feel where to look for stuff.
Lotus Domino Release 5.0: A Developer's Handbook: http://publib-b.boulder.ibm.com/abstracts/sg245331.html?Open
Domino Designer 6: A Developer's Handbook: http://publib-b.boulder.ibm.com/abstracts/sg246854.html?Open
Lotus Security Handbook: http://publib-b.boulder.ibm.com/abstracts/sg247017.html?Open
Lotus Notes and Domino Application Development wiki: http://www-10.lotus.com/ldd/ddwiki.nsf

Thank you so much guys.  This gives me a number of great ideas.  I'm going to look further into the reader/author fields.  I'm not familiar with those, but it just sort of 'feels' like the right approach from what I'm gleaning from your comments.  As soon as I know for sure, I'll flag a solution.

To answer the question about scope, there would be approximately 15 different roles and about 30 - 50 users.  The reason for the various roles is that there are about 14 different facilities that will be submitting information and an overall coordinator.  Users from the various facilities should be able to see each others documents, but only be able to update the documents for their own facility.  There are some additional documents (in a separate category) that should only be visible to the coordinator and the members of the facility that added them.

Oh and to answer the question about visibility - my thought was that they just wouldn't show up in the view for any user that doesn't have access.   I'm not sure its necessary to go to any extraordinary lengths to prevent a doc from being accessible.  I don't believe the info is quite THAT sensitive.  But I'm not averse to a simple solution that does both.

I mentioned it because reader fields can have performance drawbacks (server needs to compute visibility) in large databases where only a small portion of the documents are visible to a user.

From your extra info, I would only put reader fields on the separate category.

I think you will be best served with assigning Author access for most users, and assigning roles to groups. When a user has a role which is in an Author field in a document, he can edit the document.  If not, he can only read the document.

That's actually the approach I'm taking now.  So far, it looks to be exactly what I needed.  I had actually already decided on the roles and groups, but implementing it was a challenge before I understood what reader/author fields were.  I'm coming from a relational & .NET background and many of the concepts don't translate well to Notes.

Thanks again.  I'll let you know how I make out.

Bear in mind that Notes is NOT relational, so you may run into problems if the list of users in a particular set ever changes. To alleviate this, have a Group document created in the Domino Directory for each unique access combination (site, plus one for the central admin). Place the group name in the readers and authors fields. You shoudl come up with a naming convention, something like:

Authors_AppName_CentralAdmin
Authors_AppName_SiteName
Readers_AppName_SiteName

It wasn't the solution that I was expecting, but I was brining a non-Notes mindset to a Notes problem.