I have to edit Company Name profile property in SSP. It is not allowing me edit or delete property. I need to change length value from 250 to 50. How can I do that? Can we set through code?
Even if you can't delete the property, you should be able to hide it and create another one with the same display name.
If you have access to Sharepoint database, you can definitely do it directly there (which I do not recommend unless you're completely sure what you are doing).
Check if this property is mapped to an Active Directory property. If it is then go to AD manager and change the propertie's properties there :)
Related
We currently have a number of workflows in our organization that require users to add an item to a list via a form, but then not be able to edit that item unless given special permission to do so.
For example a user submits a leave of absence request and it is routed to their manager. The 1st level manager might approve this request and the workflow continues. While the request is in the managers hands it cannot be modified by the original submitter, however if the manager rejects it or requires revision the original submitter should then be able to edit.
Is this possible? The best strategy we could come up with for this is multiple Lists to handle the different levels of security required for this. Are there better ways of doing this?
SharePoint seems to have a very open concept of security within an SP site and maybe were just trying to fit a square peg in a round hole.
Thanks!
How about Remove permission for that user/for all user using workflow itself?
http://spcycle.blogspot.jp/2012/01/how-to-create-workflow-to-change-item.html
http://shareapointkiran.blogspot.jp/2012/06/addremove-permissions-using-sharepoint.html
And then give it back when manager approves/rejects
I had a similar problem and solved it with a quick and dirty solution.
In our case this quick and dirty solution might be even easier.
You could add a hidden field that has an default value of for example 0.
Then you add a (formating) rule to one of the fields that should be deactived.
The rule should deactivate the field if the value of the hidden field is not 0.
This rule can be copied to every field that should be deactivated too.
Now add a set field action to your workflow that set the value of the hidden field to something else than 0, for example 1.
To make a hidden field you can define formating rule with a condition that is always true.
Now if someone creates a form the workflow will set the value of your hidden field to 1. The rule of the fields that should be deactived will now deactivate the fields.
Hide the field
Deactivate the field rule
In the latest MODx (2.3.1) I'd like to make the 'Container' checkbox (system key isfolder) for a document resource checked by default.
How can this be accomplished?
Thanks.
In modx you can set a default field value in many ways. Possible via a plugin, but you can do it easy through form-customization ( http://rtfm.modx.com/revolution/2.x/administering-your-site/customizing-the-manager/form-customization-sets )
1. Go to Security --> Form Customization.
2. Create new profile and go edit him.
3. Inside profile create new "Set Rules" on "create resource" action,
live template blank if you do not have to limit on it.
4. Edit new set of rules and set inside property "isfolder" to 1.
5. Save and check how it works.
Within the system "you can't", what you will have to do is create a plugin that fires on one of the document save events, it's going to be a little complicated to implement but there is a discussion and some code examples here for you to follow.
http://forums.modx.com/thread/81774/automatically-tick-container-box-when-subpage
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 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 am having problems hiding an action button in a view. We recently upgraded to 8.5 and the method I used to use no longer works. I used to be able to create a role in the acl. Then add this formula to the action button properties "Hide action if formula is true". This is the formula #IsNotMember("[StatusUpdate]";#UserRoles)
Thank you in advance for your assistance.
That is the correct formula. #UserRoles returns a list of strings containing the roles for the current user surrounded by brackets, as in "[Admin]":"[Manager]":"[User]"
It "smells" like a bug, but perhaps there is a workaround.
I would create a simple form with a computed field to show the user's roles, and make sure they are set correctly and calculating correctly.
If so, then create a new role in the ACL, say TestRole, and set yourself to that role. Create an entirely new button on the form and set the hide/when formula to #IsMember("[TestRole]"; #UserRoles); Make sure the button does not appear for you.
If all this works fine then perhaps there's some minor corruption in the database within the roles or design elements themselves, and recreating them from scratch might clear that up. Try deleting the role, and the button, and creating them again. (I realize this is a little far-fetched, but it wouldn't be the first time I fixed a odd problem in Lotus Notes this way.)
I would also delete the icon from the Notes workspace (assuming that still exists in 8.5?) and compact the workspace as well. I know in Notes 6 that cleared a lot of the locally cached design elements that were often the cause of strange behavior.