I know you can disable some actions via Automation Step. But can you also explicitly hide them ? I understand a customisation can achieve the same result. Automation Step however is quick and easy to roll out.
TIA
Hi Rick the only why to "Hide" them is to remove all entries of the action from all automation steps from page/screen. If there are any entries even if they are not active the code will still load them in the menus(grayed out).
Option 1: Remove all "steps" that have the action in them for that page.
Option 2: Hide the action using code:
protected void SOShipment_RowSelected(PXCache cache, PXRowSelectedEventArgs e)
{
ActionNameHere.SetVisible(true);
}
Related
I'm trying to add options to the Source dropdown on the Leads screen. The field uses the CRMSourcesAttribute class to define the existing list. After simply creating a new attribute class to add my own items, I extend the CRLead.Source CacheAttached event to use my new attribute class instead. The result is that there is no change - the new dropdown items are not shown. After doing this, if I inspect the field and select the Drop Down Values button, I do actually see the new options in the Drop Down Values popup window. Any ideas on what could be preventing the new options from displaying in the dropdown itself?
Here's how I configure it in my LeadMaint graph extension:
[PXMergeAttributes(Method = MergeMethod.Append)]
[PXRemoveBaseAttribute(typeof(CRMSourcesAttribute))]
[CRMSourcesExt] // list with old + new options
protected virtual void _(Events.CacheAttached<CRLead.source> e) { }
(v20R2)
Another option is to use code and create a new attribute class with new options, then override the DAC field to use it instead. However, as far as I know, you still have to go through the steps of activating the new options in the workflow customizations UI for each of the fields you're overriding. But then you can refer to the new options in code without having to search the list's AllowedValues at runtime.
With help from a colleague, I was able to get it working, and “without code” through screen workflow customization. I removed my code, then customized it with a new custom Workflow copied from the default. Not sure yet of the ramifications of this, like if we can access the new options in other real code or not, but I see how to create these options now. It has to also be done for both Lead and Opportunity in this scenario. It’s a bit tedious and ethereal (good word) though. I can see this easily causing problems and unexpected results for us we’ll want to watch out for.
Update 5/28/21: I added the options in the Workflow customizations for the field, then copied the default workflow to a new workflow, activated it, and activated the new options for each state/transition. I don't like it, but Acumatica tells me "that's just the way it is now". Note: you'll want to do this for other places referencing CRMSourcesAttribute as well, such as Opportunity.
Is there a way to override the Quick Process Action Button in Acumatica.
Requirement:
After clicking on the OK Button, print pick list and the Shipment confirmation should be opened as a Combined in a single report instead of opening in the two separate tabs.
We could not able to locate the Quick Process action button.
Please help me to resolve this .
Quick Action button is made available, per order type. Review the Sales Order type screen.
Inside the standard graph SalesOrderEntry graph, you will find the method QuickProcess. It is available after you create the graph extension. Inside your extension, you may extend QuickProcess. Or override if you wish.
Is there any way i can implement two stepts like this(see below) in a single function:
When I click on the "Button_name" button
When I click on the "Link_name" name
Is there any syntax so the cucumber won't care what will come after the string and on these two steps i will not need to make two different functions?
Usually i will implement them separately with something like this:
#When("^I look at the \"([^\"]*)\" button$")
public void smt (String smt){ }
Yes, you could implement one step with one method, and pass what was clicked as an argument to that method.
However, this will make your test code more complicated. So please consider whether you should. Having complicated logic in your test code, will make your tests harder to understand and maintain, thus defeating their purpose imho.
If you want to reuse common functionality, the recommendation is to write helper methods that you can call from your step definition.
For example:
#When ("I click on the {string} button")
public void clickButton(String button) {
clickButton(button);
}
#When ("I click on the "Link_name" name")
public void clickLink(String link) {
clickLink(link);
}
and implement clickButton() and clickLink() to click a button or link respectively. (I've used different clickButton() and clickLink() methods in this example, because iirc these would use different types of elements.)
If needed (or you really want to use a switch) you could use a switch statement to get use the right selector based on the button or link name.
Alternatively, you could implement page objects, add all the relevant selectors for the page object there and call the method on the relevant page object that click that particular link/button, delegating the logic to interact with the UI to the page objects and calling this logic from your step definitions.
If are different context one click button and other click link, the best practices is to have two different steps.
One of the bad practices of using BDD is to think about reusing code within steps.
When you have a lot of logic inside a step, any modification can affect many tests.
Should be concerned about code reuse in page objects.
I'm using this NetResource class to send files to a network drive and it looks like this:
[StructLayout(LayoutKind.Sequential)]
public class NetResource
{
public ResourceScope Scope;
public ResourceType ResourceType;
public ResourceDisplayType DisplayType;
public int Usage;
public string LocalName;
public string RemoteName;
public string Comment;
public string Provider;
}
Now it's very important that the order of these fields stay the same, as hinted on by the StructLayout attribute.
However, when someone would run a resharper cleanup, resharper decides to move the fields around and that would break the code.
Is there any way of telling rehsarper to not mess with it? I feel like if I can't do that, someone is going to eventually break the code and have no idea where to look.
But a mediocre solution to that I think would be to create a unittest that can check if there layout is as expected.
Edit: I've seen this answer, but it is outdated and requires resharper settings to be updated. I will also not be guaranteed that coworkers use this resharper setting. I'm looking for a way to add it in the code, just like you can do // ReSharper disable once InconsistentNaming
I see a couple of solutions here:
You might mark the class with NoReorderAttribute from the JetBrains.Annotations (there are several ways to add them to a project). Then ReSharper will stop reordering members inside the marked code entity.
It is mostly about already mentioned answer, I will show you how to get the same things in last ReSharper builds. All you need is to add "System.Runtime.InteropServices.StructLayoutAttribute" to "Non-reorderable types" pattern in ReSharper | Options | Code Editing | C# | File Layout.
Step 1:
Step 2:
Step 3:
Step 4:
Step 5:
To make sure your colleagues use the same settings in ReSharper, save this change to the Solution team shared layer (Save To at the bottom of the Options dialog). Then if any of your colleagues opens the solution, ReSharper will automatically use the setting from this layer with no additional actions required.
I have added a Global Button with the following code.
public override void Initialize()
{
if (!String.IsNullOrEmpty(Base.PrimaryView))
{
Type primaryViewItemType = Base.Views[Base.PrimaryView].Cache.GetItemType();
PXAction action = PXNamedAction.AddAction(Base, primaryViewItemType, "SubmitTicket", "Submit Ticket", TestClick);
}
}
public IEnumerable TestClick(PXAdapter adapter)
{
throw new PXException("Button clicked from graph" + Base.GetType().Name);
}
And it renders the button like this in each of the pages.
Now, I would like to display a popup panel, on button's click. I know I can create a popup panel on screen section. But, is there some way that I can have a general popup panel created in one place and can be displayed on each of the pages on the button's click?
Thank you.
As #HB_ACUMATICA mentioned there is no good easy way.
Providing another alternative to his post, you can create a graph and use it as a reusable popup by calling:
throw new PXPopupRedirectException(graph, string.Empty, true)
One thing I ran into was a sizing issue on the popup...
Changing the height/width when calling another graph as an in-page popup using PXPopupRedirectException
If you do copy and paste the PXSmartPanel you can create re-usable business logic by implementing the reusable business logic pattern found in this help as a starting point:
Reusing Business Logic
If I understand correctly you want to share the same PXSmartPanel control in different pages without having to copy/paste it in every screen.
In Acumatica Framework this is achieve by custom container controls like 'PXUploadDialog' which derives functionality from other controls like 'PXSmartPanel'. This is the control that is used when you attach files in all screen.
Unfortunately there seems to be no documentation on how to achieve this.
The closest I found is this SO question which is essentially unanswered:
Create custom User Control for Acumatica
Considering this, you may want to copy/paste the same smart panel in all screen.
To ease copying you can use the 'Edit ASPX' feature, make sure you backup the project before.
Edit ASPX to get to the code:
Copy paste your smart panel in the page and click 'GENERATE CUSTOMIZATION SCRIPT' to package the changes in the project: