For customization shown below, when editing the line item, validity is never triggered and its error message is not shown. I can even back out from the line item to editing of requisition header by pressing OK button (and thus saving changes) what should be blocked.
<inClass name="ariba.purchasing.core.ReqLineItem">
<inField name="SupplierPartNumber">
<validity combine="and">
<context enclosingDocument="ariba.purchasing.core.Requisition"/>
<condition expression="false">
<parameter name="Message" value="Temporarily, this validity is always NOT valid."/>
</condition>
</validity>
</inField>
</inClass>
However, the expected error message is shown on header level, when I press Submit button or Show Approval Flow button.
How can I make validity to work normally on the line item?
Set validity condition at value source instead.
ReqLineItem.SupplierPartNumber is actually an alias for LineItemDescription.SupplierPartNumber. Although its visibility and editability conditions can be controlled separately, its validity condition is transferred from the originating field. This is logical, because when the content is shared via alias, it still has to keep the same validity rules.
The answer:
implement validity condition at originating field LineItemDescription.SupplierPartNumber, it also applies to its aliases
do not use validity condition at aliased ReqLineItem.SupplierPartNumber. The usage is technically possible without getting an error but it actually leads to somewhat unexpected behavior described above.
Related
The event raised by clicking on a phone number will either be of the form "tel:" or "skype:". Here are the steps I've followed so far to enable a window navigation rule to capture the event, and I've attached events to the rule to actually see the action get fired in the Debugger. Still, even with navigation rules set to capture tel: and skype:, the action will never fire in USD Debugger. Here is the general approach I've used so far (From another post):
Create a Windownavigation rule.
Don't put anything into the entity Settings but put "tel:" or "skype:" into the URL TextBox.
Routetype will be Popup
Target will be Tab (or registercard, at least I think that's the name for it in english - I'm using a german one)
Define None as Action in result for your Windownavigationrule
Create your own Action to resolve when the Navigation rule is triggered
Set your own hosted control (In this case I use the CTIConnector class.)
Define an Actionname for your Action that will be exectued (I named it "MakeCall" in CRM)
Set Data to [[SUBJECTURL]] so the URL ist given to the Action als Parameter.
Override the method DoAction from your hosted control
Just 2 -3 points to verify.
Do you have a UII action with the name "MakeCall"? If that is there then only your code will be triggered from DoAction.
In case, if you have above in place please check whether your action calls and other records are added to the respective configuration reocrd?
I have database that I have multiple orders entered into. Everything seems to be working fine except for a few old entries which will not accept updates/changes to their Fields.
Note: The majority of the Fields are Strings with Possible Values entered via a DropDown Box.
So if I open Order A I can make adjustments just fine and those changes persist even after closing the page and coming back or refreshing.
But if I open Order B, I can make changes via the dropdowns and it looks like they have adjusted, however if I leave the page or refresh all the changes have reverted back.
One piece of info that may be helpful is that each of these orders has at least one Field that contains an entry that is no longer a Possible Value (the original entries were removed/changed per request of the client).
Maybe they are "locked" because of this? Is there a way to look at an error log for a Published app?
I can delete the "corrupt" entries and recreate them (since there are currently only a few), but I would prefer to find a better solution in case this happens again in the future.
Any help would be greatly appreciated.
It's a bug. Such field level value updates should get through.
As workaround you can update prohibited(not possible anymore) values with allowed ones in OnSave Model's Event like:
switch (record.Field) {
case "old_value_1":
record.Field = "new_value_1";
break;
case "old_value_2":
record.Field = "new_value_2";
break;
...
}
Sorry for the inconvenience.
Each deployment has its own log. Have you tried "App Settings > DEPLOYMENTS > (click on the desployment) > VIEW LOGS"?
When using ibpy trying to close some positions placed on TWS manually, it turns our we could not do this. Specifically, when performing:
self._tws.reqAllOpenOrders()
sleep(0.2)
We get the orders with id 0 (probably because i placecd it manually on TWS)
<openOrder orderId=0, contract=<ib.ext.Contract.Contract object at 0x103b78ad0>, order=<ib.ext.Order.Order object at 0x103b78a50>, orderState=<ib.ext.OrderState.OrderState object at 0x103b78b10>>
<orderStatus orderId=0, status=Submitted, filled=0, remaining=100, avgFillPrice=0.0, permId=134994568, parentId=0, lastFillPrice=0.0, clientId=0, whyHeld=None>
<openOrder orderId=0, contract=<ib.ext.Contract.Contract object at 0x103b78c90>, order=<ib.ext.Order.Order object at 0x103b78c50>, orderState=<ib.ext.OrderState.OrderState object at 0x103b78cd0>>
<orderStatus orderId=0, status=Submitted, filled=0, remaining=1, avgFillPrice=0.0, permId=134994562, parentId=0, lastFillPrice=0.0, clientId=0, whyHeld=None>
<openOrderEnd>
When trying to close it with:
self._tws.cancelOrder(0)
or
self._tws.cancelOrder(134994568)
I get the error:
<error id=0, errorCode=135, errorMsg=Can't find order with id =0>
<error id=134994562, errorCode=135, errorMsg=Can't find order with id =134994562>
Any idea how could we close them? Thank you.
You have to 'bind' the orders to the new client. Use this method tws.reqAutoOpenOrders(True). From the docs,
Finally, IBApi.EClient.reqAutoOpenOrders will allow to obtain those
orders manually placed using the TWS itself. This method also allows
the client application to take over these orders and modify them by
setting the autoBind parameter to true. If successfully bound, The
orders will be assigned (i.e. bound to) an API order id and as such be
eligible for modification.
client.reqAutoOpenOrders(true); Important: only those applications connecting with client Id 0 will be able to take over
manually submitted orders
Through the TWS' API settings it is possible to configure this
method's behaviour to some extent. As shown in the image below,
manually placed orders can be given a negative order Id which can
serve to easily tell manual from API submitted orders. The TWS'
tooltip elaborates further:
The callback will look like <openOrder orderId=-3,... and then you just call tws.cancelOrder(-3)
Note that you don't get orders placed previously in TWS, only those placed after the call to reqAutoOpenOrders.
Working on Work Execution app (v 7.5.2). In MAM, Field having datatype as INTEGER (4) but when I enter values "1234567890123456789' in Anywhere, it doesn't throw error instantly but after saving, It throws "Database error number -4461 has occurred when operating on WORKLOG : WorkLog ID=1234. Report the error to the owner of the deployment."
Either User should warn immediately after entered or Need to restrict the MaxLength to enter in TEXTBOX. How to do ?
You can put some validate javascript code on the dataChange event for this field to validate that less than 4 characters were input. You can also open a PMR as this seems like a limitation that we would address in a future release.
I want to customize the standard drill-down functionality and add a text parameter to the drill-down URL. I will then parse and use the parameter in the SysStartUpCmdDrillDown or EventDrillDownPoller class like the solution provided by Jan B. Kjeldsen in this question.
The standard drill-down link is dynamics://Target/?DrillDown_RecID/ :
dynamics://0/?DrillDown_5637230378/
In previous versions of AX it was possible to modify the RecId to custom text and parse the text once the client is started:
dynamics://0/?DrillDown_0MenuItemName=PurchTable&FieldName=PurchId&FieldValue=P000044
Unfortunately, in AX 2012 the RecId is checked before the client is started and if it is not a valid int64, the drill-down event is not sent to the client. Since it is not possible to change the RecId to anything other than an integer, #Alex Kwitny suggested in the comments at that same question that you can add the custom text to the drill-down target like this:
dynamics://0MenuItemName=PurchTable/?DrillDown_5637230378/
The problem I experience with this is that the link now gets confused about which instance to start.
If the target is equal to the value in the System Admin -> system parameters -> Alerts ->Drill-down target, a client with the correct server instance is started. When I append the text with my custom text, it always starts the default instance(Which could be different from the instance I intended to start). While this is not ideal, I could work around this issue.
The bigger problem is that it now always starts a new session of the default instance, even if a client session is already started. As far as I can see I cannot write X++ code to solve this issue since the server instance is determined before any code in the client is executed.
My question is this - How can I add custom text to the drill-down link while preserving the way the client instance is started: If a client for the instance is already open, it should process the link in the open client, and not start up a new client of the default instance.
You should probably come up with another solution as mentioned in this post, but there could still be a way.
The URL has two objects that can be modified:
dynamics://[Drill-down target(str)]/?Drilldown_[Int64]
According to you, if you modify the [Drill-down target], then it launches AX using the default client config, and that is behavior that you don't want. If you have a matching [Drill-down target], it'll launch in the open client window, which is behavior I can't confirm, but I'll take it at face value and assume you're correct.
So that means the only thing you can modify in the URL is [int64]. This is actually a string that is converted to an int64 via str2int64(...), which in turn corresponds to a RecId. This is where it gets interesting.
This work all happens in \Classes\SysStartUpCmdDrillDown\infoRun.
Well, lucky for you the ranges for the objects are:
RecId - 0 to 9223372036854775807
Int64 - -9223372036854775808 to 9223372036854775807
You can call minRecId() and maxRecId() to confirm this.
So this means you have -9223372036854775808 to -1 numbers to work with by calling URLs in this range:
dynamics://0/?DrillDown_-1
to
dynamics://0/?DrillDown_-9223372036854775808
Then you would modify \Classes\SysStartUpCmdDrillDown\infoRun to look for negative numbers, and fork to your custom code.
HOW you decide to user these negative #'s is up to you. You can have the first n-digits be a table id or a look-up value for a custom table. You can't technically use a RecId as part of that negative number because in theory the RecId could get up that high (minus 1).