2021-08-26 11:39:17 +00:00
|
|
|
import {DataRowModel} from "app/client/models/DataRowModel";
|
2022-07-04 14:14:55 +00:00
|
|
|
import DataTableModel from "app/client/models/DataTableModel";
|
2022-01-27 17:51:37 +00:00
|
|
|
import {DocModel} from 'app/client/models/DocModel';
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
import {ColumnRec} from "app/client/models/entities/ColumnRec";
|
2021-08-26 11:39:17 +00:00
|
|
|
import {TableRec} from "app/client/models/entities/TableRec";
|
|
|
|
import {ViewSectionRec} from "app/client/models/entities/ViewSectionRec";
|
2023-07-07 08:54:01 +00:00
|
|
|
import {UIRowId} from "app/common/TableData";
|
2021-08-26 11:39:17 +00:00
|
|
|
import {LinkConfig} from "app/client/ui/selectBy";
|
2023-07-19 17:37:22 +00:00
|
|
|
import {FilterColValues, QueryOperation} from "app/common/ActiveDocAPI";
|
2022-06-07 14:57:29 +00:00
|
|
|
import {isList, isListType, isRefListType} from "app/common/gristTypes";
|
2021-08-26 11:39:17 +00:00
|
|
|
import * as gutil from "app/common/gutil";
|
2022-01-27 17:51:37 +00:00
|
|
|
import {encodeObject} from 'app/plugin/objtypes';
|
2022-02-01 19:51:40 +00:00
|
|
|
import {Disposable, toKo} from "grainjs";
|
2021-08-26 11:39:17 +00:00
|
|
|
import * as ko from "knockout";
|
2022-06-07 14:57:29 +00:00
|
|
|
import identity = require('lodash/identity');
|
2022-01-27 17:51:37 +00:00
|
|
|
import mapValues = require('lodash/mapValues');
|
|
|
|
import pickBy = require('lodash/pickBy');
|
2021-08-26 11:39:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns if the first table is a summary of the second. If both are summary tables, returns true
|
|
|
|
* if the second table is a more detailed summary, i.e. has additional group-by columns.
|
|
|
|
* @param summary: TableRec for the table to check for being the summary table.
|
|
|
|
* @param detail: TableRec for the table to check for being the detailed version.
|
|
|
|
* @returns {Boolean} Whether the first argument is a summarized version of the second.
|
|
|
|
*/
|
|
|
|
function isSummaryOf(summary: TableRec, detail: TableRec): boolean {
|
|
|
|
const summarySource = summary.summarySourceTable();
|
|
|
|
if (summarySource === detail.getRowId()) { return true; }
|
|
|
|
const detailSource = detail.summarySourceTable();
|
|
|
|
return (Boolean(summarySource) &&
|
|
|
|
detailSource === summarySource &&
|
|
|
|
summary.getRowId() !== detail.getRowId() &&
|
|
|
|
gutil.isSubset(summary.summarySourceColRefs(), detail.summarySourceColRefs()));
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Maintains state useful for linking sections, i.e. auto-filtering and auto-scrolling.
|
|
|
|
* Exposes .filterColValues, which is either null or a computed evaluating to a filtering object;
|
|
|
|
* and .cursorPos, which is either null or a computed that evaluates to a cursor position.
|
|
|
|
* LinkingState must be created with a valid srcSection and tgtSection.
|
|
|
|
*
|
|
|
|
* There are several modes of linking:
|
|
|
|
* (1) If tgtColId is set, tgtSection will be filtered to show rows whose values of target column
|
|
|
|
* are equal to the value of source column in srcSection at the cursor. With byAllShown set, all
|
|
|
|
* values in srcSection are used (rather than only the value in the cursor).
|
|
|
|
* (2) If srcSection is a summary of tgtSection, then tgtSection is filtered to show only those
|
|
|
|
* rows that match the row at the cursor of srcSection.
|
|
|
|
* (3) If tgtColId is null, tgtSection is scrolled to the rowId determined by the value of the
|
|
|
|
* source column at the cursor in srcSection.
|
|
|
|
*
|
|
|
|
* @param gristDoc: GristDoc instance, for getting the relevant TableData objects.
|
|
|
|
* @param srcSection: RowModel for the section that drives the target section.
|
|
|
|
* @param srcColId: Name of the column that drives the target section, or null to use rowId.
|
|
|
|
* @param tgtSection: RowModel for the section that's being driven.
|
|
|
|
* @param tgtColId: Name of the reference column to auto-filter by, or null to auto-scroll.
|
|
|
|
* @param byAllShown: For auto-filter, filter by all values in srcSection rather than only the
|
|
|
|
* value at the cursor. The user can use column filters on srcSection to control what's shown
|
|
|
|
* in the linked tgtSection.
|
|
|
|
*/
|
|
|
|
export class LinkingState extends Disposable {
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
// If linking affects target section's cursor, this will be a computed for the cursor rowId.
|
2023-07-07 08:54:01 +00:00
|
|
|
public readonly cursorPos?: ko.Computed<UIRowId>;
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
|
|
|
|
// If linking affects filtering, this is a computed for the current filtering state, as a
|
|
|
|
// {[colId]: colValues} mapping, with a dependency on srcSection.activeRowId()
|
|
|
|
public readonly filterColValues?: ko.Computed<FilterColValues>;
|
|
|
|
|
2022-01-27 17:51:37 +00:00
|
|
|
// Get default values for a new record so that it continues to satisfy the current linking filters
|
|
|
|
public readonly getDefaultColValues: () => any;
|
|
|
|
|
2021-08-26 11:39:17 +00:00
|
|
|
private _srcSection: ViewSectionRec;
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
private _srcTableModel: DataTableModel;
|
|
|
|
private _srcCol: ColumnRec;
|
|
|
|
private _srcColId: string | undefined;
|
2021-08-26 11:39:17 +00:00
|
|
|
|
2022-01-27 17:51:37 +00:00
|
|
|
constructor(docModel: DocModel, linkConfig: LinkConfig) {
|
2021-08-26 11:39:17 +00:00
|
|
|
super();
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
const {srcSection, srcCol, srcColId, tgtSection, tgtCol, tgtColId} = linkConfig;
|
2021-08-26 11:39:17 +00:00
|
|
|
this._srcSection = srcSection;
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
this._srcCol = srcCol;
|
|
|
|
this._srcColId = srcColId;
|
2022-01-27 17:51:37 +00:00
|
|
|
this._srcTableModel = docModel.dataTables[srcSection.table().tableId()];
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
const srcTableData = this._srcTableModel.tableData;
|
2021-08-26 11:39:17 +00:00
|
|
|
|
|
|
|
if (tgtColId) {
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
const operation = isRefListType(tgtCol.type()) ? 'intersects' : 'in';
|
2022-02-01 19:51:40 +00:00
|
|
|
if (srcSection.parentKey() === 'custom') {
|
|
|
|
this.filterColValues = this._srcCustomFilter(tgtColId, operation);
|
|
|
|
} else if (srcColId) {
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
this.filterColValues = this._srcCellFilter(tgtColId, operation);
|
2021-08-26 11:39:17 +00:00
|
|
|
} else {
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
this.filterColValues = this._simpleFilter(tgtColId, operation, (rowId => [rowId]));
|
2021-08-26 11:39:17 +00:00
|
|
|
}
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
} else if (srcColId && isRefListType(srcCol.type())) {
|
|
|
|
this.filterColValues = this._srcCellFilter('id', 'in');
|
2022-05-12 12:59:17 +00:00
|
|
|
} else if (!srcColId && isSummaryOf(srcSection.table(), tgtSection.table())) {
|
2021-08-26 11:39:17 +00:00
|
|
|
// We filter summary tables when a summary section is linked to a more detailed one without
|
|
|
|
// specifying src or target column. The filtering is on the shared group-by column (i.e. all
|
|
|
|
// those in the srcSection).
|
|
|
|
// TODO: This approach doesn't help cursor-linking (the other direction). If we have the
|
|
|
|
// inverse of summary-table's 'group' column, we could implement both, and more efficiently.
|
|
|
|
const isDirectSummary = srcSection.table().summarySourceTable() === tgtSection.table().getRowId();
|
2022-04-07 15:18:20 +00:00
|
|
|
const _filterColValues = ko.observable<FilterColValues>();
|
|
|
|
this.filterColValues = this.autoDispose(ko.computed(() => _filterColValues()));
|
|
|
|
|
|
|
|
// source data table could still be loading (this could happen after changing the group by
|
2022-10-20 05:35:11 +00:00
|
|
|
// columns of a linked summary table for instance), hence the below listener.
|
2022-04-07 15:18:20 +00:00
|
|
|
this.autoDispose(srcTableData.dataLoadedEmitter.addListener(_update));
|
|
|
|
|
|
|
|
_update();
|
|
|
|
function _update() {
|
2021-08-26 11:39:17 +00:00
|
|
|
const result: FilterColValues = {filters: {}, operations: {}};
|
2022-04-27 17:46:24 +00:00
|
|
|
if (srcSection.isDisposed()) {
|
|
|
|
return result;
|
|
|
|
}
|
2021-08-26 11:39:17 +00:00
|
|
|
const srcRowId = srcSection.activeRowId();
|
|
|
|
for (const c of srcSection.table().groupByColumns()) {
|
2022-08-30 20:13:57 +00:00
|
|
|
const colId = c.colId();
|
2021-08-26 11:39:17 +00:00
|
|
|
const srcValue = srcTableData.getValue(srcRowId as number, colId);
|
|
|
|
result.filters[colId] = [srcValue];
|
2022-01-27 17:51:37 +00:00
|
|
|
result.operations[colId] = 'in';
|
2022-08-30 20:13:57 +00:00
|
|
|
if (isDirectSummary && isListType(c.summarySource().type())) {
|
2022-06-07 14:57:29 +00:00
|
|
|
// If the source groupby column is a ChoiceList or RefList, then null or '' in the summary table
|
|
|
|
// should match against an empty list in the source table.
|
|
|
|
result.operations[colId] = srcValue ? 'intersects' : 'empty';
|
2021-08-26 11:39:17 +00:00
|
|
|
}
|
|
|
|
}
|
2022-04-07 15:18:20 +00:00
|
|
|
_filterColValues(result);
|
|
|
|
}
|
2022-02-01 19:51:40 +00:00
|
|
|
} else if (srcSection.parentKey() === 'custom') {
|
|
|
|
this.filterColValues = this._srcCustomFilter('id', 'in');
|
2021-08-26 11:39:17 +00:00
|
|
|
} else {
|
2022-01-27 17:51:37 +00:00
|
|
|
const srcValueFunc = srcColId ? this._makeSrcCellGetter() : identity;
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
if (srcValueFunc) {
|
|
|
|
this.cursorPos = this.autoDispose(ko.computed(() =>
|
2023-07-07 08:54:01 +00:00
|
|
|
srcValueFunc(srcSection.activeRowId()) as UIRowId
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
));
|
|
|
|
}
|
2022-01-27 17:51:37 +00:00
|
|
|
|
|
|
|
if (!srcColId) {
|
|
|
|
// This is a same-record link: copy getDefaultColValues from the source if possible
|
|
|
|
const getDefaultColValues = srcSection.linkingState()?.getDefaultColValues;
|
|
|
|
if (getDefaultColValues) {
|
|
|
|
this.getDefaultColValues = getDefaultColValues;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!this.getDefaultColValues) {
|
|
|
|
this.getDefaultColValues = () => {
|
|
|
|
if (!this.filterColValues) {
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
const {filters, operations} = this.filterColValues.peek();
|
|
|
|
return mapValues(
|
|
|
|
pickBy(filters, (value: any[], key: string) => value.length > 0 && key !== "id"),
|
|
|
|
(value, key) => operations[key] === "intersects" ? encodeObject(value) : value[0]
|
|
|
|
);
|
|
|
|
};
|
2021-08-26 11:39:17 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns a boolean indicating whether editing should be disabled in the destination section.
|
|
|
|
*/
|
|
|
|
public disableEditing(): boolean {
|
|
|
|
return Boolean(this.filterColValues) && this._srcSection.activeRowId() === 'new';
|
|
|
|
}
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
|
|
|
|
// Value for this.filterColValues filtering based on a single column
|
|
|
|
private _simpleFilter(
|
2023-07-07 08:54:01 +00:00
|
|
|
colId: string, operation: QueryOperation, valuesFunc: (rowId: UIRowId|null) => any[]
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
): ko.Computed<FilterColValues> {
|
|
|
|
return this.autoDispose(ko.computed(() => {
|
|
|
|
const srcRowId = this._srcSection.activeRowId();
|
2021-12-17 12:16:18 +00:00
|
|
|
if (srcRowId === null) {
|
|
|
|
console.warn("_simpleFilter activeRowId is null");
|
|
|
|
return { filters: {}, operations: {}};
|
|
|
|
}
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
const values = valuesFunc(srcRowId);
|
|
|
|
return {filters: {[colId]: values}, operations: {[colId]: operation}} as FilterColValues;
|
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Value for this.filterColValues based on the value in srcCol at the selected row
|
|
|
|
private _srcCellFilter(colId: string, operation: QueryOperation): ko.Computed<FilterColValues> | undefined {
|
|
|
|
const srcCellGetter = this._makeSrcCellGetter();
|
|
|
|
if (srcCellGetter) {
|
|
|
|
const isSrcRefList = isRefListType(this._srcCol.type());
|
|
|
|
return this._simpleFilter(colId, operation, rowId => {
|
|
|
|
const value = srcCellGetter(rowId);
|
|
|
|
if (isSrcRefList) {
|
|
|
|
if (isList(value)) {
|
|
|
|
return value.slice(1);
|
|
|
|
} else {
|
|
|
|
// The cell value is invalid, so the filter should be empty
|
|
|
|
return [];
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
return [value];
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-02-01 19:51:40 +00:00
|
|
|
// Value for this.filterColValues based on the values in srcSection.selectedRows
|
|
|
|
private _srcCustomFilter(colId: string, operation: QueryOperation): ko.Computed<FilterColValues> | undefined {
|
|
|
|
return this.autoDispose(ko.computed(() => {
|
|
|
|
const values = toKo(ko, this._srcSection.selectedRows)();
|
|
|
|
return {filters: {[colId]: values}, operations: {[colId]: operation}} as FilterColValues;
|
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
// Returns a function which returns the value of the cell
|
|
|
|
// in srcCol in the selected record of srcSection.
|
|
|
|
// Uses a row model to create a dependency on the cell's value,
|
|
|
|
// so changes to the cell value will notify observers
|
|
|
|
private _makeSrcCellGetter() {
|
|
|
|
const srcRowModel = this.autoDispose(this._srcTableModel.createFloatingRowModel()) as DataRowModel;
|
|
|
|
const srcCellObs = srcRowModel.cells[this._srcColId!];
|
|
|
|
// If no srcCellObs, linking is broken; do nothing. This shouldn't happen, but may happen
|
|
|
|
// transiently while the separate linking-related observables get updated.
|
|
|
|
if (!srcCellObs) {
|
|
|
|
return null;
|
|
|
|
}
|
2023-07-07 08:54:01 +00:00
|
|
|
return (rowId: UIRowId | null) => {
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
srcRowModel.assign(rowId);
|
2021-09-22 20:08:31 +00:00
|
|
|
if (rowId === 'new') {
|
|
|
|
return 'new';
|
|
|
|
}
|
(core) Add other direction of linking by reflist
Summary:
Allows selecting by a reflist in another table. This generalises cursor-linking with a ref column, but now it's filter linking.
Added another case to LinkingState where the source column is a reflist to the target table, filtering by the id column.
Updated convertQueryFromRefs and related functions to handle this since the id column has no column ref. In this case the string 'id' is used instead of a number.
LinkingState also checks if the source value is a reflist and uses that as the list of filter values instead of a single-element list of the cell value.
Indirect linking also works, where the source and target columns both are both references to the same table. This was the plan for a source reflist and target ref column.
I was surprised to see it also works perfectly when both columns are reflists, and it filters rows where there's an intersection!
Adding rows to the target section using the selected source record for default values is iffy. When filtering by row ID, there's no column for defaults, so the new row disappears.
For a source reflist and target ref, the first value of the reflist is the default, which is okayish. When both are reflists, the full source reflist is the default for the target column.
This seems like a bit much but just using the first value seems a bit arbitrary when there's room for all of them?
While doing all this I noticed an unrelated bug which I fixed as I was refactoring. Previously cursor linking based on a reference column did not update the cursor in the link target
when the value of the selected reference cell changed. Now cursor linking uses a floating row model like most other cases to observe the value correctly.
Test Plan: Extended SelectByRefList test and fixture, added previously failing test to RightPanelSelectBy.
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D3004
2021-08-30 13:29:39 +00:00
|
|
|
return srcCellObs();
|
|
|
|
};
|
|
|
|
}
|
2021-08-26 11:39:17 +00:00
|
|
|
}
|