Recently my firm acquired the Workiste solution (DMS) v9.3.2. It is connected to Outlook as a plugin.
To the left of Outlook, beneath the Inbox, Outbox, Deleted Items and other folders, there is a browser of this DMS, whose contracted label is FileSite.
Within FileSite there are the Documents in Checkout, Recent Documents and Recent Folders blocks.
Within the latter, there are all the 'workspaces' I've been getting via search.
However, many queries of these folder blocks (named 'workspaces') remain forever in the FileSite browser and therefore in Outlook.
I would like to keep only those 'workspaces' already searched and useful to me, those useful to my day-to-day, and not all those I search just take a peek, only.
The Worksite documentation is crappy on the web, so I did not find any information on how to clear the contents of the block called _Recent Folder (and if this is possible to do)
FileSite allows you to view recently accessed workspaces via the Recent Workspaces node. This is typically configured by you system administrator to show the last 10 or 20 workspaces that you accessed.
There is a corresponding My Workspaces node which will show you a list of workspaces that you are interested in, which may or may not be those same workspaces in your list of Recent Workspaces. To add to that list of My Workspaces simply right click any workspace (the reddish box icon that is the root of each workspace folder structure) and select Add to My Workspaces. Once you've done that a shortcut to that workspace will appear in your list of My Workspaces.
While the underlying workspace name typically won't be editable (usually because a company policy prohibits it) the shortcut is yours and you may rename it if you wish.
Also, in My Workspaces you may find that you want to logically group certain workspaces, perhaps because you're working on a set of related projects or matters. In that case you can right click on My Workspaces and select New..Category. A Category is merely a logical grouping of workspaces that is personal to you.
You can also make use of your My Favorites area to store shortcuts to workspaces and categorise them. The main difference between My Workspaces and My Favorites is that the latter allows you to add shortcuts to individual documents and even folders, not just workspaces.
In my experience, most people seem to find that My Workspaces gives them enough flexibility
Note that the My Workspaces and Recent Workspaces etc nodes are themselves configurable. That means your organization's administrator may have relabelled them, eg to My Matters and Recent Matters if you're a legal team, or My Projects and Recent Projects, etc. Also, you may have been restricted to only view certain nodes in FileSite
Your administrator or tech training team should be able to provide you with some comprehensive FileSite user guides that are produced by iManage in PDF format. Those guides provide much more detail
Related
Our company currently has about 10 active projects and 5 programmers.
My manager wants a weekly update on all open items, just a list of them.
I only need the list for our organization, not across multiple organizations.
I can see all open items assigned to me, but I cannot seem to figure out a way to see all open items across all projects.
Is there a way to do this without having to go to all 10 projects then manually compile this list?
It is looking like we have perhaps set stuff up less than optimally.
Is is perhaps better to use less projects and group work differently?
Joe
Hmmm...reading this:
When to add another project In general, we recommend that you use a single project to support your organization or enterprise. A single
project minimizes the maintenance of administrative tasks and allows
full flexibility to cross-link objects.
from: https://learn.microsoft.com/en-us/vsts/organizations/projects/about-projects?view=vsts&tabs=new-nav
makes me think we may have setup or organization wrong. It would have been great if this was made a bit clearer in the documentation. This is the first I have seen this.
You can use a query and check the "Query across projects" checkbox:
For example, this query give you all the bugs in all projects with state "In Progress":
You can save the query and display the results on the dashboard or export to Excel with this extension.
I have a big problem. One of my coworkers left the company yesterday and one of his projects went into my hands. We work for a company which set up a TFS for us to work together on one big project. He accessed the TFS by using his LiveID. When he left yesterday, he hasn't checked in his new/updated items and I forgot to do it today before I disconnected him and logged in with my account.
So basically I still have the updated solution on my local hard disk. But since my workspace is mapped to another folder, it actually downloaded old versions of our code files.
How can I copy the updated, not-checked-in items into my local workspace folder and check them in?
UPDATE: I have tried changing the local workspace folder by going to File --> Source Control --> Workspaces but I get another error telling me that the folder I'm trying to map (the one used by my ex-coworker) belongs to somebody else.
The easy way would be to log in as him, but a it is a Microsoft ID rather than an AD account you are kind of scuppered there. You o however have the files from disk. If you copy the files from his workspace and drop them over the top of your workspace TFS will detect the adds and edits for you. You will then have to go through and look for any deletes yourself..
a...make sure it builds, run all your unit tests, and then check in.
I have a complicated system of folders and I need to share 2nd and 3rd level folders with certain groups of users while maintaining the full path to the folder.
Is this possible? I tried but without success as if I share a folder eg. Project 1->Administration with the "Group Administration" on the client I only see the Administration folder and I need, instead, to replicate the entire structure.
Thanks for the support
With the current ownCloud sharing implementation this is simply not possible. Every shared item appears directly in the "Shared" folder of the user the file/folder is shared with.
Update: At the moment ownCloud (and I guess also nextCloud) allow a user to move around and rename files/folders shared with them. So even if you could enforce a certain structure on your users, they could always change it afterwards.
You could always report a feature request for it (or maybe there even already is one) here: https://github.com/owncloud/core/issues/ .
Context: I'm currently working as an intern at a company which has made the move to TFS 2010 from VSS. TFS has been in use here for a couple of months now, but in the early period after the move some 'mistakes' were made in setting up the projects. After while the need for a custom team project template was recognized. The template has been developed and is now being introduced into the organisation. (small web development company, many small projects)
Question:
We're trying to migrate old projects to the new template by setting up new pojects with the custom template. We'd like to move the sources of the old projects into projects making use of the new template. The history of the sources should be preserved for support reasons. It is undesireable for the old projects to appear in the Team Collections' Team Projects list, so we'd like to hide them if deletion is not an option. (to reduce the garbage in the list)
I have some solutions on my mind to get the job done, but I'm unsure if they'll work out. (even after spending some time researching the issue on the web)
1: Doing a branch from the old project into the new and then deleting the old project. I think it should keep the history of the the old project has been deleted. Some people over here are very vocal about this not being the case causing some strife. Before pushing this option I'd like to be sure this will work
2: Hijack the migration tool to migrate sources between projects (possibly via via a temporary Team Collection). I have read this could be an option, but the details of how to execute such a move are still unclear to me. It seems this has a lot of caveats attached to it and can be cumbersome to execute. (I'm no superman when it come to these matters, but so is noone else over here)
The Migration guide seems to suggest that this might be possible, but I can't determine if this scenario is supported, and how to recover if things go wrong.
Maybe it is possible to set up the new projects and hide the old projects from the team collections' team projects list without deleting them? (I wonder if there is some kind of inactive setting for team projects, I can't seem to find any such option after exploring the tfsconfig tool of the admin console)
An explanation of how to best apporach this problem and possible solutions would be much appreaciated.
Doing a branch from the old project
into the new and then deleting the old
project. I think it should keep the
history of the the old project has
been deleted.
I'm pretty sure if the old team project is deleted, the part of history that is associated with that team project will also be gone, see here for more details. You can confirm this by doing a quick test move if you want.
Maybe it is possible to set up the new
projects and hide the old projects
from the team collections' team
projects list without deleting them?
You can mostly achieve this by denying read access (GenericRead) to most of the users on the old team projects. Of course for the Project Collection Administrators who have this permission by default on all the team projects, the old team projects still appear in the list for them.
Good luck!
There is no firm relationship between a team project and a particular part of the source control tree. Let's say you have a team project named "Mistake". You have source at "$/Mistake". You can now create a new team project named "Got It Right", and specify to use the sources at "$/Mistake".
Use the source control explorer to move a solution between projects. Here is how the projects and solutions appear before moving a solution.
The move selection is found by either
right-clicking the solution, choosing Move from the drop-down menu
Selecting Move from the Source Control menu found under File in the drop down menu
In VS, it's simple. Everything the project needs is stored in the project folder and all VS settings are stored in one place. Eclipse, however, stores Eclipse settings with the project and keeps a .metadata at the workspace level which is needed to detect the projects in the workspace. Thus, I can't simply branch a project and then open it in Eclipse. I need to set up a workspace, branch it into that workspace, copy over all my workspace settings (settings import/export doesn't even work right in Eclipse) so I have the same Eclipse settings, then do some kind of import to get the project in the workspace. This is what I generally refer to as a pain in the freaking neck, and it causes me to not branch any Java projects and to keep them all in one folder. This is also a pain.
Is there any way I can get a setup where I can just branch a project and open it in Eclipse, while maintaining the same Eclipse settings?
UPDATE: The current state of the question is expressed by the comment to soru's post.
Pretty sure you want to:
Keep the same workspace for all projects (or maybe a few, at the level of say 'hobby' and 'work').
switch between different branches in the same project by using the features of your version control tool/plugin
if you want to work on multiple branches at the same time, just create two projects, and manage them both as above.
if you want to temporarily hide the inactive version, use the 'working set' feature.
The main limitation is that you might want to have projects with the same name, but you can't. So sometimes you have to make up a project name different from the underlying folder name.
In general, mapping between VS and Eclipse:
Installation <-> workspace
Solution <-> working set
Project <-> project or folder or VC system branch or working set node
Refs:
VS object model
using working sets in Eclipse
working with branches in subclipe
Well, I'm not a fan of keeping any IDE specific settings in the repo, but when I do I keep only .project, .classpath and .settings.
You can also keep you settings at the workspace level (Windows->Preferences),and not on the project level (Project->Properties).
Also why do you create a seperate workspace for branches? You can keep it in one workspace, no need to create another one.
You could also use "switch" in subversion (I don't know if that's what you are using, but other revision systems should have something similar) and go to the branch you have created.
(of course if you wan to work concurrently on more than one branch then it doesn't help)
I can't speak to the Eclispe problem, as i'm only a n00b user, but I can speak to the secondary question.
I've been working in systems for a number of years that ended up needing to have various branches of the same code done for a variety of reasons.
One of the best reasons for keeping specific settings in project-specific locations is that so the various compiler / sdk / etc. settings & files can be specific per-branch and not collide between branches.
This allows, for example, for the work to upgrade a code set to a newer sdk/compiler to be done without impacting the ability to work on the existing "main line" code set with the previous sdk/compiler should the need arise.
In my experience in the computer game industry as a core technology wog, this happens a LOT.
I'm sure the same situations occur outside the computer game industry, maybe just not at the same pace.