Tiago Guedes

Hey, @copasetickid. Yes, I'm still looking for someone willing to bring support for this feature. Let me know if you want to do so and if you need any help...

@copasetickid I haven't work on a plan for that yet. Actually, the last iterations I had here were all regarding minor fixes and improvements. Since I will be done with...

Sorry for not answering in time, @guy-simplee. I went through hard days last week, but as soon as I get some free time, I'll check this issue in order to...

I think it's definitely worth revisiting it, @seanabrahams. Since I'm currently working on a few improvements for the gem I may come up with a solution for this issue soon.

Yes, initially the idea was to let the cache implementation to be a developer's choice. But I will reconsider this point since caching usually is not related to the app's...

Making this helper method safe seems like a good idea for me and I will sure work on a refactoring asap. Anyway, I'm curious on how you came to reach...

Hey there, @KidA001! It's happening because you didn't defined `projects` as a relationship of `project_toolbox_talks`. Then you just need to add the following line to `ProjectToolboxTalkResource `: ```ruby has_many :projects...

Well, for this feature in specific I think we'd rather to avoid another duck typing since all error objects are already expected to quack like the `#errors` method. Thus, to...

Thanks for the feedback, @supremebeing7. It seems to me that there's a lack of documentation for this kind of use case at `README.md`, then I'll keep this issue open until...

Actually, with your last comment in mind, there's something we could work around: what about to configure (white list) the error classes the helper should work by default? For example,...