I am setting up an Inquiry list. There will be two groups of users: Requestors and Administrators. The Requestors will fill in a form with basic information and their question. The Administrators will respond to the inquiry and have additional status fields to fill in; these fields should not be visible to Requestors (essentially, two different forms). What do I need to do to allow the Requestor to see one form, while the Administrators see a different form (containing all of the fields from the Requestor form as well as Administrator-only fields) when they edit the request? I'd like to do this without having both forms show up on the "New" button.
Also note that I am prohibited from using anything other than Sharepoint's "out-of-the-box" functionality.
Thanks!
Ralph
Try Forms Designer tool. It allows to personalize forms based on the current user membership, permissions and field values.
I would keep the same form myself, but get the Administrators fields to not display.
Boost Solutions may be what you are after.
Related
Is it possible to validate the Xpage's ACL depending on the Source document's field value.
We need to make the Authors & Readers ability at XPage level (as per requirement I am not supposed to use the ROLES, since, it is dependent on each individual Authors which is stored in backend document FIELD).
Kindly suggest the approach, as I am not even looking HideWhen for the Buttons(edit,save etc)
Example code in the ACLEntry[0] in Xpage:
if getComponent("inputText1").getValue() == sessionScope.user {
session.getEffectiveUserName();
} else {
return false;
}
Thanks.
I do not quite understand your code on that property...
To query the readers/authors level at XPage level I suggest to use the database.queryAccess method (http://www-10.lotus.com/ldd/ddwiki.nsf/dx/NotesDatabase_sample_JavaScript_code_for_XPages?opendocument&comments#queryAccess)
You try to compare the username only. This may fail if your access level is computed by a membership in a group where your username is not relevant.
XPages' ACL depends on the database ACL, so you have to setup the levels there - the XPages' ACL is in addition to the "real" ACL as far as I experienced.
I also experienced that readers fields affect the ability to use an XPage to open a document by default.
I hope my answer is not too confusing ;-)
I think the question is valid (to my current knowledge):
If I want to design a workflow application but the current approver should not edit the full document I want to give him only access to parts (ie. a comment field and the approval button).
The question above relateds somehow to access controlled sections in old LN development. I so far also didn't find a good solution
What you describe is a very common workflow scenario. There are several ways how you can implement that efficiently. Here is what I would do:
Have one (or more) custom controls that render the "payload" (the fields the requester fills in)
assemble them into one bigger control that is used to render the form
compute the mode to read/edit depending on who is opening the form and the mode (new, pending approval, approved, rejected etc.)
Optional: when submitted remove submitter from the author field
Have one "Approval Control" that show only when the current user is the (current) approver and status is "pending approval" That control has fields that are NOT bound to the document, but a scope variable
The approval button triggers SSJS that takes the scope variable values and updates the document (and triggers notifications, access change etc)
The approval component can be used for any approval form. You then can contemplate not to give the approver write access since you could handle that in code.
I need to display account notes across all opportunities. typically a MSCRM creates a blank Notes section for each new Opportunity you create inside a account, but I need to display a running Account dialog of conversations to review in one continues notepad (means display all notes).
Can anyone tell me how I can display all notes in the opportunity form?
Is this possible without coding (or in fact, with coding!)
Thanks in advance,
SD
Well you can do this a few different ways.
1) The easiest way is to add an IFRAME and then point to the applicable Account notes container. You'd have to set the "id" attribute based on the account. Here's what your IFRAME url will look like:
/_controls/notes/notesdata.aspx?EnableInlineEdit=true&EnableInsert=true&id=%7bEF88BCAA-C3EB-E111-B142-78E7D162EE67%7d&ParentEntity=1
2) If you are only wanting to display the notes and not allow for a user to edit them (read-only), then you'll need to use fetch to query the annotations where the related id equals the account.
Just to be clear the on requirement here.
I believe you are saying: Each Account has multiple Opportunities, each Opportunity has many Notes. On the Account you want to show all the Notes for all the Opportunities.
I don't think you can achieve this with out of the box functionaility, I would suggest creating an SSRS report and iFrame'ing it in.
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.
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.
We'd like to create something within SharePoint that would allow to ensure a set of forms is completed for each employee (i.e., Tax forms, non-compete, etc.). HR staff would have access to a page listing employees and upon selecting a specific employee, they would be shown a list of these completed forms which could be opened to view the document.
Is this scenario something that can be done fairly easy with out of the box features? Or would a custom workflow, web part, or something else be the best bet?
The easiest way to do it out of the box would be to use a single Document Library (or possibly Forms Library) that has multiple document/form templates in it. Then create a View that groups by Created By. HR could then expand on an Employee and see what has been filled out.
To limit an Employee from seeing the forms of another Employee, set the View and Edit options to Only Their Own. Make sure that HR has a higher level of permissions for the list and/or site in order to see all Employees.
If you don't have complex workflows - my advice will be to populate SharePoint List using InfoPath Forms (this article will be a good start).
In other case solution heavily depends on your business requirements and may vary from simple SP List to custom workflows with infopath forms and custom webparts.