A business owner of my ticket tracking app in Xpages wants to track every change to the document. If a user opens the doc in edit mode but doesn't change anything, then no tracking. If, however, they open up a document and change one field, I have to capture that.
Here is my solution. When a user edits a doc, I create a "shadow document", which is a "before" vision. When the user saves I am comparing field for field for changes, and then acting appropriately.
Is there a better way to do this?
This is another good use case for Java beans. If you create a bean which sits between XPages-UI and Domino back-end document then you can easily track field changes.
Karsten Lehmann wrote a blog about it some time ago.
... and you could use the OpenNTF Domino API that has functions for exactly this. As far as I remember there is an example of this in the demo database. Not sure if it is also in the new version of the demo database - but then you may just need to find an older version (e.g. for milestone 4.5 where I saw this).
/John
Related
We have a (super)user who has been using VBA in an Excel spreadsheet to create and manipulate documents in a Domino database application.
The user has 'Editor' access to the application, and should normally be able to create/edit the document contents.
They have been, however, creating documents using VBA. That logic doesn't consider such important document fields as Readers, Authors, etc. .
We would like to restrict access to all Domino data so that it can only be created/modified using an IBM Notes client.
I have tried looking through the ECL, but that only restricts what 'others' do.
Since he has his Notes client available, the external logic is using his normal Notes credentials.
I have tried setting a hidden field with the Notes client and looking for that in the QuerySave event of the form design.
Unfortunately, the external code pays no attention to the form events and the save is executed despite the missing field.
Similarly, the Database Script has no bearing on the execution of external logic.
I was going to inspect the client version upon database open and restrict activity based on a variance in the version (I was hoping!).
I have de-selected the 'Don't prompt for a password...' option in the user security preferences, but that has no effect at all (suspected as much!).
The ONLY thing I have been able to suggest is to hide the database design... That's really only designed to thwart a user's efforts to understand the underlying design.
It won't prevent them from creating hundreds of thousands of documents with a fictitious form and throwing the app into disarray.
I'm hoping that there is a solution out there that I'm missing.
The user has been instructed not to undertake such activity in the future.
We were lucky that there really wasn't any malicious intent - "Just trying to be more efficient" we're told.
The effects of the activity have been remedied, and the user has been warned.
What I want to know is... how can I prevent this from ever happening again?
The circumstances are rare I know, but I would've thought there'd be a means of restricting the platforms used to manage Notes/Domino data.
Is there a way to ensure no external applications are able to access, create or modify Notes database documents?
I am currently focussing on access to Notes via COM.
I thought that, if I unregistered 'nlsxbe.dll' from the registry, that would prevent such activity - It has not.
I also tried removing the .TLB files from the Notes executable folder - removal of 'notes32.tlb' and 'domobj.tlb' have no effect at all. Removal of 'ltsci3.tlb' screws everything up (as expected!).
I'm really having no luck at all - Any/all suggestions would be most appreciated!
I'm not aware of any way to detect that a connection has been made by standalone code instead of by the Notes client, but you do have two paths available to you:
A Domino server add-in that prevents documents from being saved in that particular database if certain criteria aren't met.
An agent that is triggered to run shortly after documents are saved or modified in that particular database. The agent code can delete (or modify, if you prefer) the documents that don't conform to the required criteria.
The server add-in route would normally require coding in C, but thanks to the Open NTF Trigger Happy project, the hard part is done for you, and the rest can be filled in with either LotusScript or Java agent code that is "triggered" by the pre-written C code. You will need to have some basic knowledge of how the Notes Extension Manager interface works, but once you get past that and write your agent code to enforce your data consistency/integrity requirements, the only real hurdle is your willingness to host open source code on your server.
There may be two other possibilities, but I can't say if either will solve or deal with the issue...
In the ECL you can disable 'COM' access for the user (also known as OLE or ActiveX) automation since VBA access is usually via COM. This has stopped Notes using external COM access for me, but I don't know if also prevents VBA using Notes. Additional steps may be needed to enforce the ECL and apply to the specific users.
There is an (old) notes.ini 'DisableExternalApps' (or something similar) that disables some external access. This can affect many things (DDE/Prompts/#dblookups) but again I don't know if this will disable VBA/COM and its not user specific, but server wide.
I would have thought that removing the nlsxbe.dll or restricting access to execute it might work, but the ECL may be the best bet.
Alternatively, rather than add hidden flags to your design (and the documents), and then delete the offending documents, your agent could apply the correct author/reader fields to the documents instead.
Very tricky. Did you find a better solution?
I recently made changes and created two forms in a database residing in a production server. When I sent out the link, the users are getting this error:
Unable to create document, database does not contain design.
I suspect that the database residing in their Workspace is not getting the latest design elements (not in-sync). I tried asking one user to remove the database from her Workspace, sent the link to the database to open it again, and click on another link which I provided to open up the two forms and she was able to access the forms.
May I ask if there's any other way I can do for them to not delete it from their Workspace and re open it again so it will get the latest design elements? Should I request the Notes Administrator to perform some codes in the console?
Form designs are cached by the Notes client, presumably to aid performance. As far as I know, it's not possible to disable the caching.
If users have a database open when you modify or add forms, it's usually necessary for them to close and reopen the database to see the design changes, but they shouldn't ever have to remove the database from the workspace and re-add it. I don't think there's any way to avoid having to reopen the database.
I have seen a problem affecting several users at one customer where Notes wouldn't update its design cache, no matter what they did inside the client. The only solution I found in that case was to close Notes, delete a file named "cache.ndk" from the root of the Notes data directory, then restart Notes. It's been 2 or more years since this last occurred, so it might have been fixed in some version of Notes.
i am using domino designer 8.5.3 and my notes client and server are also above version 8. Manager level access is given to the user and run on behalf of field is also set correctly. can anyone tell me how to start out of office service through java code.
There is some sample code in this question that shows how to access the Out Of Office profile document.
For the rest of it, I can't answer your question, but I can teach you how to answer your own question.
The fields in that document control the Out of Office settings. You want to change those settings in code, so you need to figure out exactly what changes occur in those fields when you manually do what you want your code to do for you. You will need to analyze those fields to figure out which ones changed when you do it manually. These are the fields you need to change in code.
You can use NotesPeek to look at the fields and their values. Doing this before and after making manual changes to the settings, and compare the values of the fields should give you everything you need to know, but because of caching of profile document values, I would recommend the following steps:
Use NotesPeek to examine and record the field values in the Out of Office profile
Using the Notes client, manually make the changes to Out of Office settings exactly as you want your code to do.
Shut down Notes completely. (This means the client, designer, and admin clients, and NotesPeek. Everything. If you have any doubts, just reboot.)
Use NotesPeek to examine the field values in the Out of Office profile, comparing them to the values that you previously recorded. Note what has changed.
Then just write your Java code to modify the appropriate fields, and save the profile document.
We have a doc library, Requirement is that only the user who has contributed to the document should be able to see the document and other user who has access to the library should not see that.
Can you please help me to achieve this.
Update: I talked to my TL he said, we need multiple Views on the Doc Library. Any one with new Ideas?
Add a custom view to the document library that only displays the items if the current user == creator of the document.
Set this view as the default view.
Prohibit users from changing the view.
If you are after a true permission based solution, you could develop a event handler for the adding item handler that sets the permission on the newly created item.
(By breaking parent inheritance also)
Set only permissions (owner) for the user that created the item.
EDIT: Just re-read your question. I didn't understand correctly. I missed the "contribution" part. Anyway, I will let my answer be here.
Adding a view is not really good practice. If one want's to gain access to the data he can do so by working with the lists web service. the solution is much simpler then it seems.
1. you need to install this: http://spdactivities.codeplex.com/.
This add-on will add you work flow activities to the SP Designer.
2. create a workflow doing what you described. It will take you no more then 10 minutes.
That's it :)
I'm using the built-in Domain Catalog database to list all the databases on a particular Domino server. I'm creating a custom view to show certain information about each database. What I'd like to have is a column that displays the creator of each database. However, if the Domain Catalog is keeping track of this information, I can't find it.
Is there a field in the Domain Catalog that provides this information that I just haven't been able to find? Is there some other way I might find this information and get it into this view? #DBlookup and related functions don't work in column formulas.
That information is not stored in the catalog, and is probably not stored in the database either (It's not shown on any of the property tabs).
You would probably need to get/write a server add-in to monitor database creation and store that data somewhere. Then you'd need to account for databases created by adminp/replication - your add-in might pick them up as having been created by a server.
This question was also asked in the R4/R5 forums in 1998 and received no answer.
Interesting question. There is no such attribute for database, but you can dig for some clues.
New databases: use NotesNoteCollection and look for some specific design element (icon, for example) and look for first element in $UpdatedBy field.
New copies/from templates: above mentioned method won't work. It will return info from original/template, not current database. In this case, try using Created property of DB and check user footprints after that date - in ACL log (he probably altered ACL immediately after copy), new design elements (probably made new view, folder, agent...) or profile documents.
What Frantisek said. Looking in the log archive (ugh!) may tell you who deployed it, but in a well run environment that won't be who developed it. A list of $UpdatedBy(0) for all design notes should give you a good idea. The catch will be that it mayl be people who left the company years ago. : )