I have a view on a Xpage called Main.xsp which needs to open documents in read mode on a different xpage called Contact.xsp. I get the documents to open as they should, since it's very simple and basic. But somehow the SetDocumentMode doesn't work!?
I have a button, when clicked it should set the document mode to Edit. I've tried using the simple actions from the menu, i've tried all of the examples here http://xpageswiki.com/web/youatnotes/wiki-xpages.nsf/dx/Work_with_documents_and_fields_on_the_XPage#Check+for+edit+mode+and+set+edit+mode
What the hell am i doing wrong here? Thank you in advance!
Also, even though the url is docID&action=editDocument the document is not editable.
EDIT
This is weird... I was triple-checking my ACL. And tried changing Anonymous access to Editor, and now it works!? I switch it back to Author with all the available options checked and it doesn't work!?
Is this some kind of bug?
Author rights for Anonymous does give Anonymous the ability to create a document (if that box is ticked) - but NOT the ability to EDIT any document. UNLESS you have a field of type Author that has "Anonymous" as one value (or a role that you assigned to Anonymous".
The definition of AUTHOR access:
Can create documents (if "create documents" is checked)
can edit any document where an AUTHOR field contains the user's name, a group or role (s)he is member of.
Explanation here: http://www.wissel.net/blog/d6plinks/SHWL-89PMVR
(and basics before here: http://www.wissel.net/blog/d6plinks/SHWL-89N7XR )
Related
A user is not able to edit a form. The user had editor access and i've tried to replicate the issue using a test user and providing the same access as the user, but to no avail. I came across a link which told me that there is something called as additional ACL control in Lotus Administrator. I'm not sure if this actually can influence the editing privileges. I don't think that could be the problem. Anyway, please let me know if you can figure out the problem.
Additional info:
The user is a part of a distribution list(multipurpose group) and the group has editor access.
The default access to the form is Author, with a authors field in the form.
The user has 2 names mentioned in the names.nsf person document. An old name and a new name.
The required user roles are assigned to the group.
Let me know if you need additional info.
With Editor rights she should be able to edit. Please check her rights by placing a Computed Text with #UserAccess on the form.
Or if she is using a Notes client she can simply click the "Security" icon in the bottom toolbar of the Notes, near the right corner. It will open a dialog box telling what is her access level to the database.
A few things to check:
is the user listed explicitly in the ACL? If so, those rights will take precedence over any groups she's in.
check the authors field carefully. Best option is to look at the properties of the doc she's editing via the Notes client and examine the authors field in the dialog. That will let you see if any code altered the list of allowed authors. If she's an editor this shouldn't matter but based on the behavior you are seeing it sounds like she's acting as an author.
Make sure that the names in the authors fields are being stored in the canonical format and are not abbreviated or in common name. EG: using Herny Newberry/MyOrg does not work while using CN=Henry Newberry/O=MyOrg does.
The issue is solved. There was some problem with the user configuration. Thats the reason she was getting author access even though she was an editor. After reconfiguration of her Notes client, she'd able to edit the form now. Thanks to all of you for your help.
Although already answered and a solution found, it should be noted that user-names listed in the 'fullname' field of the NAB person record should list the current or 'newname' first as other names may not be recognized.
I've been a Notes developer for years but never used an Access Control Section on a Form.
I want to give (web) users (with the right [role]) access to edit only one field on a document. I'm assuming an Access Control Sections is the way to go.
A couple of things aren't obvious:
As well as adding the [role] name to the Access section's formula does it also have to exist in an Authors field on the document?
If #1 is true, then do all other fields have to also be in an Access Control Section where that role can not edit them?
Jake
The access control section controls access to what ever is in the section. It does not need an authors field.. Only the content or fields that you want to control access to are included. Authors fields define who can edit a document. Regardless of what level of access a user has, if there is an authors field and the role is not listed, that user will not be able to edit the document.
You can use an authors field to limit the editors to certain documents, from there you can further restrict access to fields to edit by sections. If you do have an authors field in conjunction with a section, the role needs to be in the authors field as well as the section access formula in order to be able to edit
In Lotus Notes Access is ALWAYS calculated top -> down.
If you don't have Author- Access to the document itself (defined by an Author- field or because you are Editor or higher) then a Section- Author- Role will not help you.
The answer is: Yes, you need an editor- field containing the role.
In consequence the answer to your second question is also: YES, you need to protect the other fields with a section (without the role) as well, if you really want to restrict access to that single section.
I am new to CRM, and I have run into a requirement where I have to show some controls (textbox, option set, etc) and custom entities (sub - grid) as readonly. But, when I made them readonly, they appears like disabled and are getting grayed out. Is there any way to make them only read only not look like disabled?
Please suggest.
Thanks,
Ashfaq.
in CRM read-only means fields are greyed out but still they are readable.
If you want to make the fields visible as normal but don't want them to be editable by the user, you need to write JavaScipt for that.
Take the following steps.
1. Make the fields editable.
2. On form's OnSave Event, call the following method to prevent the attributes to be saved.
function PreventSave()
{
Xrm.Page.getAttribute(“CRMFieldName”).setSubmitMode(“never”);
}
It will not grey out the fields and still prevent the user to change their values.
I hope it will help you.
For text fields, there is one type of text field that when set to readonly does not look like it is disabled. Off the top of my head I can't remember which type. For the other field types I have not found a way to not have them look disabled when made readonly.
Other option is not to use form fields but show the data you need to be readonly (and not grayed out) in a web resource (HTML/SL/etc). Be aware tho that if your users are using outlook with crm addin, there are limitations here when the record is viewed in the outlook reading pane.
Only other option I can think of is to not set the fields as readonly but control any field data changes with javascript.
In short, I haven't found a good way to do what you need.
I have a legacy Lotus Notes application that starts to randomly lock a document even though no one is opening the document. So when someone tries to edit a document, Notes will say that 'the document is locked by user1/Domain' but when I check with user1, the person does not have that document open and the admin or the user1 has to manually right click the document and select 'Unlock document'.
What would some suggestions to try to find out the cause of this problem?
If users aren't manually locking the documents, then there must be some code that is doing it on their behalf. Look through the code for places where the NotesDocument.Lock() method is being used or the formula #DocLock
I would use the Design Synopsis feature to generate a report of all the forms, script libraries, and agents, and then do a text search for those methods/formulas. That may help narrow down where the lock is occurring.
Or, if you wish to turn off document locking completely:
Choose File - Application - Properties and click the Basics tab.
Deselect "Allow document locking."
I have created a Custom Edit Form for a custom list using SharePoint designer. I need to check that the current user is the author of the list item before displaying the form as only the author should be able to edit this content. I don't have server access so want to do this in the form itself using XSL. So far, I haven't been able to retrieve the Author / Created By value. Does anyone know how to get at this value?
Thanks for your help
Iain
Update:
I can see now that the Edit Form is using a datasource which basically returns a view containing all fields in the content type. "Author" is not part of the content type (which is a custom one). I can't see any way of adding the Author to the content type. Does anyone know how this can be achieved as i think this would solve the problem.
Cheers,
Iain
Isnt it possible to use the View/Edit access settings for the list? You find them under "List settings -> Advanced Settings" or somthing like that.
To bar someone form editing an item he should not, I would not edit the edit form of the item but do this by the item's permissions set. Therefore I would add an event handler to the list which changes the list items permissions after its creation, so that only the creator of the document has the permission to edit it.
Informations about event receivers can be found on Brian Wilson's blog.
I think JMD is right. You can do this without a custom form or any coding. From the list's menu bar select Settings -> List Settings -> Advanced Settings
Once there, you should see an option in Item Level Permissions to restrict edit access to only the item's author.