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
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?
Scenario: We have four databases that are setup to inherit from a master template and they in turn have individual design elements that inherit from a different master template via template name added in the field shown in image.
It has always been my understanding that in order for the individual design elements in the database to inherit any changes a version of the master template must also be on all servers where the database resides so that the nightly server process will make updates to the design element(s).
Is this true? Does this change when creating a build using Teamstudio CIAO Builds/Promotions?
If you want changes to any design elements to be automatically picked up from templates overnight - regardless of whether they inherit individually as in your screenshot, or inherit from the template named in the database properties - then one of the following must be true:
If the database is replicated to multiple servers, then the templates must be on at least one of those servers; or
If the database is only on one server, then the templates must be on that server.
So, if you have a few databases that are on one server each and not replicated, and they inherit from the same templates, then you'd need those templates on every server to get automatic overnight inheritance in every database.
However, there's no need to rely on automatic inheritance, as users with Designer access to affected databases can manually refresh designs from templates using the Notes or Designer client. If you do this, you can keep the templates on just one server regardless of how many servers have databases using those templates.
Note regarding template designs in any case, whether databases are automatically or manually refreshed: Best practice (as I understand it) is to have production template designs signed by a single user id created for the express purpose of signing designs, with a Domino policy in place to ensure that all users Execution Control Lists (ECLs) trust that signer, to prevent users from getting ECL alerts when using production applications.
My experience with Teamstudio CIAO isn't extensive, but I don't think it changes any of the above.
CIAO! / Build Manager uses the IBM Domino API to perform a Design Refresh, therefore it does not need to wait for the nightly Design task to run.
CIAO! / Build Manager calls the Design Refresh API and passes the Target DB info and then name of the IBM Server where the template resides. Therefore for a full design refresh of a Target db the Template does not need to reside on the same server.
If you have indicated a Design Template for individual Design Elements within a Notes Application, then in this scenario the Master Template would need to reside on the IBM Domino server where the Notes Application also resides. The CIAO! / Build Manager application does not include the capability of updating these individual Design Elements.
We have a production SharePoint site that uses a custom database quite a bit. We have a dev site on a separate box where we develop all of our things then move them over to a live site when they are ready for our customers.
We have many pages that use data views to show information from the database. Most of the actual programmability is done with stored procedures and UDF's in the database itself. One of the problems we are having is that when we try to move these custom pages over from one site to another (even if within the same SharePoint installation), the data views become broken. As far as I can tell, the data views are associated with data connections via a GUID. We can go in and set up all of these connections by hand on the new site, however there is no option in the data view webpart to change the data view's associated connection.
At present, this pretty much prevents us from developing on a separate site at all. Doing a command-line SharePoint export/import is an all-inclusive way of accomplishing this. However, ignoring the limited options for this operation, it is at best unreliable. Our first attempts left out some of the content (like custom aspx pages). As we began to create more complex customizations on the SharePoint site, the export function stopped working altogether only to return cryptic errors.
Has anyone else found a good way to do this?
You can do the following:
Create a new page on the destination sharepoint and include an empty data view
copy/paste the old code into the new page
Replace the webpart id of the old dataview with the new one
It worked for me, although I'm still struggling with some complex forms that use drop-down lists that lookup their values in the database depending on other fields. For that I use custom datasources and on the original site they work... but haven't had success in copying it to the new one.
The biggest problem I have faced so far in sharepoint, is to be able to make a certain webparts invisible or hide if the user is not logged in, basically to be able to make an audience for anonymous user.
If anyone knows how to do that, please help.
As far as I know the only way to do that out of the box is to wrap the complete Web Part Zone in a SPSecurityTrimmedControl.
Another thing you could try is to create Control Adapter for every single Web Part type and then implement the display logic in there. Please notice though, that this approach has some limitations. The most important is that all Control Adapters will be applied to every single Web Part in the given Web Application of the given type.
A little trick I use is to hide the web part in your CSS (either your master CSS or another web part), and then use ANOTHER web part - this time targeted to authenticated users - that overrides the initial CSS, making the content visible. I wouldn't recommend it for secure content, since the web part is still being rendered at the client, but if you're going for UI elements, this works perfectly.
How do you manage deploying InfoPath forms to different sharepoint servers? Is there a better way to deal all the data connections being site-specific without opening the forms, editing the data connections and republishing for each environment?
This is a common problem, if you are working on a dev-system and need deployments to a productive system from time to time. I use a script that performs (plain text) replacements based on regular expressions.
on each deploy:
make a backup of your form ;-)
Save your form as source code. (I suggest you work on source code files rather than the .xsn, because the xsn is only a renamed .cab with the source files in it. And you are able to use source control in a more satisfying way.)
open the manifest.xsf file
search for the xml node "DataConnections"
search and replace the site-url part
(Do not forget the save-path, file-&site attributes and publishUrl)
deploy from the InfoPath Designer
I use a script that does all the replacements. That works fine and already saved me a lot of work.
If I understand your scenario correctly:
You have an InfoPath form, with data connections that submit your data.
You wish to deploy this form on multiple SharePoint Servers and have those data connections submit data to the currently deployed server.
You can't really get around needing to do work on every SharePoint server that you would want to deploy the form to. However, you can get around needing to modify the InfoPath Form Template.
If you use the SharePoint Data Connection Library (DCL), and create a UDC file from your data connection, on every SharePoint Server that you would want to use...then your InfoPath Template can just talk to the UDC file.
Here's a link to an article about integrating InfoPath with SharePoint's DCL:
http://msdn.microsoft.com/en-us/library/bb267335.aspx
If you go into the submit options, there is an option to perform custom action using rules. If you have all of the data connections set up, you can configure rules to select which connection to submit to.
re: speedfox's answer, try to stay away from editing the manifest whenever possible. It'll just lead to head aches.
If I understand your problem, you're deploying to multiple servers (DEV, UAT, Production) and need to edit the data connection manually every time you go from one environment to another? Forgive me if I've over simplified the problem
I've found the best way to make data connections site relative is to:
Use data connection files in your form. Open the data connection wizard in infopath and for all of you data conencting click "Convert..." this changes your data connection from being embedded in the form to being an independant XML file. You'll need a Data Conenction Library on you sharepoint site to store these in. Create that in the browser.
After you've converted and the connection go back into it and there will be a Connection Options... button use it to change from "Local data connection library" to "Centrally managed connection library"
Upload the data connection that is in your sites Data Connection Library to central admin
When you publish your form make sure you're publishing to a centrally managed location (Central Admin)
Use your form as a content type in any forms library on that site collection.
To use the form on another site, upload the data connection file to the new servers central admin and publish the (unchanged) form to the centrally managed forms.
See my blog post where I take you step-by-step with relevant snapshots covering the following:
a. Converting InfoPath Data Connections to DCL library in SharePoint.
b. Publishing InfoPath form to a SharePoint List/Library
c. Creating a .wsp solution package for the InfoPath form and its code-behind
d. Creating a batch script that will deploy the InfoPath form on your Production site.
e. Ensuring the InfoPath form has been deployed as a feature
f. Modify the DCL's in the production environment.
g. Associate the InfoPath Content Type with the Document/Forms Library
See the full blog post at: http://www.sharepointfix.com/2009/12/infopath-2007-form-and-nintex-workflows.html
By site-specific, do you mean that the data connections in your forms refer to the server the form is deployed to? If that's the case perhaps you could tweak your connections to use localhost instead of the server name for the hostname part of the data connection URLs.
In my scenario, I am not using the built-in "save" button. I have a data connection that I use to "post" the data to another list.
Yes, that's what I mean by site-specific. I don't think you can use localhost 'cos then when a user saves the form, it'll try to post to the user's computer (i.e. localhost). I have tried to use relative paths but that doesn't seem to work.