I have two accounts: account_1 and account_2 with two different e-mails, mail_1 and mail_2, respectively (both the accounts are backed-up, there is no concern of work loss).
I am a part of Team_X with account_1 and mail_1, but I am told to be a part of Team_X with account_2 & mail_2.
Does, renaming account_1 to account_old and renaming account_2 to account_1 suffice the requirement?
Or, do I have to additionally change my primary mail address from mail_1 to mail_2 too?
Or, are there any other steps that you can perform?
The best way would be ask the Team manager or concerned person to remove your old account from Team_X and add new new one. This will impact your work and commit history, You new user id will be shown for new commits.
another better way would be just remove your mail_1 from account_1 and mail_2 from account_2 and attach the mail_2 to account_1. Now you can change your username from account_1 to account_2.
There are repercussion of doing these things.
Like After changing your username, your old username becomes available
for anyone else to claim. If the new owner of your old username creates a repository
with the same name as your repository, that will override the redirect
entry and your redirect will stop working.
So deal it with precautions.
Related
I'd like to change my Candy Machine from having hidden settings to no longer be hidden.
Initially, the Candy Machine is created with hidden settings like these:
hiddenSettings: {
name: "Name",
uri: "uri..."
hash: '44kiGWWsSgdqPMvmqYgTS78Mx2BKCWzd',
}
I have attempted updating the candy machine to set the value of hidden settings to null, but this does not change any of the NFTs' metadata or seem to do anything at all.
Is there a way to unhide the assets after initializing them to have hiddenSettings?
Very late but answering for others who may have the same question...
Unfortunately it's not that simple. The "hidden" settings for a candy machine determines how the NFTs are uploaded. With it set, all NFTs will be uploaded with the same URI - the placeholder image and metadata.
Once an NFT is uploaded and minted, the candy machine does not control its metadata. Even if you could remove the "hidden settings" field, this would not reveal your NFTs. In fact you need to keep the hidden settings (in particular the hash) for a reason listed below. Instead, you need to update the NFTs themselves, setting the new URI to the actual metadata file.
The tool which makes this easier is Metaboss. It that can explore the blockchain and make changes for you. In particular, you can find the mint accounts of the NFTs which have been minted, and update the URIs. Updating will require your keypair for the wallet with the update authority for the collection.
After installing Metaboss, the command
metaboss snapshot mints -c [YourCandyMachineAddress] --v2
will output an array of the mint accounts to ./[YourCandyMachineAddress]_mint_accounts.json
You can change the output destination with the -o flag. Then for a given NFT you can find the metadata using
metaboss decode mint -a [MintAddress]
which will output the metadata to ./[MintAddress]. Again the output destination can be changed. You will see that this metadata has the URI of your placeholder. The name field, like "SomeCollection #1", identifies which NFT this is. By changing the URI to the actual URI for that NFT, you reveal it. Then wallet and marketplace apps will see the real NFT. You can do this with
metaboss update uri -k [/path/to/keypair.json] -a [MintAddress] -u [https://somestorage.com/realurifornft1]
All these commands have good nested documentation with --help. Obviously doing this manually for a large collection is very impractical. I have uploaded a bash script for this here. Read the script for usage info.
Now you may be thinking "isn't editing the NFT metadata like this shady? Couldn't someone use this to maliciously change my NFT?" You would be correct. To prevent this, the hash field from the hidden settings is very important. This should be the MD5 hash of the cache file created when you launched your candy machine, which contains the "real" metadata URIs. If you were to change the metadata to a different URI, you could totally change the NFT. This hash field exists so that users can confirm after reveal that the real URIs have not been changed, by reconstructing that cache file and comparing the MD5 hashes. Hence you should not remove your hidden settings - without that hash, your collection cannot be trusted.
You can not unhide. Only solution is creating a new candy machine.
In many of the calls described in the Azure DevOps REST API documentation, I need to supply the name of the organization, e.g.:
https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases?api-version=5.0-preview.8
The project I can get from System.TeamProject. I would have expected something similar for organization name, something like:
System.TeamFoundationCollectionName
This does not seem to be available. I've even printed out all of my environment variables on the agent and don't see anything that fits the need exactly. Sure, I can parse it out of one of the other values, but this seems fragile since MS seems to like to change the format of URLs.
I also can't hard code the organization name because this release definition will live in multiple organizations and we don't want to have to manually update it for each. How are others solving this problem?
Try using System.TeamFoundationServerUri and System.TeamFoundationCollectionUri to build your API requests. They have the organization included in them.
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/variables?view=vsts&tabs=batch
edit: SYSTEM_TEAMFOUNDATIONSERVERURI/BUILD_PROJECTNAME/_apis/release/releases?api-version=5.0-preview.8
It looks like currently there is no such variable for the organization, also, the variables return the old URL (xxx.visualstudio.com) and not the new URL (dev.azure.com/xxx) so if you use the System.TeamFoundationCollectionName the API should work without the {organization}:
https://System.TeamFoundationCollectionName/{project}/_apis/release/releases?api-version=5.0-preview.8.
In Powershell, do this:
# Where SYSTEM_TEAMFOUNDATIONCOLLECTIONURI=https://some_org_name.visualstudio.com/
([System.Uri]$Env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI).Host.split('.')[-3] # returns 'some_org_name'
Now, just assign that to a variable and use it anywhere you like. "SYSTEM_TEAMPROJECT" is the Project Name, so no need to do any parsing there. It is already available.
Newly Created subscription for new report fails with error " Failure sending mail: The specified string is not in the form required for an e-mail address.Mail will not be resent."
It is defined in the same way the existing one, using same ReportServer with unchanged config since it started working.
Using full email addresses (user.name#do-main.co.uk), existing SMTP Server that is set up on Exchange Server (working, other services use it successfully) but queue does not pick up new subscription emails. Security is individually managed for this report (limited acces, users added using full DOMAIN\User Name notation).
There were changes in firewall/proxy settings, but SSRS is internal anyway so don't see the connection..
Where else can I look to see what's the problem?
I deleted subscriptions and recreated them from scratch. And no errors, all works fine. Funny part is that I entered email addresses manually, in contrast with previous attempts on copy&paste them from elsewhere.
Still weird.
it is possible that when you copied they were including characters, the names must match exactly. I have had this issue, very finicky...
here are some helpful scripts for analyzing subscriptions, Microsoft does not make it easy to identify individual users and reports in the back-end, but you may find the typo here if there is one hiding:
;
WITH subscriptionXmL
AS (
SELECT SubscriptionID
,OwnerID
,Report_OID
,Locale
,InactiveFlags
,ExtensionSettings
,CONVERT(XML, ExtensionSettings) AS ExtensionSettingsXML
,ModifiedByID
,ModifiedDate
,Description
,LastStatus
,EventType
,MatchData
,LastRunTime
,Parameters
,DeliveryExtension
,Version
FROM ReportServer.dbo.Subscriptions
)
,
-- Get the settings as pairs
SettingsCTE
AS (
SELECT SubscriptionID
,ExtensionSettings
,
-- include other fields if you need them.
ISNULL(Settings.value('(./*:Name/text())[1]', 'nvarchar(1024)'), 'Value') AS SettingName
,Settings.value('(./*:Value/text())[1]', 'nvarchar(max)') AS SettingValue
FROM subscriptionXmL
CROSS APPLY subscriptionXmL.ExtensionSettingsXML.nodes('//*:ParameterValue') Queries(Settings)
)
SELECT *
FROM SettingsCTE
WHERE settingName IN ('TO', 'CC', 'BCC')
Also find this lovely article about setting up subscriptions:
http://www.sqlcircuit.com/2012/10/ssrs-implementation-of-file-share.html
In file: ext/quick/ext_tables_static+adt.sql
...
INSERT INTO `tx_quick_string` (`name`, `vlaue`) VALUES
('catalog', 'this is group one');
...
I want to change the value to 'this is group 1'. This is what I did:
a.changed it in this file:ext/quick/ext_tables_static+adt.sql
b.changed it in typo3/phpmyadmin->table tx_quick_string
It seems work. But I have some questions:
1.Does this file ext_tables_static+adt.sql only take effect when install/uninstall extension?
2.Is there anything else I need to do after I changed the value in ext_tables_static+adt.sql and typo3/phpmyadmin->table tx_quick_string? Do I need to update the extension in EM?
Yes, only when you install the extension.
No, if you already did the db update manually, there is nothing more to do.
If the extension you mentioned is not maintained by you, the files may get reverted during the next update of this extension, keep that in mind!
Apart from the things you asked I strongly advise you to NOT use the phpmyadmin extension of TYPO3. It has security problems on a kind of regular basis. So the better and more secure solution is to either use the db management tool your hosting company provides (they will keep it running and updated) or to put a separate tool somewhere else and secure it with a password (like htaccess restriction or something).
So we're trying to set up replicated repositories using PlasticSCM, one in the US, and one in Australia and running into a bit of a snag.
The US configuration is Active Directory, the AU configuration is User/Password. This in itself is not a big deal, I've already set up the SID translation table.
The problem is with plasticscm's replicate command itself. This is the command which should replicate from the US to AU, run ON the AU server.
cm replicate br:/main#rep:default#repserver:US:8084 rep:myrep#repserver:AU:9090 --trmode=name --trtable=trans.txt --authdata=ActiveDirectory:192.168.1.3:389:john.doe#factory.com:fPBea2rPsQaagEW3pKNveA==:dc=factory,dc=com
The part I'm stuck at is the authdata part (the above is an EXAMPLE only). How can I generate the obscured password? I think it's the only thing preventing these two repositories from talking to each other.
Ok, I've solved my own problem.
To get that "authdata" string, you need to configure your client to how you need to authenticate.
Then navigate to c:[users directory][username]\Local Settings\Application Data\plastic.
Pick up the client.conf and extract the string from the SecurityConfig element in the XML.
Check the new GUI here. It's a little bit easier.