Hide repeatable subgroup in Vue Formulate - vue-formulate

I'm trying to hide the initial (default) first group in a repeatable group, much like what is described in Initially hide first group in Vue-Formulate repeatable group except:
I'm using a schema
My group is a subgroup of another group.
Tried to follow jpschroeder's example and logic here:
https://codesandbox.io/s/vue-formulate-group-with-button-to-start-forked-7u682
The subgroup data is being set to an empty array in the `mounted` lifecycle hook, as recommended, but the field persists...

WAY overthinking this. While I never got the subgroup to not display using the above technique, I think I lost track of the original goal: to just keep the subgroups visualy hidden. If that's the only point, I can include a component in the schema to wrap the group in a details tag:
https://codesandbox.io/s/vue-formulate-group-with-button-to-start-forked-frzd7
While this works, it's a little cluttery. Better to figure out how to replace the div tag in the group template with details, or just use the provided classes to mimic the details behavior.

Related

React-Admin filters that relate to the current results

We're really enjoying using the capabilities offered by React-Admin.
We're using <ReferenceArrayInput> to allow filtering of a <List> by Country. The drop-down contains all countries in the database.
But, we'd like it to just contain the countries that relate to the current set of filtered records.
So, in the context of the React-Admin demo, if we've filtered for Returned, then the Customer drop-down would only contain customers who have returned items (see below). This would make a real-difference in finding the records of interest.
Our current plan is to (somehow) handle this in our <DataProvider>. But, is there are more ReactAdmin friendly way of doing this?
So you want to build dependent filters, which is not a native feature of react-admin - and a complex beast to tame.
First, doing so in the dataProvider will not work, because you'll only have the data of the first page of results. A record in a following page may have another value for your array input.
You could implement that logic in a custom Input component instead. This component can wrap the original <ReferenceArrayInput> and read the current ListContext to get the current data and filter value (https://marmelab.com/react-admin/useListContext.html), then alter the array of possible values using the filter prop (https://marmelab.com/react-admin/ReferenceArrayInput.html#filter).

react-admin conditional rendering on select field

I got stuck a little bit:
I've got Field A which is for querying the projects (Select field -> ReferenceInput) when the user hits this, we should only show the user on Field B (Select Field -> ReferenceInput) the relevant tasks based on the projectId.
How could I achieve this?
Link to image to visualise the problem
What you’re looking for is the useFormState or FormDataConsumer. Take a look in the docs and let me know if you have any other questions related.
https://marmelab.com/react-admin/Inputs.html#linking-two-inputs

React Admin - Make input for filter based on other resource

I am using React Admin to make a dashboard and I have this Lead resource with the status field, that is computed based on another resource, Call, and wanted to make a filter component for Lead's list. The way it works is that for each lead, I query the last call (sorted by a date field) associated with this lead and get its status. The lead status is the status for the last call.
{ filter: { lead }, sort: { date: -1 }, limit: 1 }
the lead status query
I use this query to make a field (that appear in the list in the row of a single lead), and wanted to know how I can make an input component to use as a filter in the list. I know this pattern is weird, but it's hard to change it in the backend because of how it's structured. I am open to suggestions concerning how to change this messy computed field situation, but as I said, I would be satisfied with knowing how I can create the input component.
The solution I'm going with is a computed field. In my case, as I use MongoDB, it will be done through an aggregation pipeline. As I'm using REST instead of GraphQL, I cannot use a resolver that would only be called in the need of the status field, sometimes resulting in an uneeded aggregation (getting the last Call for a given Lead). However, it won't incur in an additional roundtrip - and instead only consume more processing time in the DB - which would be necessary for react-admin to compute this field in through a reference. And status is an important field that will usually be needed anyways.

SRSS: Dynamic amount of subreports in a report

it might be possible I'm searching for the wrong keywords, but so far I couldn't find anything useful.
My problem is quite simple: At the moment I get a list of individual Ids through a report parameter, I pass them to a procedure and show the results.
The new request is like this: Instead of showing the list for all individuals at once, there should be a list for each individual id.
Since I'm quite a beginner in srss, I thought the easiest approach would be the best: Create a subreport, copy the shown list, and create a subreport per individual id.
The amount of this IDs is dynamic, so I have to create a dynamic amount of subreports.
Funny enought, this doesnt seem to be possible. This http://forums.asp.net/t/1397645.aspx url doesnt show exactly the problem, but it shows the limit of the subreports.
I even ran trough the whole msdn pages starting http://technet.microsoft.com/en-us/library/dd220581.aspx but I couldnt find anything there.
So is there a possibility, to create a loop like:
For each Individual ID in Individual IDs, create a subreport and pass ONE ID to this?
Or is there another approach I should use to make this work?
I tried to create a 'Fake'-Dataset with no sql query but just for iterating the id list, but it seems the dataset needs a data-source...
As usual, thanks so far for all answers!
Matthias Müller
Or is there another approach I should use to make this work?
You didn't provide much detail about what sort of information needs to be included in the subreport, but assuming it's a small amount of data (say, showing a personnel record), and not a huge amount (such as a persons sales for the last year), a List might be the way to go.
I tried to create a 'Fake'-Dataset with no sql query but just for iterating the id list, but it seems the dataset needs a data-source...
All datasets require a data source, though if you're merely hard-coding some fake return data, any data source will do, even a local SQL instance with nothing in it.

SAP Business One I Query inventory base on user defined field

I am running a query on a product. I need a field that will look at the user defined field which contains another product and check that stock level. Any help would be great.
What is the main objective?
Are you trying to check on that item because that item is the material/component? or act like a substitution?
Using UDF is quite not feasible as you have to get the link to the Item Master Data, and I have not figured out yet how to do that.
But if you are using it as substitution, why don't you use Alternative Item in Inventory > Item Management > Alternative Items? It will show on Sales Quotation for you to display it to customer. Or during Sales Order, you can get it displayed for alternative should your main item is shortage.
If you are using those item as a component, I suggest you use Bill of Material. During Production Order you will be able to see those component's availability in qty, and also you can have more than one, unlike UDF.
Hope this helps.
I think the key part you're missing here is the naming convention which SAP adpots for user defined fields.
Correct me if I'm wrong, but it seems that you're capable of querying these fields from a SQL point of view.
UDFs by defuault, will have their column name prefixed with "U_".
For example, the UDF 'AnotherProduct' will be referred to in SQL as 'U_AnotherProduct'.
Hope this helps, if not, please explain your problem in some more detail.