#Analytics36 人がディスカッション中

I also have the same question about the overall flow of the dashboard. I think connecting gaming addiction risk with average daily gaming hours first and then moving into sleep hours and social isolation makes sense because it gives the viewer a natural progression from gaming behavior to possible related outcomes. I would mainly make sure each chart has a title that clearly tells the viewer what they are looking at rather than using short or generic labels. The takeaway statement should also be easy to understand on its own, so someone who has not seen the dataset before can quickly understand the main pattern without having to interpret every chart first. 

For the layout, I would try to keep the most important comparison visually prominent and make the other charts support that main story rather than competing for attention. Using the same color meaning throughout the dashboard would probably make it easier to compare the different risk levels, while too many colors could make the story harder to follow. I’d also check spacing, font sizes, axis labels, and whether any chart has unnecessary elements that could be removed. Overall, the story sounds clear, but I’d be interested in seeing how other people would arrange the charts so the connection between gaming behavior, sleep, and social isolation is immediately noticeable. A similar approach can be useful when looking at Free Fire beta, where keeping important information and comparisons visually clear can make it easier to understand what is changing between different versions or gameplay elements. Perfectly stated here  ffbeta.io

Chris's Set and FIXED LOD approach looks like the right solution.

One additional dashboard-layout point: if the milestone section contains multiple worksheets, place all of them inside a single tiled layout container and apply Dynamic Zone Visibility to that container rather than to each worksheet individually.

That way, when the Boolean calculation returns False, the entire milestone section is hidden and the surrounding tiled content can use the released space.

Hi Suraj,

To write a unit test for a @future (callout=true) method, you need to mock the HTTP callout (using HttpCalloutMock) and enclose the execution between Test.startTest() and Test.stopTest(). Salesforce runs all asynchronous methods (like future methods) called within startTest() and stopTest() synchronously right when Test.stopTest() executes. 

Here is an example test class structure to cover your method:

1.Create a Mock Callout Class:

Mock Implementation. 

Create a mock class that implements HttpCalloutMock to return a fake JSON response simulating your patchCall output (ensuring it contains 'state' => 'Success' and a valid JSON structure with an id field).

2.Prepare Test Data and Context:

Test Setup. 

In your test method, insert a test Bid_Review_Request__c record so that the update brUpdate; statement can successfully find and update a record in the database.

3.Wrap in Start/Stop Test:

Execution and Assertion. 

Assign your mock, wrap the future method call inside Test.startTest() and Test.stopTest(), and assert that the record was updated successfully.

Apex 

@isTest
private class NewProjectHandlerTopUpTest {
    // 1. Mock class for HTTP callouts
    public class MockHttpResponseGenerator implements HttpCalloutMock {
        public HTTPResponse respond(HTTPRequest req) {
            HttpResponse res = new HttpResponse();
            res.setHeader('Content-Type', 'application/json');
            res.setStatusCode(200);
            // Construct JSON response matching the parser requirements
            res.setBody('{"state": "Success", "resBody": "{\\"id\\": \\"12345\\"}"}');
            return res;
        }
    }
    @isTest
    static void testNewProjectHandlerTopUp() {
        // Create test record to satisfy update operation
        Bid_Review_Request__c testReq = new Bid_Review_Request__c(
            Name = 'Test Project'
            // Add required fields for Bid_Review_Request__c here
        );
        insert testReq;
        Map<String, String> recordMap = new Map<String, String>{
            'ID' => testReq.Id,
            'Name' => 'Test Project'
        };
        // Set mock callout
        Test.setMock(HttpCalloutMock.class, new MockHttpResponseGenerator());
        Test.startTest();
        // Calling the future method
        YourClassName.newProjectHandlerTopUp(recordMap, '{"test":"json"}', 'destination', 'WBS123');
        Test.stopTest(); // Future method executes here
        // Assertions to verify the record was updated
        Bid_Review_Request__c updatedReq = [SELECT WBS_Project__c FROM Bid_Review_Request__c WHERE Id = :testReq.Id];
        System.assertEquals('12345', updatedReq.WBS_Project__c, 'The WBS Project code should be updated successfully.');
    }
}

(Note: Replace YourClassName with the actual name of the Apex class containing your future method).

Hi Vikrant, autocomplete="off" isn't supported directly by lightning-input-field because it doesn't expose the underlying <input> element's autocomplete attribute. 

If you need to control autocomplete, you can use lightning-input instead of lightning-input-field and set: 

<lightning-input
    type="text"
    autocomplete="off"
    name="myField">
</lightning-input>

If you need to keep lightning-record-edit-form and lightning-input-field, you generally can't reliably disable the browser's autocomplete through the component attribute. 

If you can share which field you're trying to disable autocomplete for and what browser you're testing in, I can suggest a more specific workaround.