I am currently working on a project in ServiceNow that requires me to configure around 500 descendants of the Configuration Item table by adding multiple form sections to the CI's with around 10-20 fields in each of these form sections. I currently am doing this by going into the Form Design for each CI, and manually adding these form section and fields for every CI individually, which takes far to long to do for 500 CI's.
Is there a way to add a form section to multiple CI's without having to go into the form design on every CI you want to change and adding it manually?
Technical answer: yes, because all of that form layout data is stored in tables (sys_ui_form_section, sys_ui_section, sys_ui_element, etc) that you could script to insert relevant records. However, due to the complexity (form sections, form elements, ordering) and the potential to run into conflicts (forms differ between tables), I would recommend this only as a last resort.
I think the real question is why is it required to have all of those fields displayed on the forms? If you're populating data from Discovery or a large import, can those fields just be visible by a list page, or just be available to use in filters? Will users actually be clicking to view a CI record and need to see that data on the form? The other part to consider is which view you are adding all of these form sections and fields to. As an example, a user won't see the data on a reference field hover if you're only making changes to the Default view, and won't see any of the fields on a mobile device if you don't add to the Mobile view.
Related
Looking to rebuild account pages for users of a Laravel 8 based application using something like Inertia/Livewire, Vue/React to make just the account area an SPA. User accounts currently have many pages in which to manage their items and have a dashboard that summarises item data that link to item listing pages for managing.
Ideally the new dashboard will have component based widgets which would load the HTML with temporary place holders for the items whilst the data is being requested. Not sure what would make a better user experience, having the whole page show temporary place holders for dynamic data and then all populate at the same time or populate each component as and when the data is ready.
Would it be more efficient to have each component request its own data individually or should each component specify what data it needs to the parent component (dashboard) which then does one request for all widgets?
The widgets would link to item listing pages where users can manage items. The way the listing pages should work is very similar to that of Asana, when an item is selected it opens a panel to the right of the list which loads the data related to that item. Again, when the panel opens it has place holders until the data requested has been fetched.
With Inertia the data can be queried in the controller and then passed as props to the view that Inertia renders. Items would be passed in this way and then listed on a listing page component. The URL should update from /items to /item/123 when clicking an item so it would have its own dynamic route that passes the item id to the relevant action.
Would this have its own action separate from the one that gets the initial list of items?
The list still needs to be there and used to click between items so was thinking it could actually use the same action?
Items could be in the thousands and will have filtering options so pagination and throttling will be necessary.
Been looking at Inertia with Vue so far and it looks to meet requirements, can’t change from using Laravel 8, just wondering what approach would be most suitable or if there is another approach that should be considered. Interested to hear how others might go about it.
I have a merchant application form that I want to split up into multiple regions so that the user only has to see one section of the application at a time. Each region is tied to the same table therefore:
Each region would have to share the same primary key
I only want one submission of the form items at the end of the form
I read this post Create an Apex form with multiple pages
which makes it seem like an easy to do process by using the Hide and Show Region template and manually separate the form into multiple regions. The problem I'm running into is that Apex requires a primary key to be tied to each form region, but you also can not have duplicate items on the same page. Any ideas?
-- attaching the PNG of the error message here Primary Key ERR
To me, it looks like a single page with several regions. Doing so, you'd have only one primary key item.
Logically, you'd separate items into different regions. Each of them should use its "Server side condition" which would decide whether to render (i.e. display) that region at certain time or not. It means that it doesn't have to be a hide and show region (besides, it is always here and visible, user just decides whether to reveal its contents or not). You'd create any region type (even an ordinary HTML region).
For example:
the first region displays customer ID, name and address. Other regions are "hidden" because e.g. P1_ID IS NULL is met as no data has been submitted yet. Once user enters ID, name and address and submits the page, P1_ID gets its value which enables other region(s) to be displayed
the second region contains items about some other customer's data; it is now visible because P1_ID is no longer NULL, but 3rd region is still hidden as you didn't enter some required data in the 2nd region which would let the 3rd region to be displayed.
and so forth
Note that the post you are referring to is 6 years old. That is like medieval in apex terms - so much has changed since then.
This is a way to do it if you want multiple pages. Just create multiple pages with the same form (using the create form functionality) and depending on the functionality needed on a specific page you delete the page items you don't want to show. If a database column is not included in the form it will not be touched by the dml process. This should be relatively simple to create.
Note: if you want to get up to speed on forms, read this blog
I am having a little problem with the form system in Symfony 3.3.
I do want to generate a table of form-fields inside a form, depending on the data the user is selecting inside the form.
For example, I have one field with a daterange, that I want to use for the days beeing displayed on the x-axis. On the y-axis I want to display the data the user has selected from a multiselect, that has 1..3 different categories.
The goal is to generate a table after these fields are selected, that has an integer formtype for each cell, that can be changed by the user.
I am quite new to symfony and this really makes my head hurt.
My question is, what would be the easiest or at least most clever concept to achieve this goal in Symfony 3.3?
Have a look at Symfony Form Events: https://symfony.com/doc/current/form/events.html you might be looking for preSubmit or postSubmit.
You could also look at a data transformer: http://symfony.com/doc/current/form/data_transformers.html
Finally based on you wanting to render a table, you could probably do this just in twig templates: https://symfony.com/doc/current/reference/forms/twig_reference.html
For this specific project, my team and I are thinking of leveraging the power of AngularJS directives and use them to build custom elements specific to our project, and use them like they were real HTML components.
For instance...
Say we have this table where each row is composed with a bunch of information that we get from a request, each row will be repeated with ng-repeat. Inside each row we will have multiple custom buttons with the same custom behavior. This button will also be used across different modules/pages on the website and not only on this specific table.
Our first thought was to use 2 directives, one for the table row and one for the button. The idea is that these are custom components/elements with custom attributes to define the custom behavior of the element. This would allow us to have a really nice modular application where each component is developed and unit-tested individually. Our HTML would also be easy to ready and understand.
Does this sound good?
Now, what about performance issues? Could we encounter big issues with this approach if, say we have a table with 100 of those rows and 5 of those buttons per row. Could this be big a problem if those rows/buttons had a couple of bindings to update information each X seconds?
The father of Angular Misko Hevery has this to say about performance and data-binding:
How does data binding work in AngularJS?
But in short like he says as long as you dont have more than 2000 data-bound items per page performance wont be an issue...
I have a question on the subject of composite attributes that I would be grateful if you could help me with.
I posted this before on other question blogs but got no response I am satisfied with.
I am writing JavaScript that will update the fields (i.e. address1_line1, address1_line2, address1_line3, address1_city, address1_stateorprovince, address1_postalcode, address1_country) in the composite (address1_composite). When the fields are updated the composite does not seem to update. I have to open the composite and close it again. Is there a way of doing this automatically in JavaScript?
I have tried the following ideas:
Idea 1:
Xrm.Page.data.entity.save();
This is recomended at http://community.dynamics.com/crm/b/magnetismsolutionscrmblog/archive/2013/10/22/working-with-dynamics-crm-2013-composite-fields-fly-out-menu.aspx
This is not any good as my customers want to view the composite before saving the page. Also I would not want to save the page for my customers as they do not want this. They would like to decide when to do this themselves.
Idea 2:
Xrm.Page.data.refresh();
This is not really what I wanted as I do not want to refresh the whole page. I just want to refresh the composite. Also it bring up a popup that warns you about not having saved the page which will be annoying for my customers.
Idea 3:
Writing the address from the address lines to the composite.
This feels like a nasty hack.
There is probably more than one way of doing this. I used the function
Xrm.Page.getAttribute("address1_composite")._attribute.setValueForCompositeField();
I do not like this for the following reasons:
This is a hack as it is not using the system functionality of the done button to write the data.
You do not get the system formatting you get with the done button although this will get done when the form is saved so it is not so bad.
In the future if customers are allowed to add their own composite fields it could cause problems as the field names could be different.
It requires me to write extra code for each form that has a composite which has fields with different schema names. E.g. I have to write different code for forms with ShipTo and BillTo addresses as the code for the account form will not work.
Another idea was to set the focus to the composite field after a change has been made to any of the fields inside the composite.
Xrm.Page.data.entity.attributes.get("address1_composite").controls.get(0).setFocus();
This is the best idea so for but it is far from perfect. This forces the user to press the done button and hence the fields will be written. I was hoping for something more automated.
My Question:
What would be great is if there was a way to click the composite done button in JavaScript. This would give me the formatting of the done button and the automation I need.
Update - 14/04/2014
Since posting this question I have been in contact with Microsoft and they say there is no supported way of clicking the done button via a program.
If the field is locked down CRM JavaScript does not send the data back to the server for updating. Another approach would be:
perform the update using JavaScript (so the user sees the change); and
use a server side plugin on the Update event so the value is persisted.