You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ability to control which project is automatically selected based on a set of simple criteria rather than per integration or per exact URL.
What I imagine would be a list of URL matching patterns like *.github.com/zeel01/* or trac.mycompany.com/* that can be assigned to specific projects. Rather than relying on matching an existing project exactly, or building features around specific integrations like #264, this feature would allow for user-defined matching. This wouldn't work for every service since some don't have nice clean URLs, but it would work for many include some of the most popular ones. There are of course a wide variety of ways that the extension could identify a page, and many of these could be presented to the user in an easy to use way.
Additional options could include:
URL pattern matching (as above)
Page title pattern matching
Specific CSS selector matching
Element text content pattern matching
Element style matching (is it red or blue?)
Full regular expression matching
With just a handful of matching options such as these, even non-technical users could fairly easily configure the extension for most integrations to function as their needs demand.
How does this help you?
At the moment there's a lot of extra user input required after starting a timer even with an integration, because most of the time the project selection isn't going to really make sense. For ticketing/issue systems like Github, Gitlab, Trac, Jira, etc you are highly unlikely to create a "project" in Toggl for every ticket, rather certain tickets might belong to certain projects, or might just belong to one "Tickets" project that belongs to a specific client. Rather than setting one top-level default for a service, or the opaque remembering of the last project used on a particular page, this feature would allow a highly flexible means of identifying pages and assigning them to the correct project thus reducing the need for user input.
A few examples:
I have a default project for my day job, that just ensures that miscellaneous tasks are assigned to the correct client. For integrations like Outlook this is the task I would use. For this the integration-specific option is fine.
My company has a Github organization, if I start a tracker from there I want the time tracked for the company. With the URL based matching, this would be trivial for me to configure.
I have a personal Github account, if I start tracking from a repo I own, I want the default to be a different project which is assigned to the client "personal" in my Toggl account. Again with URL matches, trivial.
I have certain personal repos that I track time for individually, with a more specific pattern I could match to those repos.
My company has a Trac ticketing system. The text in .trac-type a would indicate the appropriate project to assign a time entry to.
If we couldn't add this feature, is there a compromise you can think of?
The most compromised version of this feature would be only to support URL matching, or even only support URL prefix/suffix rather than patterns. I don't think there is a more minimal version of this feature.
However, I believe I can achieve my goals by editing the relevant integrations myself. But that would be a lot more work to configure and debug, and to modify in the future, compared to this proposal. And that's only an accessible option because I'm a developer, most users will not be able to do this.
Edit: Or not, looks like that feature is no longer supported #2187#2245
The text was updated successfully, but these errors were encountered:
Describe the new feature
The ability to control which project is automatically selected based on a set of simple criteria rather than per integration or per exact URL.
What I imagine would be a list of URL matching patterns like
*.github.com/zeel01/*
ortrac.mycompany.com/*
that can be assigned to specific projects. Rather than relying on matching an existing project exactly, or building features around specific integrations like #264, this feature would allow for user-defined matching. This wouldn't work for every service since some don't have nice clean URLs, but it would work for many include some of the most popular ones. There are of course a wide variety of ways that the extension could identify a page, and many of these could be presented to the user in an easy to use way.Additional options could include:
With just a handful of matching options such as these, even non-technical users could fairly easily configure the extension for most integrations to function as their needs demand.
How does this help you?
At the moment there's a lot of extra user input required after starting a timer even with an integration, because most of the time the project selection isn't going to really make sense. For ticketing/issue systems like Github, Gitlab, Trac, Jira, etc you are highly unlikely to create a "project" in Toggl for every ticket, rather certain tickets might belong to certain projects, or might just belong to one "Tickets" project that belongs to a specific client. Rather than setting one top-level default for a service, or the opaque remembering of the last project used on a particular page, this feature would allow a highly flexible means of identifying pages and assigning them to the correct project thus reducing the need for user input.
A few examples:
.trac-type a
would indicate the appropriate project to assign a time entry to.If we couldn't add this feature, is there a compromise you can think of?
The most compromised version of this feature would be only to support URL matching, or even only support URL prefix/suffix rather than patterns. I don't think there is a more minimal version of this feature.
However, I believe I can achieve my goals by editing the relevant integrations myself. But that would be a lot more work to configure and debug, and to modify in the future, compared to this proposal. And that's only an accessible option because I'm a developer, most users will not be able to do this.Edit: Or not, looks like that feature is no longer supported #2187 #2245
The text was updated successfully, but these errors were encountered: