[BUG] mgt-todo doesn't support initial-id and target-id

[sebastienlevert]

It's currently impossible to programmatically set the task list ID we'd love to see automatically load. Both MgtTaskBase properties (initialId and targetId) are never used within the component.

[ghost]

Hello sebastienlevert, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[musale]

Hello @sebastienlevert, I have done some digging into this issue and I have findings I would like to discuss.

mgt-todo uses mgt-picker to load the task lists

This is a blocker because it utilizes the /me/to/lists endpoint.

microsoft-graph-toolkit/packages/mgt-components/src/components/mgt-todo/mgt-todo.ts

Lines 152 to 166 in e7efa21

	/**
	* Render the generic picker.
	*
	*/
	protected renderPicker() {
	return mgtHtml`
	<mgt-picker
	resource="me/todo/lists"
	scopes="tasks.read, tasks.readwrite"
	key-name="displayName"
	placeholder="Select a task list"
	></mgt-picker>
	`;
	}

This makes it a challenge to use either target-id or initial-id as per their documentation. My understanding is target-id will only show a single task list on the dropdown. The initial-id will have the specified id as the first task on the dropdown list.

microsoft-graph-toolkit/packages/mgt-components/src/components/mgt-tasks-base/mgt-tasks-base.ts

Lines 51 to 68 in e7efa21

	/**
	* if set, the component will only show tasks from the target list
	*
	* @type {string}
	*/
	@property({ attribute: 'target-id', type: String })
	public targetId: string;
	/**
	* if set, the component will first show tasks from this list
	*
	* @type {string}
	* @memberof MgtTodo
	*/
	@property({ attribute: 'initial-id', type: String })
	public initialId: string;

The task lists will always be loaded and displayed on the UI - even if we filter them out in the todo backend. Filtering in the todo backend is also impossible because mgt-picker is not accessible.

MgtTaskBase has an abstract renderPicker method

Another way to get access to the rendered task list would have been to manipulate the picker logic. However, this is done in the super class that is also used with mgt-tasks.

Recommendation

The documentation for the initial-id and target-id clearly show this is a bug. However, it cannot be fixed with the current updated state of the component.

One approach is to allow mgt-picker to take in a list of values to render. This way, we can load the required task lists and pass them to the mgt-picker for display manually:

<mgt-picker custom-list="[{id: 1, title: 'list item one'}]"></mgt-picker>

In our case, we filter out the task lists and remain with only one for target-id or set the initial-id as the first item on the list.

Another consideration should be de-coupling mgt-todo from MgtTaskBase. This should allow customization of behavior without affecting other components dependant on the super class.

What do you think? Cc @gavinbarron @Mnickii

[sebastienlevert]

Could we ignore target-id in this case? I don't think this is a scenario that we necessarily want in this case. What would be ideal would be to select the "initial" list to be selected, but allow users to move to other lists.

Something we could potentially think for target-id could be disable the picker and select the initial list. That would remove the ability to the user to change their choice and might be easier to work with the current picker implementation.

Thoughts?

[Mnickii]

Currently, mgt-picker just uses the response from mgt-get but the approach to allow mgt-picker to take in a list of values to render then load the required task lists and pass them to the mgt-picker for display manually could work.

As for decoupling mgt-todo from MgtTaskBase, I think this decision would depend on how the redesigned planner looks if we still plan to have all similar behavior in MgtTaskBase for both of them or have them decoupled.

@sebastienlevert another suggestion that could work is if we check for a target-id and if there's one, render tasks of the target-id, if there's none, render the current picker implementation?

[gavinbarron]

So, for target-id, if it's provided then we don't need to render the picker at all, we could just have a label with the list name rendered. Sure we need to load that target list during the loadState method, but that seems reasonably straightforward. This looks similar to what @Mnickii is suggesting.

With initial-id we can use the selected-value attribute of the mgt-picker to set the selected value. This will need some testing to ensure that the selectionChanged event is emitted to correctly trigger the state changes, or some other manipulation of the data loading behavior.

[musale]

Thank you all for your input on this. I have raised a PR that covers most of the suggestions raised, please review and advise on the PR.