on 2018 Mar 12 2:47 PM
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
Request clarification before answering.
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Just for those looking for an answer to that question.
@Core.Immutable worked for me.
annotate OrderService.GrantedTypes with {
code
@title : '{i18n>grantedTypeCode}'
@Core.Immutable
@Common.IsUpperCase;
Result in creation mode:

Result in edit mode:

Although three years later, I hope it will be useful to someone. 🙂
Best regards,
Marc
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You can set Core.Computed to true on the Property you want to render as read-only on the UI when in edit-mode.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Andrew,
You can make use of {updateEnabled: 'EXTERNAL_CALCULATION' at field level } and make sure not to provide updateEnabled at BO header leve, and by default it will be disabled for editing for update, in case you want to play with functionality more then make use of Actions in BOPF.
BR
Ravi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Andrew,
You can use @ObjectModel.readOnly:true.
Regards,
Pratheek
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
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
Hello I can see you found the solution your self however i'm aware of an easier way to prevented the editing of a certain field when in update screen by adding the below in the behavior definitions interface.
field ( readonly : update ) FieldName;Hope this helps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 18 | |
| 6 | |
| 6 | |
| 6 | |
| 6 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.