Skip to Content
0

Prevent editing of key value in Fiori Elements object page

Mar 12 at 02:47 PM

89

avatar image

Hi,

I have created a CDS view, generated a Business Object for it, exposed it via an OData service using annotations, and created a Fiori Elements List Report application based on this service.

When I run the application, navigate from the List Report to the Object Page and go into Edit mode, the field specified as the key is open for input, even though changes to this field are not saved to the database (as you would expect: you can't change the key value in SM30, you have to copy the original and then delete it).

Is there a UI (or similar) CDS annotation I can use to prevent the key being open for input when editing the Object Page?

Thanks,

Andrew

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Best Answer
Andrew Fordham Mar 27 at 01:12 PM
0

I have found the answer. It is not possible to get this behaviour by using CDS annotations alone, but it can be achieved programmatically in the Business Object that gets generated by the CDS annotations:

https://help.sap.com/viewer/cc0c305d2fab47bd808adcad3ca7ee9d/1709.001/en-US/ff67efc37b154f1e88a2f44d26eb2cf0.html

Share
10 |10000 characters needed characters left characters exceeded
avatar image
Former Member
Mar 13 at 02:46 PM
0

Hello Andrew,

You can use @ObjectModel.readOnly:true.

Regards,

Pratheek

Show 6 Share
10 |10000 characters needed characters left characters exceeded

Hi Pratheek,

That works when I am editing an entry, but it means I cannot create a new entry as there is no way of entering a value in this field.

Is there another annotation that mimics SM30 functionality, so that I can create a new key but not edit an existing one?

Thanks,

Andrew

0
Former Member

Hi Andrew,

Ok now I understand.

What we do in case of an Editable Key is,

We create a casted field from the Key field and call it "ForEdit" like below.

Key PurchaseOrder as PurchaseOrder,

PurchaseOrder as PurchaseOrderForEdit

In the above case, the PurchaseOrderForEdit is a non-key field and can be edited from UI. Now on Save, you have to copy PurchaseOrderForEdit value to PurchaseOrder field and save to the database.

If you have a Draft Based BOPF, you have to then control the editability of the PurchaseOrderForEdit field using annotation @ObjectModel.Readonly. But here the value of the annotation will not be true. Instead we use 'EXTERNAL_CALCULATION'. This would create a ACTION_AND_FIELDCONTROL determination in your BOPF and you can control the editability of the field there by setting it editable when the value is null and is draft and disable it once value is entered.

Finally, Your CDS would be like this

Key PurchaseOrder as PurchaseOrder,

@ObjectModel.readonly: 'EXTERNAL_CALCULATION'

PurchaseOrder as PurchaseOrderForEdit


Hope this helps.

Regards,

Pratheek

0

Hi Pratheek,

Thanks for your answer. I'm afraid I don't have enough experience with transactional CDS/Fiori Elements to know how implement that functionality. Is there any documentation on this approach? I do not have a draft-based BOPF, which will hopefully make it simpler.

I still don't see how this allows you to have an editable field when creating a new entry, but a read-only field when editing an entry, given you can't identify which mode the UI is in when adding the @UI.Identification.position annotations.

Looking at the code in methods CL_SADL_ENTITY_CDS->IF_SADL_ENTITY~GET_ELEMENT_CONTROL and CL_SADL_GW_MODEL_EXPOSURE->_ADD_ENTITY_PROPERTY, would it not be easier to introduce an annotation so that the sap:creatable and sap:updatable OData annotations can be set to different values by CDS annotations?

Thanks for your help so far,

Andrew

0
Former Member

Hi Andrew,

The idea is to prevent exposure of Key field in Fiori Elements by using "@UI.hidden:true" ( In my example PurchaseOrder ). Now, for a User the key value would be shown using the "ForEdit" field( in my example PurchaseOrderForEdit). As I mentioned, During save, you will then copy value from ForEdit to your actual key field.

To Make a field Editable/ Non-Editable, Fiori elements uses the annotation @ObjectModel.enabled. I think you can find this logic somewhere in CL_SADL_ENTITY_CDS->IF_SADL_ENTITY~GET_ELEMENT_CONTROL. May be you could use something similar??. I have very less experience with Non-Draft Odata services.

Let me know if these info would help you, In case you need more info on how to implement, do let me know, I can get back to you :)

Regards,

Pratheek

0

Hi Pratheek,

Thanks again for your answer.

Maybe I am missing something, but I'm surprised that this sort of processing isn't already built into Fiori Elements, as I'm sure every object has the same requirement since we are all dealing with relational DB tables with key fields. As I said, I am after an SAPGui SM30-like experience, where newly created records have the key field(s) open for input, but existing records have them disabled.

Since we have a purely declarative view of the data with the CDS annotations, I cannot see how I can specify that a particular field should be available in 'Create' mode but not in 'Edit' mode, unless the framework supplies a specific annotation for this. Just saying that a field is 'read-only' or 'hidden' will surely make that field 'read-only' or 'hidden' in all circumstances, which won't fulfil the requirement.

In the Gateway builder, we have the ability to influence the entity properties' "createable" and "updatable" attributes seperately, but I cannot find a CDS annotation that has the same effect.

If you have an example CDS view/MDE you can point me at so I can have a look, that would be very helpful.

Thanks,

Andrew

0
Former Member

Hi Andrew,

This is an OData behavior and I don't think this should be handled "differently" by FIORI.

As an example, you can check CDS "C_PurchaseReqnHeader"

Regards,

Pratheek

0