DataSourceField.canEdit stripped in js

[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-05-19/Enterprise Deployment (built 2024-05-19)

Hello, I just noticed that if I have a dataSource field with canEdit="false" and updateRequires="false", the canEdit is stripped from the js translation. If updateRequires is true or not present, it isn't stripped.
I can't actually reproduce it in the showcase.
I load the ds with the loadDS tag.

I tried decompiling, but I'm not sure what's happening. I see that in the JSTranslater.toJS method the attribute seems already missing.

Please let me know if I can do something to help debug this issue.

[Isomorphic]

Assuming it's reproducible, what is likely happening is that since updateRequires is set, implying a dynamic check for editability, canEdit="false" needs to be removed or else the ability to edit will never be offered.

Why are you setting both?

[claudiobosticco]

Hello, I need to check but I think it's simply because it must not be updatable, but updateRequires hasn't an effect on the UI.
Instead canEdit is overridable client side. Using 13.0 builds it isn't removed.

[Isomorphic]

OK, as far as the server, if updateRequires were set to a dynamic expression, then the field is sometimes updatable, so sending canEdit="false" to the client would be wrong, since that would unconditionally disable all editing UI.

Not sure what is meant by "canEdit" is updateable client-side. You're not allowed to change a DataSource definition after it's been created, but perhaps you're just sending the definition and changing it before DataSource creation, or re-creating the DataSource - something like that.

[claudiobosticco]

OK, as far as the server, if updateRequires were set to a dynamic expression, then the field is sometimes updatable, so sending canEdit="false" to the client would be wrong, since that would unconditionally disable all editing UI.

ok, maybe canSave is a better fit for my use case.

Not sure what is meant by "canEdit" is updateable client-side. You're not allowed to change a DataSource definition after it's been created, but perhaps you're just sending the definition and changing it before DataSource creation, or re-creating the DataSource - something like that.

I mean that canEdit could be overridden in a client side databound component.

[Isomorphic]

Ah, overriding canEdit in a client-side DataBoundComponent makes sense, but just note, if that field is truly canEdit="false" and updateRequires="false", and DataSource operation is going to fail on the server-side because that's what those Declarative Security properties do. So to perform a save, you would need to circumvent that somehow - originating a request on the server, for example (not subject to client-side constraints).

[claudiobosticco]

of course, but if the updateRequires was a velocity expression instead of a fixed value, the canEdit could have different sensible values for different users for instance.

Anyway, could you confirm that the behaviour I'm seeing in 13.1 is the (new) correct behaviour? I'll have to check for other occurrences.

I think it's correct to say that the right thing to do is to switch to a canSave="false" instead of the canEdit="false" AND updateRequires="false", right?

[claudiobosticco]

Hello Isomorphic
but in any case there is something wrong: with updateRequires="false", I just noticed that the title defined on the dataSource field is also removed, replaced with the default calculated from the field name.

[Isomorphic]

Ok, that cannot be explained by updateRequires effectively disabling canEdit:false..

You mentioned trying to reproduce this in the showcase and it didn’t work? Can you share any more information on that reproduction attempt and what’s happening in your actual app?

Is it possible the field is omitted entirely - as in have you looked at the generated JS definition?

Normally a field would be omitted entirely if there were a viewRequires declaration that returned false.

[claudiobosticco]

Hi, fortunately, to do some tests to give you more details, I downloaded the May 26th build, and I'm happy to say that the issue no longer occurs.
Previously, it was enough to add updateRequires=false on a random field to see various attributes (title, length, ...) removed in my app, which I verified through the view source on the page.