Securing Hidden Views in Lotus Notes - security

In Lotus Notes hidden client, hidden views are not shown by default but you can further hide them by using outlines.
But a user can gain access to hidden views by following either of the following
Right click on the database bookmark, "Application" -> "Go To" while holding CTRL+SHIFT
User opens database and goes to "View" menu and click on "Go To" while holding CTRL+SHIFT
In these scenarios users can see any hidden views or views which are only hidden on the outline.
Is there any way to hide those views aside from creating a reader list for each view?

Assuming that you do not require the documents in the view to be hidden. Ben's response is quite good. But I am not a big fan of Reader lists in view designs, even if you're using ACL roles to manage them. Reader view lists are notoriously hard to maintain, and easily overlooked later when debugging user issues.
If you want to prevent UI access to the view but still permit the user access to the documents via the application programmatically, you will need to goto the view's "QueryOpen" event in the Domino Designer and insert the the following code.
Sub Queryopen(Source As Notesuiview, Continue As Variant)
messageBox "Not authorised to access this view"
Continue = false
End Sub
This should prevent a user opening the view via the UI as you described, but allow the application to use it where required. And if so desired later on, you can programmatically control when those views can be access by the UI. I have had a couple of instances where I have had to create control objects that determine which type of user can open/paste documents into a view.
My answer is on the basis you just want to prevent people accessing views. But if you need to actually hide the documents in the view, then you need to consider document level security, and then design your application around that. Admittedly, this will increase the complexity of the application because, if required, you'll need to use agents to run on someone else's behalf in order to act on the documents the user can't see.

Unfortunately, there is not. The only true way to secure anything in Lotus Notes is via the reader lists at the document level, or access control lists at the database or server level. VIews, Forms, etc are just design "documents", so they need to have reader lists applied.
Those other tricks usually suffice if there isn't highly sensitive data. Many users don't figure out that means of displaying hidden views, but of course once they do it's all over :)

Even if you protect your views, any user with at least reader access can make user defined view with all documents. So I think this attempt is silly - don't waste your time.

Related

Filtered and Categorized view on Lotus XPages within Notes client

Hoping someone can point me in the correct direction for an XPages application we are writing inside the Domino Client (Notes?) viewer.
I have a view of documents which is being returned, this view has categories on it, and shows fine as this in an XPage, we now apply a filter to the view to limit it to specific owners of the documents, but as soon as we apply the filter, the categories disappear, which means we are left with a long list of documewnts, but unsorted - is there any way to display a filtered view in a categorized manner, on an XPage.
Moving further down my list, I also need to be able to select these documents (and one or many owners) to send to an Lotus Agent which will then create a JSON document to be sent to our friends at DocuSign requesting signatures from the selected owners on the selected documents. I'm not sure what an Agent is yet, but that is the goal ...
Caveat: I'm not a Domino developer, so excuse me if some of the terminology is incorrect.
Categorised views are a very "Notes" construct. When you filter a view, it will only show documents, but not categories. While they are practical in the back, they are cumbersome in the UI.
There are a few design considerations how to tame them in a webUI. However if your users love them, you might consider to flatten them out and recreate the categories in the UI (client side) only.
The actual better way for your use case: add another view that is firstly categorised by the owner and secondly by your category. Use the category filter of the view control to limit the documents to that author. This should do the trick. Eventually use one of the controls from the extension library.
For the agent: don't bother, that's "old Notes speak". An agent would be a piece of code (LotusScript or Java, but since you do web interaction: Java) that gets triggered by an event: manual, on schedule, on document create/update (with some delay).
Since you are in an XPage, you have easier options at your disposal: create a Bean that has the JSON format you need, add a method that takes a Notes document as parameter to populate it, something like public void populate(final Document doc) {...} and use e.g. the GSON library to simply marshall them to JSON (or a collection of them). The GSON library probably is on a current Domino, I put it there as part of VoP 1.0.
Then use a managed bean to talk to Dokusign. When traveling down the managed bean road is is much easier to test than trying to mess with agents.
Hope that helps and ask more questions! (Check the Learning XPages Cheatsheet too)

