I think the search feature in the Workspace Explorer could benefit from being able to reason about file paths.

Two examples in which productivity would be boosted:

1) I have many config.ini files. If I search for "config.ini", I will find too many results. So I may want to search "MyFolder/config.ini".

2) I have a full path for a file. I want to inspect the history of this file, so I just want to quickly jump to it in the Workspace Explorer. To do that, I would like to just copy paste the full path of the file in the search bar, and immediately find the file. This is similar to the workflow in P4V.

This would reduce the amount of manual permissions work massively, as I feel I am battling the hierarchical system all of the time to allow things to be enabled properly.

An example of this is when I'm trying to give access to just one branch.

At the moment, giving the repository read / view access (which is required for setting up the repository) then enables that read / view permission for every branch. I then need to manually go through each branch, disable the read and view access and repeat.

This persists down to the folders also, where we need to limit some members of the team to certain submission folders.

A whole lot of manual permissions work could be avoided by separating repository read / view permissions.

This is a major bug in your product and it literally stopped our team to switch from git to plastic scm. I was trying out your product for the first time and after creating a project I invited my colleague to work together with me and she was not able to join my server. She was also checking out plastic scm and she did not join organization but instead created one. Later she was not able to join my organizaton even after several attempts. She tried to logout but she couldn't because that feature was not present in the GUI. She tried uninstalling nd reinstalling but still she was logged in. Finally she lost hope. You must definitely add an feature to logout and login from the windows application and also fix the joining organization after skipping it in login page.

(The following text is specifically about read-only xlinks. I am not sure if it applies to writable xlinks as wel.)

When I use Plastic, I expect that the contents of an xlinked folder in my workspace is updated at the same time that the xlink itself is updated. Plastic currently requires me to perform a workspace update to download the changes. Me - and everyone else on my team - find this behaviour counterintuitive. I would like to see the following changes in behaviour:

1. When I create or modify an xlink, I would like that Plastic update the xlinked folder contents immediately, rather than require me to create/modify the xlink locally, check it in, and then update the workspace.

2. When I receive an xlink modification as part of merging from another branch to my current branch, I would like that Plastic update the xlinked folder contents immediately, instead of waiting for me to click "Update Workspace".

Reason for change 1: The need to check in the xlink before receiving the new files locally makes it impossible for me to verify the consistency of parent repository + xlinked repo together before checking in.

Reason for change 2: The need to click "Update Workspace" to update the xlinked folder contents means that the "merge from branch X" operation in the UI does not actually guarantee that my workspace includes the changes from the other branch; merge + update is necessary, but only in situations where xlink changes are part of the merge.

Change 2 also means that I can freely choose how I introduce or modify a new code module that most of the team wants to maintain as a separate entity: either by duplicating the code module's files into the current repository, or by xlinking to another repository containing the module. Without change 2, there is a hidden cost to using an xlink: Everyone else on the team that has a work branch in flight will need to click "Update Workspace" after they have merged my in my changes to a work branch, or else it will appear to them that some source files are missing / out-of-date related to my changes. They do not care that I happened to use an xlink, they just expect that after a merge, their workspace is up-to-date (like it is in 99% of cases when merges do not include any xlink changes).