Is there a way to make a field conditionally mandatory? If in a dropdown a user selects "Other", the next field should be mandatory, optional otherwise.
Thanks!!
Yes you could do that. You can write a client field change function and do something like this.
var field0=context.currentRecord.getText({fieldId: ‘field0'});
if(field0 === ‘Other’) {
context.currentRecord.getField({fieldId: ‘field1'}).isMandatory=true;
} else {
context.currentRecord.getField({fieldId:’field1’}).isMandatory=false
}
You could also make it possible via workflow as well. But for small validations and stuff it would be better if script is used rather than a workflow.
For small validations I find it best house a workflow rather than a script (contrary to the other answer). Most companies have admins and few have developers. Workflows should allow anyone to manage it.
In either case make sure you handle setting it to mandatory AND unsetting it. If a user selects other "accidentally" and then changes their option to something other than "other", the field should most likely no longer be mandatory
Related
I would like to add training phrases like
Yes
I would love to
No
No, thanks
and extract a boolean var $extraCheese containing True or False which I can use later. If I was expecting a color, I would do $dressColor and #sys.color, but then I don't find #sys.boolean
How do I do this?
It is, indeed, baffling that Dialogflow doesn't offer this natively. They offer this as an option for a Followup Intent, if that is suitable for you, but not as a System Entity.
Fortunately, it is fairly easy for you to make a Boolean Entity yourself.
Click on the + sign next to the Entity menu option on the left.
Set the name for the Entity: such as Boolean.
Add the value for an entity (true for example) which is the text value your webhook will be sent. You then also add aliases for that value. This needs to include the value itelf (true, again), but also anything else the user might say to represent this value (yes, sure, etc).
Then repeat this for other values you may want.
When you're done, you can click Save and then use this entity in your sample phrases just like the built-in entities.
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
I'm wondering if anyone knows a way to HIDE certain fields (such as costs) from certain Netsuite roles if they are not permitted to see costs.
I can prevent users changing sell prices without the proper authority with nlapiDisableLineItemField during PostSourcing and validateline etc...
But with cost fields, I'd like to HIDE them if the user does not have COST access. I realize I can do this by creating a separate form that does not include costs, but if I can hide information via the script, it means less duplication of effort down the track with other things I have in mind.
You can use a beforeLoad userevent script to hide body level fields (but, it is not possible to do the same for line item field, as there isn't any API on nlobjform to allow that. For sublist/lineitem fields You will have to write a client script validations or remove the field from the form like you have been already doing as you mentioned in your question).
In you beforeload user event script you get access to form and then use something like below to hide body level fields.
function beforeLoadEntryFunction(type, form)
{
if(nlapiGetRole() === 'NON_ACCESSIBLE_ROLE_ID'){
form.getField(YOUR_BODY_FIELD_ID).setDisplayType('hidden');
}
}
Edit:
For sublist/lineitem fields create a client script with code as
function clientScriptEntryFunction(type, form)
{
if(nlapiGetRole() === 'NON_ACCESSIBLE_ROLE_ID'){
form.getField(YOUR_BODY_FIELD_ID).setDisplayType('hidden');
nlapiDisableLineItemField(SUBLIST_ID, LINE_FIELD_ID);
}
}
And in before load user event use form.setScript(YOUR_CLIENT_SCRIPT_ID) as you already have access to the form object.
Remember, client script should be a global client script
If your purpose is purely aesthetic, you can do a Client side onLoad script and hide the fields via jQuery, you can do a select by name which wouldn't change even on version upgrades.
The jQuery library is included on NetSuite.
I've created my own solution with a custom entity of type activity. I'd like to show a message whenever a new instance of it is created using an existing contact but not allow the user to create one, if only attempting to do that without going via contact.
Basically, my aim is that it won't be impossible to just create that activity (the form will be hidden directly at any attempt except for one way only). The user will have to go to contacts (or leads etc.) and in there add and create an instance of the custom activity entity. That way, I can assure that the field "regarding" will be filled out already.
I'm guessing that I need to detect somehow that the opening of the form is a creation attempt. How can I do that?
Also, as it is now, the user can't create a contact-less activity of the custom type because it doesn't appear on the menu with other activities. I must have disabled it somehow but I have no idea how. Anybody who has one?
You could do this a bunch of ways but the easiest would probably be to:
Make the regarding field read only.
Make the regarding field mandatory.
That way if a user opens a create new form they wont be able to set the regarding and because its mandatory they wont be able to save the record. When they open via an existing contact the regarding field will be mapped automatically. That said in this case just making it mandatory my be enough.
(As a side JavaScript can be used to identify the current form state, but I'm not sure how useful that is here).
In terms of where custom activities appear, by default mine show in a number of locations, for example:
CRM > Workplace > Activities > Ribbon > Other Activities > XXX.
CRM > Workplace > Activities > View Selector > XXX.
They don't show under the left hand navigation of the workplace because they are grouped under 'Activities'. I'm pretty sure these are all the default settings.
You can exercise greater control by editing the sitemap, where you can put pretty much anything, anywhere.
In addition to Mr Wood, I'd like to show you some code. It works as supposed to but I'm not sure if it's optimal.
var foo = function () {
var whatIsGoingOn = Xrm.Page.ui.getFormType();
if (whatIsGoingOn === 1)
alert("Let there be an entity!");
else
alert("Not a creation...");
}
The other states' (deletion, update etc.) numeric values are listed here.
Answering the second part of your question:
When you create a custom activity you can choose whether to have it appear in 'normal' Activity menus or not by checking the box at the top right of the entity form. This is a once-only choice as far as I know and can't be changed later.
For your setup, I would suggest NOT checking this box, so it does not appear in the activity menus to avoid users even being tempted to do it that way.
Instead, add an explicit relationship to the activity N:1 to Contact, and another N:1 to Lead. Use this relationship to add your activity to the left navigation of Contact and Lead forms, or add a grid for them (depends on how you want to use this and if you need to filter the view to something other than the default "Associated View").
When a user navigates to this section they will see if any previous activities of this type exist, and be able to add a new one. BUT this means that the child record is a child via this relationship, not using "regarding", so use a script on the form for the activity so that if Contact is filled in, it is copied to Regarding, and if Lead is filled in then that is copied. If neither, then use an alert or other means to warn the use that something is wrong (see comment earlier). If you want Regarding to be read-only but filled in by script, you will need to make sure to use the force the value to be saved:
Xrm.Page.getAttribute("regardingobjectid").setSubmitMode("always");
You must have the lookups for Contact and Lead on the form to be able to use them in your scripts, but you can make them not "visible by default" so they are there but not seen by the user (and taking up no space).
I'm not a Notes programmer, however, for my sins, have been working on some Notes features for an in-house project recently. I need to enable/disable editing of a field depending on circumstances. It seems to me to be a fairly standard feature, I need, but I can't find any information on how to do this anywhere.
In form setup (and other field's onchange) code, something like the following:
if some requirement = true then
textField.enable = true
else
textField.enable = false
end if
I've seen other places where there's a workaround of conditionally hiding paragraphs based on some code, having 2 paragraphs with opposite hiding conditions, one with an editable field, the other with a computed field. However, I don't know enough about Notes to see how this is implemented (I can see it done on other forms, but there seem to be some 'magic' steps within Notes which I either can't see or don't get).
[EDIT]
The reply from Kerr seems to be what I'm looking for, but I still can't find out where the InputEnabled property is located. Should have said in the initial question, I'm using Notes 7.0.3.
In fairness, it doesn't matter what the circumstances are for when to enable/disable the field, it's just some boolean condition that is set, in my case only on form loading so I don't even have to worry about this changing dynamically while the form is displayed.
I've got a few issues with Notes, my largest bugbear being that it's so tied so tightly to the Designer UI, which is utter shite. I can do this sort of thing programmatically in most GUI languages (C#, Java, Delphi, even VB), but I need to open property boxes in Notes and set them correctly.
This would be OK as an optional method, but forcing you to go this way means you can only work as well as the IDE lets you in this case, and the IDE here seems to actively work against you. You can't open multiple functions/scripts, you can't swap from one script to another without going back to the menus on the left, you can't easily search the codebase for occurrences of variables/fields (and believe me, this is a major failing for me because either Notes or the internal codebase in my case seems to make a lot of use of global variables!), you can only work with fields through the property boxes that get displayed, you can't edit code in Designer while debugging through the main Notes client.
While the Java side of the coding is better than LotusScript, it's still fairly crappy (why can't you debug INTO Java code?? Why do you need to re-import JAR files for each Java class, does each class have a different CLASSPATH???). Possibly this was improved in Notes 8, I hear it's based on Eclipse. Does anyone know whether this is true or not?
It would help to hear more specifics about the 'circumstances', but the most common way to handle this is to use a hide when formula on the field you want to enable/disable.
Technically you are not enabling or disabling the field, just hiding it, but usually that works just as well.
Since there are few events to work with in Notes, developers commonly use the document refresh as the 'event' to cause the field to hide or show.
Let's assume you have two fields called TriggerField and Subject. Say also you want to disable the Subject based on a value in the TriggerField. The easiest way to do so is to set the TriggerField as a Dialog List type and check the "Refresh fields on keyword change" option. This means when the value of the dialog list changes, the entire document will get refreshed.
Then in your hide when formula for the Subject field, you specify your criteria for when to show or hide that field. Anytime field values change, followed by a refresh of the document (i.e. form), that hide when formula will be re-evaluated.
There are other ways, depending on your circumstances, to solve this problem. If you want to let the user refresh the form themselves, put a button on the form that calls the #Command([ViewRefreshFields]) command. You can add any other formulas to that button before the refresh command if you want to make other changes to the form at the same time.
Another option is to make a certain field display-only. Then create a button that runs LotusScript to allow users to change that display-only field. In the script you can propmt the user for a value, set the display-only field, and then call for a document refresh.
In ND7 and up if you want to just disable the field for input, write an appropriate formula in the InputEnabled section of the field you want to disable.
So I have two fields one called Trigger, a checkbox with the value "On" and another Subject that is a text field. When Trigger is checked I want the value Subject to be enabled.
I simply put the following formula in the Input Enabled element of the field Subject:
Trigger = "On"
I also want this to be recalculated whenever the value of Trigger changes so I select the "Refresh fields on keyword change" option on the Trigger field.
If you're stuck in an older version you need to to hide paragraphs appropriately.