In one of my xpages applications the following bug
was reported to me by a customer.
It is very confusing, because this issue should be fixed years ago:
In Notes/Domino releases prior to 6.0, the error "Entry is no longer
in view: " would occur when accessing a property or method
of the NotesViewEntry class. This occurred in cases where the entry
was derived from a NotesViewEntryCollection based on the
GetAllEntriesByKey method (of the NotesView class), and when the
relative view had a column where the following property was
enabled"Show multiple values as separate entries" (found in the Column
Properties dialog box --> Sort Panel [second from left]). This issue
was resolved in Notes/Domino release 6.0 by a fix based on SPR#
CSMH483KAX.
http://www-01.ibm.com/support/docview.wss?uid=swg21264910
Thanks for any advice
I got the same error "Entry is no longer in view:" in a java agent when running on server.
Each time, the error fired on the same document.
I didn't get this error if I run agent from my notes client.
I solve this problem by replacing ViewEntryCollection by ViewNavigator.
Related
As title. I am working on a Vaadin 14 application (final stages of upgrading from Vaadin 7).
One of the aspects I am currently looking at is updating some existing fields on a screen to control whether or not to enforce mandatory (asRequired) checks.
ie: if field A is populated, field B is mandatory, otherwise not mandatory. That kind of thing.
Looking at the API, it appears I should be able to do this.
https://vaadin.com/api/platform/14.5.1/com/vaadin/flow/data/binder/Binder.Binding.html
void setAsRequiredEnabled(boolean asRequiredEnabled)
Enable or disable asRequired validator. The validator is enabled by default.
The problem is, I cannot seem to find where I can get access to this function.
We are currently using Vaadin version 14.5.1.
The Binder and the Binding Builder both do not show this function.
I would appreciate any guidance. I just cannot seem to locate how to access this function, to control dynamic adjustments to the required validator.
As always, right after I posted the query, it took me slightly longer in experimenting with the Flow API to find the solution.
For anyone else trying to find this -
I found you get the Binding object from the Binder you are using as follows, which then can tweak this setting:
Binding binding = (Binding) binder.getBinding("property").get();
binding.setAsRequiredEnabled(true);
For some unknown reason, during the checkout flow a global message error appears saying Item no longer valid (was removed) - Object no longer valid
when we check its the item is a cart entry which is no longer valid
we found a similar issue raised in git hub. Below is the GitHub issue link,
https://github.com/SAP/spartacus/issues/5596
We wanted to know if any solution was discovered for this issue
We have below versions,
Hybris - 1905.7
Spartacus - 1.4.4
This is a known case with multi-dimensional products.
Generic variant product is dependent upon the Product as a partOf attribute. But in some scenarios when the GenericVariant product instance is modified without modifying the base product then sync deems that genericvariant instance as an orphaned one that should not be related to the product so it deletes the variant and recreates one.
Now in the checkout, the PK of the entry changes as the sync has created a new Online variant due to the above reason. Since the cart contains the entry of the earlier variant with another PK which could not be found, the error of "Object No Longer Valid" is thrown.
This is not traceable as the same product is available in the cart entry (but with a different PK)
The below approach of modifying the sync description through Backoffice-> System -> Multithreaded Synchronization should help to resolve this.
In the below screen, I have disabled sync of Product Variants [Variants] (The selected node). By default, it is ticked.
CX Jira References:
https://cxjira.sap.com/browse/ECP-3394
https://cxjira.sap.com/browse/ECP-5494
I believe this is also related or very similar to the backend, which throws the error type 'JaloObjectNoLongerValidError'
For Spartacus release 5.0, which should be coming somewhere in March 2022, we have fixed this issue by creating a backoff mechanism, which retries the request when the error is thrown.
An example of it's usage can be found in here.
Moreover, you can see the mechanism in action from this end to end test.
I use the framework to create an Overdue Charge. In previous 5.20 version, there is no issue. I upgraded the site to 6.0. Now an error occurs:
Error #115: An error occurred during processing of the field IsRUTROTDeductible : Index was outside the bounds of the array..
I create the ARInvoiceEntry graph. Next the ARInvoice DAC, and populate the header fields. Finally I call graph.Document.Insert(overduecharge). Transactions are inserted later.
I do have some user fields in an extension table 'ARRegisterExtension'. But that table uses the default InnerJoin, with the matching records from ARRegister included in the table
Please advise if an extra step must happen with RUTROTDeductible. I'm not familiar with this entity.
Try to search for RUTROT in your code.
These fields were moved to an extension in 6.0, so these fields will not be available in ARInvoice DAC any more.
If you are setting these fields anywhere, please remove this code.
These fields are for Sweden users only, so, I don't think you need to set it.
I have a Notes Form (Personnel) that contains a Notes Subform (that I call DocInfo) which has computed fields for storing original author and created date.
Created field formula
#If(#IsAvailable(CreatedOrig); CreatedOrig; #Text(#Created) + " by " + #Text(#Author))
Author field formula
#UserName
I have an XPage with a document source of "Personnel" and computeWithForm set to both. On a Domino 8.5.3 server the XPage computes and saves the Created and Author field on the back end Note. However, on a Domino 9.0.1 server the XPage does not compute the fields and the fields don't appear in the Document Properties of the back end Note.
<xp:dominoDocument
var="document1"
formName="Personnel"
computeWithForm="both">
<xp:this.parentId>
<![CDATA[#{javascript:sessionScope.get("PID")}]]>
</xp:this.parentId>
</xp:dominoDocument>
I am guessing that somehow the Domino 9.0.1 server engine does not include the subform fields in the computeWithForm function? This has worked on our 8.5.3 servers for a couple years, but does not work now on a 9.0.1 server?
Any help, suggestions or information would be welcome.
I can't tell what the exact problem in your case, but I have experienced some weird problems before, with computed fields and computeWithForm on XPages. There is no problem with subforms, at least on 9.0.1FP2. But there has been a couple of changes on the behaviour from 8.5 to 9.0.
On one case, I have found that field type mismatches result in some unexpected problems (Blogged here: http://lotusnotus.com/lotusnotus_en.nsf/dx/more-xpages-error-fun....htm)
I suggest checking the types of those fields. For instance if you set a field as Date/Time but provide a String value, computeWithForm will not throw an error, instead the field will be empty. It's the same for formula errors.
To find the root cause, remove those fields one by one on a separate XPage-Form-Subform setting.
I have some javascript code attached to the accounts entity. This code sets the requirement level of the primary contact attribute based on the value of a custom option set field showing various account types. This was developed on one server, where it worked, and so the solution was imported into another organisation where it now doesnt work.
It seems to be only on this field as i have changed the code to look at another field and that works fine. The error it gives is that the "Object doesn't support this property or method". Also what is strange is that the field doesn't appear in the list under the entity within the solution despite it being a system field.
The code i'm using is:
Xrm.Page.getAttribute("primarycontactid").setRequiredLevel("required");
Can anyone help me figure out what it's doing?
Thanks
EDIT: Found that the code is actually making the field required despite the error, but it's not displaying the * next to it. Also if I make the field required in it's settings then it does the same thing