I assigned myself as a reviewer, but if someone wants it more, feel free to reassign.
Circling back to the topic of whether projects could replace accounts in Huly:
Based on the testing I’ve done so far, it looks like that won’t be necessary.
We can build on existing Classes and enums to add Account and Account category fields to issues.
I’m out of time for today but I’ll post a screen recording of how it works here soon.
Here is a screencast showing how to replicate Tempo accounts in Huly:
As I mention towards the end of the video, what the platform is currently lacking is support for showing time-based reports about time logged against a set of tasks.
Someone from the community asked about that here: Time sheet or time reporting · Issue #6357 · hcengineering/platform · GitHub
The Enum system is quite powerful, but also a bit limiting. I think it would be nice if we could further map each account itself as billable, non billable etc instead of having that be two fields in each ticket. For that I think it would be a good if we can consider having Accounts be an object like Company or Issue so that if needed we could add an account type Enum to an account for our specific categorisation.
@kshitij That would be a great solution, too How would we extend the set of existing classes, is that something that can be done at configuration level when setting up a self-hosted instance of Huly? (Maybe I’m missing something, but I just double-checked and couldn’t seem to find an option for adding a new class via the UI.)
I don’t know yet, if it’s possible with just config. If we can do it with just config that would be great. However, I’m proposing that we look into adding this feature because I feel over time it’ll probably justify the cost of implementation.
@kshitij Agreed It would probably end up helping with a bunch of other use cases that we’re not even thinking of right now
Just wanted to post here that I’ve completed the orientation guide for Huly. It won’t answer everything, but it should save you hours of time getting started.
@tikr It seems Huly has recently added a feature called “Cards” that could solve this issue for us. It’s worth checking out here.
It essentially allows you to create custom data types, and objects of that data type.
For instance, we could create an “Account” type with properties like name, and description, and add a reference to the company it belongs to, and an “Account type” enum. Right now, I don’t see a way to reference this new card type from an issue, but I’m hoping that will be a future enhancement. Or maybe I’ve just missed something.
@kshitij Looks promising! I played around with it a bit, too, and couldn’t figure out a way to link a card to an issue either. Might be worth opening an issue for that feature to figure out if it’s something they’re planning to add?
I watched the relevant videos and this is part of their new “process” module that is also supposed to bring support for sprints etc, so I think this is just the first step in that direction.
I’ll keep a look out of this and update here when I know more.
Huly has just released their roadmap and from I understand they are looking to make “Cards” the foundational data-type for all content, so that issues, and epics etc. all could be implemented that way. In that case, links between accounts and issues would just be links between two card types.
They are now working on “Processes” which is their mechanism for supporting sprints or other processes for managing tasks. It seems to be what they are working on right now for release in this quarter, so it might be ready before we need to work on it at all.
Just an update here. We’ve completed a discovery on the self-hosting element of getting Huly running and the results are here.
At the moment we’re now waiting on ArgoCD to be added to our infrastructure so that we can deploy it using the included Kubernetes manifests in a maintainable way. The main ticket for tracking ArgoCD’s addition is available here.