Workspaces Forum

1. Currently each ::Tasks instance has its own list of views, there is no way to share that between instances. When you shared it, you made it available to the other users of that instance. 2. Yes, grid style is not a part of the view. No big reason for this, just our call. Generally we wanted views to be stored for different sorting/organizing tasks, while custom styles should be global. 3. No, currently nothing is shared between ::Tasks instances and/or workspaces. We do see some need for improvement here, as e.g. email notifications are annoying without proper sharing. So, in (unspecified) future we'll add better settings sharing. 4. Indeed, status (and not only status) of parent will be updated after child's changes. That is not implemented currently, although on our todo list for long time. We have some idea for the rule engine which should manage this, but that will probably be implemented in next major upgrade to ::Tasks (which is not scheduled now). Thanks for feedback, we're glad that you like it ;) I hope you'll like the new features which will become available soon, they will greatly improve usefullness of the platform.

Good idea! Thanks... I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

> Enabled auto synchronization feature Eric and I were going over the weekly tasks in the boardroom. We were both updating the same Tasks list and it was so cool seeing each other's updates appear as we worked. Very nice! Adding others as a watcher is a Godsend, and Eric says thank you for allowing comments to be sorted how he wants. Lovin' it!!

Thanks for suggestions. Points 2 and 4 are already on our TODO list. That list is overwhelmingly long, though, as we have tons of awesome ideas we'd like to implement ;) But those points are on our radar and most likely will be implemented sooner than later. Point 1 is implemented currently in very simple/minimalistic way now. E.g. each workspace might have plaintext description (you can change it in workspace settings, available through that gear icon on workspace homepage). Also, readme.md will be displayed by default, if present, on visiting source code repository. These are just small steps toward what you've described. Some bigger steps were considered by us in the past, but so far we didn't managed to define them in an elegant/useful way, so they are pending as well. The request to join is interesting idea, we'll definitely consider it. I don't think it was in our plans before. Thanks.

All write operations are authorized by your username/password. So, nobody can write to your code repository without your approval. I.e. in order to be able to write to your repo, user either need to know your password and be logged in as you, or you need to share workspace with him first. The content, however, is annotated and contains info who created it. Those annotations are strings only, you can enter any strings you want, use non-existing email, whatever. It is pretty identical on GitHub and other git hosting platforms. Git does that to embrace distributed nature of teams. One person may fetch repo to local drive, then work on it. Synchronize it with other team members, and merge their work in. Then, upload it back to repository hosted by CodeProject. After such operation, each commit will correctly display its respective author.

Sound good - waiting to see :)

Let me know if there is something to play with, I'd like to do some extensions for VS... :)

Not sure if its the right way - just given the fact its the first time I saw it, and made an assumption, whereas you guys developed it ..... user Vs dev perspective :cool: