The PhoneFactor country code dropdown has the USA on top.
The list is:
StringId="countryList">{"DEFAULT":"Country/Region","AF":"Afghanistan ...
It looks as if "DEFAULT" is set to the USA somewhere but I don't see any references to this.
I want the default to be e.g. "NZ".
I can do this by reordering the elements but it would be much simpler if I could simply change the default.
Is there a mapping somewhere for this?
I've had this issue before, the way I worked around it was to make sure that the default I wanted was the first one on the list. So in your case
StringId="countryList">{"NZ":"New Zealand","AF":"Afghanistan ...
Related
I am trying to create a list item with a multiselect field, according to the m365 spo documentation. It feels like I have tried all possible variations, but I cannot get it to work at all.
Is there any official guide as to the syntax for a multi-select value?
Ok, for whomever bangs their heads against this in the future, the format for the seeds of a multi-lookup field is the following:
Id;Value;#
Where ;# is the separator. You may use # as a wildcard for a value, ending up with the following example where I am adding the related entities with Id 3 and 5 to the seed:
3;#;#5;#
or one single entity:
1;#
or three entities:
2;#;#3;#;#5;#
There seems to be a tiny bit of tolerance on the trailing value, but I did not experiment much with this.
PS: it works, and I am very happy, but dear reader know this: if you feel the need for some eye-bleach after reading this, you are not alone!
Where does the code that makes a PX Formula work exist? I at first assumed it was a SQL Trigger, but I can't seem to find it there. This is why I ask....
I've added a custom field to the SO, called usrSpeedyTotalExt2. I'm trying to get that to sum the SOLine.CuryLineAmt. I added attributes to the SOLine DAC to append the follwing:
[PXFormula(null, typeof(SumCalc<SOOrderExt.usrSpeedyTotalExt2>))]
This seemed to work, but know I'm fining that the value is consistently twice as high as it should be. I've got a second field that's doing the exact same thing.
What's increasingly odd is that I had the same problem with the field, and I thought I had done something wrong so I deleted the PXFormula, created a new field and then added the PX Formula to populate the new field. As such, there shouldn't be any code populating the old field, but strangely it's populated, so there must b e some business logic that's stuck and somehow still populating it.
Any thoughts on how I track this down?
I believe that I figured out the problem...I think that the code may have been imported and published on more than one company, then published from the proper company to multiple tenants.
My fix was to go to the live company, un-publish all, then go back to the company the customizations live in and publish to the appropriate tenants. It would appear that now I'm only getting the proper totals. IDK how that might have happened, but at least it appears to be fixed.
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
If I create a new Account Advanced find view I am finding some very odd behaviour.
I follow these steps:
Create new view for Account
Go to Criteria
Criteria has been prepopulated as below
Which is odd on its own - why prepopulate?
Anyway, if I then add something, say Status = Active , it duplicates the first criteria as below:
Other than 'your server is FUBAR'd' - anyone have any ideas what could be causing it?
edit: if I export, the XML does not show the duplicated filters as below shows:
Reply received from Microsoft. A colleague has verified this and found it fixed the issue in our case.
A filter had been applied to the default view for Account (I must admit I wasn't aware of this!).
When you click to create a new view, part of the code executed retrieves the current default view and uses that as a template.
Removing all filters on the default view therefore solve this issue.
I'm not quite sure why it should have had the affect it did when adding new criteria, but I think I'll choose not to think about that!
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.