Might check if you're running as administrator and your yarn install is to your account (if not logged in as administrator)?
type-o
I finally figured it out -
There were more than just datatables that I needed to include.
FWIW - if it helps anyone - here's the full bundle:
{
"output": "view-resources/Areas/App/Views/_Bundles/account-datatables.min.js",
"input": [
"wwwroot/Common/Scripts/Datatables/datatables.ajax.js",
"wwwroot/Common/Scripts/Datatables/datatables.defaults.js",
"wwwroot/Common/Scripts/Datatables/datatables.record-actions.js",
"node_modules/datatables.net/js/jquery.dataTables.js",
"node_modules/datatables.net-bs4/js/dataTables.bootstrap4.js",
"node_modules/datatables.net-select/js/dataTables.select.js",
"node_modules/datatables.net-responsive/js/dataTables.responsive.js",
"node_modules/datatables.net-responsive-bs4/js/responsive.bootstrap4.js"
]
I feel your pain Dustin! I've done that before.
Found it - My columndefs were under my listaction.
Yet another instance of a missing curley bracket.
I don't know if it is any help, but the Dockerfile files are set to always copy in the downloaded solution, which means incremental builds are a bit pointless because the 'new' Dockerfile will trigger a rebuild of almost everything, every time.
Changing these to copy if newer while developing locally sped up my builds.
For what it's worth - we accomplished this by adding a project to the solution and referencing as necessary.
Depending on where / how you will want legacy data access, you can approach this by either adding references whereever you need this legacy data, or - create a service for it and reference it only there.
For example - You create a new project that connects to your legacy data. Then, you reference that in the .Core project. In the .Core project, you wrap the legacy data access with a service.
Your new legacy data service could then be exposed throughtout the architecture
Yes, this is the case.
One side effect of this the filter's always prepopulate with the date the page is rendered, excluding any results with a date time property from the results.
First view is always "today".
What needs to happen is they're only used as a filter if they're set.
This is a very bad user experience to have these set and used automatically.
Ah - I see - replaced with daterangepicker.
However, the templates in the rad tool apparently haven't been updated.
Is this correct?
In 11.0 - in bundles, there is:
"node_modules/bootstrap4-datetimepicker/build/js/bootstrap-datetimepicker.min.js",
"wwwroot/assets/bootstrap4-datetimepicker/defaults.js",
this is not in the 11.2 bundles.