grid with editRequires="false" on fields and requires="false" on remove op. Binding

[claudiobosticco]

SmartClient Version: v10.1p_2016-03-14/Enterprise Deployment (built 2016-03-14)

Chrome on OSX

Hello, I've got a simple grid with canRemoveRecords: true, which is dataBound with a dataSource.
The dataSource has editRequiresRole on all fields, and requiresRole on remove operationBinding.
The problem is when the user has a role which results in all fields non editable and also the remove operation is forbidden.
If I call grid.startEditingNew, no new record is created, which is nice.
But if, after the startEditingNew I try to remove a record, after the 'Failed the "requires" check' warn appears, a void record is added to the grid
You may see the effect here:
https://www.youtube.com/watch?v=vggU-STI0Ps

Also, if you hover the first record, its layout becomes 'broken', seems shifted to the right-bottom.

[Isomorphic]

What we really need is a way to reproduce the issue, or at the least, some idea of the settings - for example is this grid autoSaveEdits:false or not?

Also, if the current user is not allowed to remove records at all, why are you leaving the removal interface showing? Hiding it seems an obvious way to solve the issue..

[claudiobosticco]

Hello, the test case is:

isc.ListGrid.create({
  ID:"testGrid", 
  dataSource:"JTK_PAGAMENTI_TEST", 
  canRemoveRecords:true, 
  top:40,  width:500, height:500, 
  autoFetchData:true
})

isc.IButton.create({
  ID:"newButton", 
  title:"New Record", 
  click:function() {testGrid.startEditingNew({})}
})

the JTK_PAGAMENTI_TEST dataSource:

<DataSource
            schema="DBSALES"
            dbName="dbJpcEP"
            tableName="JTK_PAGAMENTI"
            ID="JTK_PAGAMENTI_TEST"
            serverType="sql"
>
    <fields>
        <field sqlType="decimal" primaryKey="true" name="ID_REC" type="sequence" hidden="true" sequenceName="SEQUENCE_ID_JTK"/>
        <field sqlType="varchar" sqlLength="200" name="TITOLARE" length="200" type="text" required="true" editRequires="false"></field>
        <field sqlType="date" name="SCADENZA" type="date" required="true" format="MM/yyyy" editRequires="false"></field>
        <field sqlType="varchar" sqlLength="50" name="TIPO" length="50" type="text" required="true" editRequires="false">
            <valueMap>
                <value>VISA</value>
                <value>MASTERCARD</value>
            </valueMap>
        </field>
    </fields>
    <operationBindings>
        <operationBinding operationType="remove" requires="false"/>
    </operationBindings>
</DataSource>

It seems the error shows when startEditingNew is called with default values or at least an empty object.

[claudiobosticco]

Also, if the current user is not allowed to remove records at all, why are you leaving the removal interface showing? Hiding it seems an obvious way to solve the issue..

yes, but consider that I'm trying to leverage the declarative security which is very handy because a simple declaration like

<operationBinding operationType="remove" requires="arbitrary velocity expression"/>

has effect on every client component, but spreading the same logic on all client components is less attractive (maintainability, testability...).

ie. if a user which has rights to remove records doesn't get the removal interface due to a bug, that is worse than having the removal interface even if he doesn't have the rights.

editRequiresRole on a field has also effect on client components, which is *very* nice, but I understand that for a requires/requiresRole on an operation binding is much more difficult if not impossible to have effect on client components.

Also consider that in general, using velocity, those 'requires' (or a DMI method) could contain more complicated logic: at the extreme, a record could be removable when loaded in the UI but not removable after some time, because of a change made by someone else.

[Isomorphic]

This has been fixed for builds dated March 25 - startEditingNew() was creating a new editSession that wasn't being cleared up properly.

Let us know if you still see anything that looks wrong.

[claudiobosticco]

SmartClient Version: v10.1p_2016-03-25/Enterprise Deployment (built 2016-03-25)

Thanks, the problem of the void record is gone.

It remains only this visual glitch:

Also, if you hover the first record, its layout becomes 'broken', seems shifted to the right-bottom.

Btw, I noticed that the error raised when an operation fails the role check is generic (-1). Wouldn't make sense to have a specific statusCode for the RPCResponse?

[Isomorphic]

The visual glitch been fixed also, for builds dated March 30 and later.

[Isomorphic]

FYI new RPCResponse status was added to reflect security failures, see declarativeSecurity overview in Smartclient reference for details.

[claudiobosticco]

nice addition, thank you very much.