Scoped applications in Fuji provide a large amount of data and process protection between application. Of course, this comes at a cost of convenience and extensibility.
As we learned yesterday, by default a scoped application cannot simple add new fields or customizations to an application table in a different scope. However there are many times where this is a valid use case. For example, most ticket integrations with 3rd party systems require additional fields on the incident table.
If your current session is running in your custom application scope you'll find that it's not so easy to add fields to any table in the platform like it was in pre-Fuji releases. When attempting this from the "Configure List or Form Layout" option you'll notice a read-only form. The information in the banner provides some information. Although, if you're like me and conditioned to ignore messages, you won't even notice that it's there and is actually helpful.
The message tells us that the global scope owns this view. If you want to modify the form, including adding new fields, you'll need to:
- Switch to the scope that owns the view. This will allow you to make the change but the change will not be captured in your application. This means that you won't be able to publish this change to the marketplace.
- Create a new form section in your scope
- Select an existing section that is in your scope
The ability to capture a form section within a different scope is a pretty cool concept. This means that application can control just their section of the form. In the past all form layout configurations were tracked together, meaning whoever made the latest change to the form would win. Now we can delegate form layouts by application.
Once our scope has it's own list/form view or a form section we have the ability to not only customize the field layout, but we can also create new fields just as we did in the past, but now have them included with our application.
As of this writing, it's a little inconsistent but here's what my findings are using the various methods of creating a field. There's a chance that this will be more consistent in a future patch. Again, this is creating a field in global or other scope that is not my application scope, while also bundling the field in my application.
Create new field from our scope view or section using the legacy slush-bucket (Form/List Layout)
Field name is system generated from your label with the application prefix (x_cavu_cavutest_my_new_field)
Create new field from our scope view or section using the Form Designer
Field name is system generated from your label with application prefix as well as u_ prefix (x_cavu_cavutest_u_my_new_field)
Create a new field from the dictionary (System Definition -> Dictionary or Form Configure Dictionary)
Field name is system "sugggested" from your label with your scope prefix. You can override the column name (how you would reference from script), but you can't modify the prefix part of the name
Create a new field from the table record (System Definition -> Tables, New Column from related list)
Same as dictionary method since the new column from the table form brings you to the dictionary
Recommendation: Given the above results, I would highly recommend that you always use the dictionary or table method to create your new fields. This will allow you to control the column names. If a field label is on the longer side you might end up with a truncated name. It would be much cleaner to simply provide a shorter, more understandable name.