How to edit a record(s) with multiple form xpage?

I have an xpage that allows the user to choose a customer and then order products for that customer. It's not a simple xpage that created a document, uses a view control to view it and re-edits it. It will be used on the web and in the client. How do I fill in all the data for the various fields when the user wants to look at their order for a company since there are multiple documents that make up that xpage? Is there automatic processes or do I need to do it manually?
The best method is to use multiple datasources (the Notes documents) each with a different datasource name. When saved, be sure to save each of the datasources that have a change. Also, it is helpful to mark to "ignoreRequestParameters", so each one acts independently.
I have found that using the dynamic content control useful when doing things like this, it seems to reduce the number of replication/save conflicts.

Create domino view dynamically in XPages

I want to know if I can click a button in my XPage and dynamically create a Domino View and then show it in a panel control on the same page. The reason I want to do this is because I have a categorized view and I don't want to lose category data by using full text search. So I am thinking of creating a new view dynamically and pass my search parameters, like end date or start date, into the view selection formula.
Is it possible? Any other alternative solution is also welcome.
yes you can, but you don't want to. A Domino view takes space in the database and quite some time for its first use. So you end up with a lot of views taking space and the need to adjust database space after removal. Your response times will suck big time.
Categories as shown in Notes views are no web interaction pattern, so you might want to solve a problem that actually shouldn't exist.
The preferred method for Domino application is navigation / drill down over search. But you could do a FTSearch where you add your category to the search parameters and render your results in a repeat control instead of a view control. There you have more control over the look and feel.
Whether or not it's the best solution, the answer to the immediate question about creating a view on the fly is yes: the Database class has a couple "createView" methods to allow you to create a new view, either entirely from scratch or based on a named other view. From there, you can use the "setSelectionFormula" and "createColumn" methods in the created View to build what you want. You can't do EVERYTHING with those methods, but it may be enough.
One problem you'd likely run into is ACL access: you'll need Designer rights to the database, which a normal user most likely wouldn't have. If you use the sessionAsSigner object to fetch a signer version of the DB (say, "var signerDB = sessionAsSigner.getDatabase(database.getServer(), database.getFilePath())"), you can work from there. Off the top of my head, I don't remember if you will also have to up the "Maximum Internet access" setting on the last tab of the ACL to Designer as well, but you may.
I am assuming that you are referring to the problem that exists when you choose the documents based on the category. This is something that I find highly annoying and I wish that it was possible to turn this on and off. It makes sense for embedded views, but not for much else.
What I did to solve this was to include the category value in the next column. In this way that text could still be seen, even if it was a flat view.
Alternatively, you could also look into using a repeater control and create your own way of presenting the information. This would be used instead of a (Dynamic)ViewPanel control. You could then present the information any way you wanted as long as it is returned in the viewrow set.
Happy Programming!

How to Enabled a single field for update for a particular role in CRM 2011

