Struct Session 

pub struct Session {
    pub config: Config,
    pub config_file: PathBuf,
    pub resolved: Option<Resolved>,
    pub render: Context,
    pub global: GlobalArgs,
}

Everything a command implementation needs, assembled once.

Fields

config: Config

config_file: PathBuf

Where config came from, so auth login can write back to it.

resolved: Option<Resolved>

render: Context

global: GlobalArgs

Implementations

impl Session

pub fn resolved(&self) -> Result<&Resolved, ConfigError>

The active profile, or an auth error explaining how to get one.

pub async fn client_for( &self, target: &str, ) -> Result<(Client, String), ExitCode>

Split a possibly profile-qualified target and build the client for it.

Queue keys are only unique inside an organisation: two profiles can both see a LMS, and LMS-12 then names two different issues. So the key decides the profile, in this order:

1. work/LMS-12 says which, and is always obeyed.
2. Otherwise the profile that can see queue LMS is used, even when it is not the default one. Sending the request to a profile known not to have the queue only produces a 403 that reads like a rights problem.
3. Two profiles in different organisations seeing one queue key is the genuinely ambiguous case, and is refused rather than guessed at.
4. A bare number is the issue’s number in the profile’s default queue. 42 and PROJ-42 then name the same issue, which is what somebody reading a board and typing a key by hand actually has in front of them. Without a default queue it is refused: there is nothing to complete it with, and a number is not a key.

pub async fn routed( &self, target: &str, ) -> Result<(Client, String, String), ExitCode>

Self::client_for, and the name of the profile that answered.

The name is what a person recognises; the organisation the client carries is what two profiles onto the same Tracker have in common. A command that has to remember something about “where this went” wants both.

pub fn announce(&self, resolved: &Resolved)

Say which profile and organisation this answer came from.

Once per run, on stderr. Every command says it, not only the writes: an answer from the wrong organisation looks exactly like an answer from the right one, and “which profile was that” should never be a question the output leaves open. stderr because stdout is the data channel.

pub fn client(&self) -> Result<Client, ExitCode>

Build an API client for the active profile.

Every failure on the way here — no profile, no stored token, a token the keychain will not release — is an auth problem from the caller’s point of view, and reports as one.

pub fn client_with(&self, resolved: &Resolved) -> Result<Client, ExitCode>

A client for a specific profile.

pub fn display(&self) -> Display

Display defaults for the active profile, or the built-in ones.

pub fn default_queue(&self) -> Option<&str>

The queue to act on when the command did not name one.

Trait Implementations

impl Debug for Session

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.