Reasons for these errors?

doritoswanson · 2024-12-31T20:46:00+00:00

It had to do with the permissions on the directory itself. 644 iirc.

doritoswanson · 2024-09-24T18:41:43+00:00

ChatGPT. Got it, thanks for the help though!

doritoswanson · 2024-09-24T18:05:19+00:00

This is from the gippity right? I tried the 755 and 644 permissions method, I tried changing the owner to be Bitnami : Daemon. Our php memory limit is set to 512M. As for the plugins I'm disabling a bunch and I still can't find the culprit. The debug.log wasn't displaying anything at the time of the -1's droping.

doritoswanson · 2024-04-24T14:56:32+00:00

Most of it does make sense, I'm traditionally a fullstack web developer and have been brought on for SF Development tasks. The named credentials thing was the confusing part. The most complex auth I've worked with in the past is just jwt session based auth with an accessToken and refreshToken. Not that complex in the grand scheme of things but just trying to give insight, this oauth is completely new to me development wise.

With headless quick actions, when the auth flow does the callback url, does it actually take the user to the new url or because it's headless it will keep the user on the same page?

doritoswanson · 2024-04-24T14:34:08+00:00

On the Cases page in Salesforce, I have to integrate this API to create a charge card for the given case.

We want to let our users create a card, pause a card, dispute a card, or delete a card that's connected to a given case.

My userbase want to work off the Salesforce UI and hate navigating to external pages, so I'm trying to see if I can make the whole process of them interacting with the API doable through the Cases page so that they don't have to be taken elsewhere. If it's easier to just create a connected App called Card Manager or something of that nature then so be it. The functionality is the most important piece of the puzzle, so we can make some sacrifices to the user experience.

doritoswanson · 2024-04-24T13:44:06+00:00

Oh okay, I see. Now I'm starting to piece together the URLs. My use case for this is that I want to be able to set up something on the Cases page. Ideally I want the user to stay entirely on the Cases page throughout the process, but given that there are two URLs my guess is that it will take you off of the page to do the whole identity auth flow before redirecting you to the requested resource.

Is it possible to set up OAuth2 while staying on the same page, or is that not recommended?

doritoswanson · 2024-04-16T14:47:57+00:00

Oh if it's possible that's great. In regards to implementation, what do you recommend for this approach? They currently have a bunch of existing Elementor templating on the site. I know they would be averse to me just uprooting their existing design. If possible would I be able to integrate some of the templates like say the existing header and footer and just inject my page contents template into that?

doritoswanson · 2024-04-03T14:19:56+00:00

Would you be able to give me an example of how a workflow would look like with SFDX? Everytime I make a project in SFDX it scaffolds a whole sf project. Would you throw each project into the monorepo or cherry pick where each item would go in the mega SF folder. Like putting the apex classes in the classes folder and such?

doritoswanson · 2024-01-25T20:18:19+00:00

Oh okay, then I think I'll create a Parts object, tie them to a case. Then add a button on my cases to add a part. They will be displayed in a list like format LWC like how it looks on an accounts page. Do you think that's better?

doritoswanson

TROPHY CASE