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?
Related
We've a real pain in our project where we ask a team of 50 resources to update a single excel sheet that's placed in a network location and when someone tries to update the data, it's locked by somebody else and they don't update it. So, they end up not updating the data.
I'm looking for an alternate solution like
creating a form in sharepoint/ jira - no sharepoint/ jira developer
getting data in mail - too tedious and lots of rework
creating a custom form and hosting it in local server - might work - any templates on this?
Or, any alternates? I'm out of ideas.
easiest thing would be to create a simple SharePoint-List. All Users can update their data at the same time and the Input-Form will be there automatically. (Can also be exported to Excel)
If you are on SharePoint-Online you could also have a look at Windows Form which provide more flexibility in creating the form.
And if you need even more capabilities you can have a look at PowerApps
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 legacy Lotus Notes application that we want to see if we can make an improvement, first by making a test environment for this application. Currently the application is located on the main server and being replicated every 15 minutes to the web server. The replica on the web server has different forms and views since they are adjusted to display the information on the web browser (in my understanding)
I have made a new copy of the application that is on the main server without any problem. I had some problem replicating it to the web server since I do not understand what will happen to those element design that are not being used in the application on the web server. So what I did was replicating the application from the main server to the web server, then deleted all the design elements on the web test then copy all the design elements from the production environment to the web test.
By doing that I was able to get into the login page then log in. After I login, the frameset that suppose to display the default view giving this error message 'HTTP Web Server: Couldn't find design note'. First of all, I thought this is normal since I could not find the view in the database and that confused me since the live system works without that view present on the database BUT when I tried to access a view that I know present on the database, I still get the same error.
So after all that I opened the web test application on a Lotus Notes client. I can open the views that are exist. Now at this point there are 2 things that I am very frustrated about:
The live system works even when the code specifically mentions views that I cannot find from the Domino Designer. It just does not make any sense
As a test I created a 'Test' view on the web test application. Basically I just told it to fetch one of the form called 'WORec' that contains Work Order information. Into my surprise, the view opens up on the web browser but shows no result, which frustrates me even more since the view 'WOByName' gets all the Work Orders just fine. These 2 views have the same selection formula, so I really do not understand why 1 view is able to show data where the other does not. Moreover if I tell the test view to fetch all the documents in the database it only fetch those documents that are not 'WORec' form
I know this is long but if I can get some pointers on what I am doing wrong here. I am just trying to create a test environment. Unfortunately I never dealt with Domino web application or a replication that completely has different element design.
Let's start with the test view.
When you created the view, you need to first verify it is a Public view. Private views or Shared Private on First Use (SPOFU) views are not what you want here.
also, verify the name and alias of the view is unique to your database.
Next, verify your selection formula is correct.
use formula, instead of simple so you can actually see the formula. e.g.
SELECT #UpperCase(Form) = "WOREC"
Refresh your view designer (F9) - do you see your records coming through?
also, make sure the view is not hidden from Web clients... you will see this in the designer client, when looking at a list of views - a column indicating whether or not it is hidden from web clients, note clients, mobile clients, etc.
if not, open one of the documents up. Show properties, verify the form property in the box (2nd tab), matches the value "WORec". If not, correct your view selection with the correct form name spelling.
Next, you need to make sure you are allowed to view this from the web.
Open the Access Control List (ACL) and add "anonymous" as reader or above.
Open the view in Designer, and Preview it in web browser.
As for the "Couldn't find design note" message - that's not good. You definitely are missing design elements. Whether this is due to a selective replication formula issue, or acl issue, or whatever, is hard to tell. But if you have a Notes thick client and a separate web version, I would recommend different databases (or master templates) and not trying to use selective replication to handle that sort of thing.
As I understand it, you replicated the database then deleted all design elements and manually replaced them by copying from the production web replica. Instead, you should have made a template from the production web database (by doing a design-only copy), and then you should have used the 'Replace Design' feature to update the test web database from that template.
As an aside: an application built the way you describe (two replicas on separate servers, each with a different set of design elements) is a pretty bad implementation. It may have been done in the very early days of Domino, before the "Hide from Notes client" and "Hide from Web" properties were available at the design element level. Or it may have been done deliberately for "security purposes" (which I put in quotes because relying on Domino design element to enforce security on a Domino web application doesn't really make the application any more secure). You may be stuck with this... but you may not be. So before you try to improve or enhance this application, I think you should look into using the "Hide from... " properties on the design elements.
On the other hand, if you stick with the current design, I do want to mention that you're going to need to make sure the ACL settings and selective replication settings on your main and web test replicas match the ACL selective replications settings on the corresponding production replicas. Otherwise, you'll end up with a jumble of design elements when the test databases replicate across servers.
I suggest you to make a new copy of the Notes Database that is on your web server to your test server.
try to open in with your browser and check that all is OK.
open this copy in designer and check that it contains the views that you didn't see previously on test.
I'm not sure that you have really 2 different designs (one for webser different from the one of your main server) so:
- on the main server: open the File/Replication/Option for this application. In advanced, check When web server receives from .... if the design elements is checked.
if not it makes sense that there are TWO different design versions.
Maybe the view you didn't find (on the web server) restricts use? to check this:
- In the view (on the main server) check in the properties of the view the tab with a key "all readers and above". If it's uncheck THIS is the reason why they don't exist on the web server AND that you don't see them in the designer:
If your don't have the role or are not the person which can "who may use this view" you don't see the view and can't copy it.
To correct this simply enter the ACL (file/Application/Access Control) and grant you the corresponding role.
I hope I helped
To quickly summarise my question:
Is it feasible to programmatically change the name of a directory (with both files and sub-folders) in SharePoint? I am expecting that users will have files checked out on at least some occasions what I am attempting the rename.
The background:
I am currently contracting for a company that produces web based software (ASP.NET) with a configurable document management system. The system can be configured to use different underlying systems, with the most common environment being SharePoint (WSS 3).
I have been assigned a task to extend what has to now been a fairly simple system (simply output files into a fixed directory structure, occasionally read). Having never worked with SharePoint before I am doing some research on best practices, and am attempting to work out what is viable. At this stage I do not have access to a testing environment myself, so am limited to reading up online.
One request is to have the directory structure reflect the name (as one example) of the current client - so all documentation for a client will be in one place, and can be accessed externally via SharePoint or other compatible applications. The specification cites that if the name of the client changes then the directory structure should immediately update. My concern is that this will either directly cause errors (eg. Permission denied) or indirectly cause errors (loss of work for users who have externally checked out files).
As a follow up question if there are concerns with the above, is there a better way to implement the above? I have looked at suggesting the users use views to access the structure in SharePoint, however there is a concern from our BA that users will not be able to directly upload new files into this structure.
Thanks
The issue with Folders in SharePoint is that they are not really folders in the way you would expect of a file system. All files in a SiteCollection are stored in one big-assed table on the Database (checkout the AllDocs table).
I cannot categorically say it is safe to rename the folder without doing a bit of testing, I know that the folders "name" is not the key to accessing the document, despite it appearing to be based on the Url you see in the browser.
The best bet is to do a quick test, but I am pretty sure that your plan will not be a problem.
The potential issue is if any Content Query Web Parts etc rely on specific folders to exist or if any other "code" or "pages" look for that folder and not the folderId.
Save the content of the list before you "attempt" it in production. You don't want to loose data.
Checked out documents will still work the way you expect them to.
You may however have to run a crawl again.
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.