What I need
I have a custom Entity with that with multiple fields. Admin Role has "god" access. All other roles except for one have read only. The one non admin role with update access, should only be able to update a single field.
What I believe to be true
I believe I have three main options to implement this requirement:
Enable Update Access to the role for that entity then write Javascript to disable all fields on the form for that role, except for the one that I want that role to be able to edit
Enable Update Access to the role for that entity then create a new form that disables all fields on the form for that role, except for the one that I want that role to be able to edit.
Enable Update Access to the role for that entity then turn on field security for each field, disabling access using the field security, for each field except for the one I want them to edit.
What's the Best Practice?
What options should I choose?
If I go with options 1 or 2, will the user be able to edit the field on the bulk edit form?
From a user perspective, I think it's confusing when a form opens up with things enabled, then they get locked down. Plus someone could possibly get data in there before the fields get locked. I'd say you'd have to combine this with a plugin to prevent changing fields you don't want changed.
I like this option better, although again, the field can be unlocked if someone knows what they're doing, so a plugin to double check would be nice.
This would avoid having to double check in a plugin, but you also have to rely on the admin correctly setting up security for new fields going forward. If that's not a concern, this might be best.
Bulk edit is a global privilege, so they'd have bulk edit for all entities. Also, the bulk edit form does not load scripts, so that knocks out option 1. I'd say if it's just this one field, I might leave the privilege locked down and provide my own Bulk edit button on the grid that would show a custom page that just has that one field on it, then handle the updates though script.
2 is most likely best, or as an alternative put the fields in the header or footer rather than as read-only fields on the form.
This also means the fields won't be available to bulk edit, but other methods such as data import or workflows would let users get round this if they know how and have rights to do such things.
3 Field Security is the most robust and works for all scenarios
Possible option 4: create another entity to contain those fields and apply different security to that entity. If created as a child, show the record in a grid on the form with the values included in the view. If it is a parent then you could use methods such as showing the values via an HTML webresource page included on the form.

SharePoint 2010 - Customizing the rendering and behavior of a List field

In my SharePoint List, I have an "Employee" column that is a User type field. I would like to add some custom Business Logic to the processing of this field.
Currently, when the user adds a row, I check to see if the user is an Employee or a Manager and then change the behavior on this column accordingly. I do this by statically rendering the field in my custom "ListForm Rendering Template", just before my custom ListFieldIterator. I simply use a standard SharePoint FormField (and FormLabel) control. In the markup of the FormField control, I specify the FieldName (Employee) and an event handler for the Load event. In this Load event, I will check to see if the current user is an Employee or Manager (using two different SharePoint groups). If the user is an Employee I set the value of the field to the current user (this part works perfectly). I also want to change the field so it can't be modified. I thought I might be able to just change the ControlMode on the field (in the code of the OnLoad Event Handler) to Display, but for some reason this has no effect. The field still renders with the full, people picker editor. Am I not changing the fields control mode soon enough? Or is this simply not the correct approach? The other logic I want to put in is if the user is a Manager, I would like to allow that user to select the person from a list (SharePoint group) of Employees. It may be easier to just use the people picker and limit the selectable users to that group. (I think I can do this with the SelectionGroup property.) Although, it would be better if I could just provide a dropdownlist of users, which I could possibly do with a hidden dropdownlist that I would show and event handlers that I could use (handle event selectedindexchanged) to pull the value selected and populate the (now hidden) Employee (user) field. Does this approach make sense? Assuming all that will work, the real difficulty I am having is with changing the ControlMode (rendering) on the field (when the user is an employee) to a label or some kind of read only control, which is how that field renders when viewing the row, which is why I think if I can just trick the control into thinking it is in Display mode then it should work perfectly!
I am still learning SharePoint, but I am very proficient in ASP .Net. This is why I would like to keep my customizations in this Custom Rendering Template, using code behind and leverage my existing skill set as much as properly.
Any thoughts, opinions or advice? Does anyone know why I can't get the column to switch the "Control Mode"?
I do not think that I fully understand your scenario. Some code samples could help.
But anyway it sounds like you want some heavy customizations of the user field. In that case you might want to have a look at creating a custom field with all its advantages and disadvantages. Have a look at MSDN: http://msdn.microsoft.com/en-us/library/gg132914.aspx
Another option might be - in case you do not want to re-use this column in many list definitions - that you can get away with your custom rendering template and create a custom create/edit form where you implement the specific edit behaviour for the field (plain ASP.NET with some SharePoint controls). Here is a nice walk-through on how to grab a custom edit form from SharePoint designer: http://community.bamboosolutions.com/blogs/sharepoint-2010/archive/2011/05/12/sharepoint-2010-cookbook-how-to-create-a-customized-list-edit-form-for-development-in-visual-studio-2010.aspx
I hope this helps. Kr., Bernd.

Resources