I am using iManage worksite 9 and there are multiple workspaces which has been created using workspace creation. Now, most of the workspaces are having Public access while others are Private. I need to convert that Public workspaces to Private workspace which I can do manually one by one but I want to do all at once. Is there any way or script which I can use for the conversion. Any suggestions?
Thanks in Advance!
iManage Worksite : 9.0
iManage Filesite : 9.0 update 6
I'm not sure if it's still relevant, but you could use a tool like 'Prosperoware Milan Helpdesk' which makes WorkSite administration much easier and lets you modify many workspaces at once.
Another solution would be to run a SQL query that updates the 'default security' attribute in either DOCMASTER or PROJECTS table (I don't remember which one exactly). You would have to update the LASTEDITED date for the indexer to pick up the change and reindex workspaces' contents.
Related
I maintain an SVN repository that has code dating back 9 years. This repo contains code for hundreds of applications in it, many of which are obsolete. The back-end is VisualSVN Server running on a Windows server and the client used is TortoiseSVN with CLI tools.
We are now prepping to migrate to a different SCM application and I need to export only the applications which have been updated in since January 1, 2021 (just under 40K revisions). If I only needed to export simply the artifacts that had been changed since that date, it would be simple. But instead, I need to export any project that contains any file (no matter how far down the tree) that has been created or modified since that date.
Note that while tags created after the cut-off date will be migrated (to make audits simpler), these should not be considered when deciding what is active or not.
I have no qualms making this a multi-step process (identifying active project root folders and putting them into a changelist, then exporting just those folders, but I'd prefer a single command solution if I can manage it. While Unix OS (like grep) commands are potentially possible, I'd prefer to stick to Windows OS commands (like findstr) if at all possible.
Things I want to avoid at all costs:
checking out the entire repo
considering anything in any of the thousands of /tags/ folders (active branches are fine)
I had started out trying
svn diff --summarize -r{2021-01-01}:HEAD https://Url.To/Repo/
but after it had been running a while, I realized that it was trying to look at all of the /tags/ and would likely end up taking a week or more to finish.
I've also looked at ls -r -verbose and log commands but neither seems to give me what I need.
Can anyone help come up with either the single or the two-step (or more) commands? I don't mind it taking several hours to run (or even overnight), but when we do the final migration, I can't take the SCM offline for more than one weekend, including the import on the other side. As a worst case, I can search the repo for all instances of /trunk/ (this would be the root of each project), and then loop through that output. Is there a cleaner/more elegant way to do this?
In testing an upgrade to our Postgres database, we've discovered that one of our oldest versioned migration files is no longer valid SQL. This isn't an issue for the production database which (of course) has those migrations already in the schema_history_table, but standing up any new sandboxes is now made impossible by this broken V file.
What's the best way to bring an old V file into the modern world without forever orphaning our production database?
Of the top of my head I can think of a few possible options.
Configure postgres to enable previous version compatibility. I'm no expert at this, but I think there are some options here.
Just modify the historic migration scripts to they now work with the new version. This will mean that you can't stand up old versions any longer, but does this matter to you? I think that you'll need to run flyway repair after you do this, as Flyway will detect that the files have been tampered with.
Create a parallel set of scripts, one for each version, putting them in different folders. Then use the flyway.locations option to specify different folders depending on the version of the target.
We are in process of upgrading Sitecore 6.6 to 7.2. Part of upgrade is to migrate all the media items from 6.6 to 7.2.
I tried creating a package but the package size is too large and times out on package installation.
I found link below using Powershell Console where it shows copy-item command:
http://blog.najmanowicz.com/2011/11/18/sample-scripts-for-sitecore-powershell-console
I attached the 6.6 to 7.2 version where I can access the 6.6 DB. However copy-item doesn't seem to support different databases.
Could someone please help how I can use SiteCore Powershell or similar to migrate media items from 6.6 to 7.2?
I had a similar issue with a (very large) media library with a similar migration. Packages seems to bomb out around the 2GB mark, instead serialize the items:
Delete everything from /Data/Serialization
Open the media library. Makes sure you have the Developer tab
showing (right click somewhere on the toolbar and enable it
otherwise)
Select your root media item then Serialize Tree
Wait...
Copy the serialized files from /Data/Serialization to your new
server
From the toolbar select Update or Revert Tree depending on your requirements
Profit.
You can find more info in the Sitecore Serialization Guide and this post by Brian Pedersen
You should be able to do this in Powershell too (from my understanding). You need to:
Add the database to your connectionString.config
Add that database to your web.config to <sitecore><databases><database>. You can copy the existing master node and rename the id attribute to match your conneciton name
Your legacy database should now be connected to Sitecore interface, you can check it is present in the database selector list from the right of the desktop
The powershell command now needs a "from" and "to" location. Assume your database is called "legacy_master", the following should work:
copy-item "master:\media library\*" "legacy_master:\media library\"
I've found Hedgehog TDS (and sometimes Razl) quite useful for doing this.
Create a new TDS project (don't version control it), and download all the items you need to your local machine. You can for example connect the "Debug" build to your source 6.6 instance, and a "Release" build to your target 7.2 instance. Then you can just synchronize the items to your target machine. It's sometimes good to synchronize one or a few branches at a time if you have long latency connections.
The good thing about this is that you're in total control of your content and can see what fields are updated etc. During an update process, it's sometimes useful to compare other parts of the db as well, just to ensure you don't miss any changes you've made to the platform.
Since I mentioned Razl as well: I've found Razl quite good if you have a whole branch that you know should be transferred from one db to another (such as the case you describe). TDS is a bit slower, but more universal - and you may have a TDS license already so it may not be worth an additional Razl license.
I've just added item transfer from one DB to another so you can Copy-item between databases starting with Sitecore PowerShell Extensions 3.0. Thanks for the great idea!
Just to add another option you can perform tasks like this using Revolver.
WARNING: Try this in a test environment first
if we assume that:
the context item is the media library item
the current database is master
the target database is called master72
then something like this should work:
cp -r -n master72/sitecore/
I have a smallish utility library I made that I had created in TFS Beta 2 to test out TFS. I now have TFS rc1 installed(and Beta 2 uninstalled) and am trying to add my Solution to TFS.
I get an error saying that it is already bound to my old TFS, which was on a different system then this one. Strangely, when I go into Source Control and look at the bindings it says there aren't any. Also, I manually deleted the .vss and .vsc files and it still does it.
Ideas? I looked through the numerous other SO topics related to this but unless I missed one none of them are dealing with my issue.
Ideas?
Grab the TFS Sidekicks from Attrice. They have a workspace sidekick, you can pretty quickly find your old machine and unbind/delete that workspace from TFS.
Once you install:
VS Menu Bar
Tools
Team Foundation Sidekicks
Workspace Sidekick
Owner will defult to you, just clear machine name
Search
Select old workspace, click the red X to delete
I had old server entries too and I fixed it by using the workspace sidekick mentioned here and then using the command line to get the rest that the tool couldn't find.
Someone left the organisation but before leaving, he locked all the files for an unknown reason.
How do you unlock them all so that the other developers can work?
For the following operation, you will need to be either a project administrator for the project you want to undo the check-in on or a Team Foundation Administrator if you want to do this across all projects.
If you still have the username of the person, you can simply do something like this:
Open up Visual Studio command prompt (Start -> Programs -> Microsoft Visual Studio 200X -> Visual Studio Tools -> Visual Studio 200X Command Prompt)
Run the following command:
tf lock /lock:none
/workspace:WorkspaceName;USERNAME
/recursive $/
To get the list of workspaces for a user, just run the following command from the same prompt:
tf workspaces /owner:username
For more commands, check tf /?
If the developer has left the organization, then the best thing to do is to delete their workspaces. This will unlock the files for you but also free up some resources on the server.
See the following blog post I did on the topic when it happened to me a few years ago.
http://www.woodwardweb.com/vsts/unlocking_files.html
You can either delete the workspace using the command line (tf.exe) or you can use the excellent TFS Sidekicks from Attrice.
This was the only way I resolved this, which involved deleting the user's workspace.
If the error message says "The item $/... is locked for check-out by someUser:1 in workspace someMachine123." then I use the command:
tf workspace /delete /server:http://machinename:8080/tfs/DefaultCollection someMachine123;someUser:1
There is just a single space between the collection URL and someMachine123;someUser:1.
Note that I payed attention to the fact that the error message mentioned the user as someUser:1, so I mimicked that in the command. It was not enough to just run the command with someUser only. I'm not sure what the :1 is all about but point being, mimick the error message.
Note the server has to be the fully qualified collection path, which you can find by going to Team Foundation Server Administration Console->Application Tier->Team Project Collections, the bottom pane will show a URL for the collection that is selected in the upper pane.
I also had a problem because I accidentally tried to use plural workspaces instead of just workspace because there is a similar command that is plural.
first you need to have the right to do this. If you have that the easiest is to use TFS sidekicks from attrice http://www.attrice.info/cm/tfs/
Here's an explanation of using TFS permissions.
Having the "Unlock other user's changes"
permission set to Allow is required to
remove a lock held by another user.
I needed to add /collection:collectionURL otherwise the workspace could not be found:
List item
tf loc /lock:none /workspace:WorkspaceName;UserName /collection:collectionURL
Have a system administrator reset that users password, log on as that user, unlock all files...
I would think this is the solution to almost all 'someone who is no longer at this organization' questions...
It is better to delete the workspace of that user from the server. example
tf workspace /delete /server:your_tfs_server workspace;username
Sometimes this is masking an different problem with a completely different application is locked by another user, but you cannot even create a New Folder for the new project you wish to merge into ( target won't allow the creation and incorrectly stating that someone has a file locked in their name) but then you dig deeper and another project is the culprit.
So a completely different project can be the problem with it having files locked by someone else.
Method that worked for me, my account has administrator permission on TFS and project :
In Visual studio 2015:
Go to Team Explorer
Click right on your solution and choose Open in source control
exporer
On left side click right on your solution
Choose Advanced
Choose Lock...
On left side click right on your solution
Choose Advanced
Choose Unlock (Now you can choose unlock)
Right now, every dev can easily commit his changes :)
by using TFS permissions,
Open up Visual Studio command prompt,Run the following command:
tf undo /workspace:workspaceName;DomainName\UserName $/file path in your solution
Use this solution as the very last resort.
I’m using TFS 2012. I went to the TFS database and ran the following queries. And it worked! Of course be very careful when messing with the database, take backups, etc.
The database is called Tfs_<<your_TFS_collection_name>>. Ignore the Tfs_Configuration MSSQL database. I'm not sure but if you don't have a Tfs_<<your_TFS_collection_name>> database, settings might be in the Tfs_DefaultCollection database. Locks are stored in tbl_PendingChange.LockStatus.
/*Find correct row*/
SELECT LockStatus, PendingChangeId, *
FROM tbl_PendingChange
WHERE TargetServerItem like '%<<fileName>>%'
/*Set lock status to NULL (mine was set to 2 initially)*/
UPDATE tbl_PendingChange SET LockStatus = NULL WHERE
TargetServerItem like '%<fileName>>%'
AND PendingChangeId = <<PendingChangeId from above>>