There is existing (dead) code for this already.
Re-vitalize the dead code, clean it up, and get it working.
The embargoTypes.name SQL in the back-end operates differently in that it is not involved in part of a column name and is exclusively for filtering. This changes the nature of the query and I opted to go with sub-queries for selecting the IDs because I can design it this way and avoid LEFT JOIN (or INNER JOIN). This has not seen extensive performance testing but this new SQL query conditions should be run through some performance testing.
I went with Embargo Type for the new custom filter because the existing code used that name.
A custom filter uniqueEmbargoType is created because the unique/uniq angularjs is not available. Using unique or uniq yields an error like this:
Using the custom filter (uniqueEmbargoType) avoids having to pass the additional | filter:{isActive: true} and similar. This can be done and is done within the same filter.
This adds a unit test for the filter (AngularJS context of filter) for the Embargo Type filter (Vireo table list context of filter).
The addition of the Embargo Type causes a test in the SystemDataLoaderTest class to fail due to a hard-coded value representing all of the default filters. This has been updated to include the new filter in the total.
The UI has an existing filter view, but it was slightly tweak that filter view to address problems in the user experience. I opted to make its design more closely match that of the Status filter (which goes in line with the issue request using Status filter as an example).
resolves #54
There is existing (dead) code for this already. Re-vitalize the dead code, clean it up, and get it working.
The
embargoTypes.nameSQL in the back-end operates differently in that it is not involved in part of a column name and is exclusively for filtering. This changes the nature of the query and I opted to go with sub-queries for selecting the IDs because I can design it this way and avoidLEFT JOIN(orINNER JOIN). This has not seen extensive performance testing but this new SQL query conditions should be run through some performance testing.I went with
Embargo Typefor the new custom filter because the existing code used that name.A custom filter
uniqueEmbargoTypeis created because theunique/uniqangularjs is not available. Usinguniqueoruniqyields an error like this:Using the custom filter (
uniqueEmbargoType) avoids having to pass the additional| filter:{isActive: true}and similar. This can be done and is done within the same filter.This adds a unit test for the filter (AngularJS context of filter) for the Embargo Type filter (Vireo table list context of filter).
The addition of the
Embargo Typecauses a test in theSystemDataLoaderTestclass to fail due to a hard-coded value representing all of the default filters. This has been updated to include the new filter in the total.The UI has an existing filter view, but it was slightly tweak that filter view to address problems in the user experience. I opted to make its design more closely match that of the Status filter (which goes in line with the issue request using Status filter as an example).