How does a monk’s Martial Arts feature modify damage done by magical monk weapons?

I’m curious about how exactly the Martial Arts class feature modifies damage done with magic weapons that add extra damage. Here’s the relevant bullet point of the class feature (which is on page 78 of the PHB, and in the basic rules).

  • You can roll a d4 in place of the normal damage of your unarmed strike or monk weapon. This die changes as you gain monk levels, as shown in the Martial Arts column of the Monk table.

The kind of scenario I’m curious about is a 10th level monk (Martial Arts die: 1d8) wielding a Frost Brand. Here’s the relevant part of the rules for the weapon (from page 171 of the DMG, and in the basic rules):

Frost Brand

Weapon (any sword), very rare (requires attunement)

When you hit with an attack using this magic sword, the target takes an extra 1d6 cold damage. […]

A shortsword version of a Frost Brand is a valid monk weapon, and it does 1d6 piercing damage as well as the additional 1d6 cold damage described in the quote. If our monk was attacking with it and wanted to use Martial Arts, which dice would be replaced? Just the base die for the weapon, or both dice? If both dice would be replaced, what damage type would the 1d8 damage be?

Does Martial Arts replace non-dice based damage modifiers? Would a Shortsword +1 do 1d8+1 damage, or just 1d8? Would Martial Arts replace the extra +7 damage you’d get when a Mace of Smiting gets a crit? Obviously for a lot of weapons, switching out the damage may be a bad idea, but its unclear if you can just swap the base damage die and still keep the additional magical damage.

(This topic came up in discussion of a question I asked about a homebrew tweak to a monk subclass. I realized I don’t actually know how the rules-as-written work, which makes it a bit trickier to homebrew!)

How to trigger some custom c# code when a new site collection is created? Feature Stapling, delegated control?

I am using sp 2013. I have some custom code which is adding some webpart to the welcome page. I would like to execute this code for each new site collection depending on a template (mysites). Someone told me you can do that with a feature stapling or delegated control. Can someone tell me if it is possible with delegated control or feature stappling? And maybe how to implement this?

Disable YouTube AutoPlay on Home Feature

I’m having trouble disabling YouTube’s “AutoPlay on Home” feature on my wife’s phone/account. I’ve followed the instructions provided on Google’s support site, but when I reach the settings for “Autoplay”, there is no “AutoPlay on Home” option to change (see below).

ex. YouTube Missing AutoPlay on Home

YouTube Missing AutoPlay on Home

I believe she is running v14.23.50 of the YouTube app for Android 9 on a Pixel 3 phone.

Can I somehow get to this setting? Should I report this to YouTube?

Is there a way to take user input (comments) using Microsoft flow “Email with Options” feature?

I have configured Microsoft flow on a task list item creation using “Send Mail with Options”. Different options that I have configured are “Approve” and “Deny”. It is working fine however I wonder if there is a way to take user input (comments) as mandatory when user clicks on “Deny” option in mail.

Do the Shadow Magic sorcerer’s Strength of the Grave feature and the half-orc’s Relentless Endurance trait work together?

I have a player that wants to create a character that is a Half-Orc Shadow Sorcerer; specifically they want to use the combination of the Shadow Sorcerer’s Strength of the Grave feature and the Half-Orc’s Relentless Endurance to be very hard to kill.

If the character is reduced to 0 hp and decides to use Strength of the Grave, but fails the saving throw, can they then use Relentless Endurance to avoid being knocked out anyway?

Prevent token sharing: chained single-use tokens VS a designated invalidation feature


Situation:

  • A Client is requesting a resource from a Host multiple times, usually with minutes or hours between requests.
  • The Client has a signed, verifiable token, which we’ll call a Receipt, that asserts that they should be allowed to access the resource. (The Receipt will eventually expire, say at the end of the month.)
  • The Host has no way of knowing (and should have no way of knowing) who the Client is beyond the fact that a given receipt is being reused.

Problem:

Receipts cost money. (We’re building a micro-transaction service; so they cost ~0.10USD) We don’t want users (Clients) posting their Receipts online for public use, or otherwise sharing Receipts. It is not critical that nobody can share Receipts, but sharing Receipts should generally be inconvenient, and hypothetical systems for sharing receipts shouldn’t scale well.

Note that in this model a “user” may have multiple “Clients” running on different machines, and will share Receipts among their Clients.

Proposed Solutions:

  1. Have the Client create a public/private key pair for each receipt (or however often the Client wants to). The public key will be submitted with the Receipt, and whenever the Host sees a given Receipt for the first time they’ll store the accompanying public key so they can verify that future submissions came from the same person (even though they don’t know who that is).
    • cons: This just moves the “secret that shouldn’t be shared” from the Receipt to the private key.
    • pros: A private key really is easier to keep secret, in particular because, while the Receipt is sent to the Host, the private key never leaves the Client’s control.
  2. Have the Host give the Client a single-use Token (as part of their normal response) to be included with their next submission of a given Receipt. These Tokens can be quite small. Re-submission of a Receipt (even once) without the expected Token is evidence that the receipt has been shared.
    • cons: This will make both systems (Client and Host) harder to implement. It’s convoluted and error-prone. Because Clients owned by a single user will share Receipts, some “false positives” are inevitable. Furthermore, sharing Receipts inappropriately is still possible using a system not too different from how well-behaving users will share Receipts among their devices. In this sense this solution relies on incompetent members of they hypothetical sharing pool accidentally violating the Token chain.
    • pros: Building a sharing pool would be relatively difficult, and as a pool scaled up in members and usage it would become increasingly non-performant (because of locking) or increasingly likely to break Receipts (because they’d been noticed as shared). Additionally, a “good samaritan” in the sharing pool would be able to break the shared Receipts by intentionally violating the Token chains.
  3. Give “good samaritans” a specific function for invalidating receipts.
    • cons: Does nothing to directly prevent sharing, it relies entirely on the idea that any hypothetical sharing pool would either not scale, or eventually be infiltrated by some kind of defector.
    • pros: It’s much easier to implement. Additionally, if combined with #1, then the Host would have a signed invalidation request they could present if their decision to reject subsequent submissions of that Receipt were ever challenged.

Originally I was planing on doing #1 and #2,
but having thought about it for a couple days I’m thinking #1 and #3 (or maybe just #3) would be easier and good enough.

Do people have suggestions for any (combination) of the above solutions, or other solutions I haven’t listed?

Are there important angles I’ve overlooked?

Where are feature definitions/field definitions stored in the Farm and how can I delete / un-cache a field definition?

I have a solution with some field definitions and content type definitions as part of a Site scoped feature.

One of the field definitions was originally this:

<Field ID="{GUID}"         Name="MyField"         DisplayName="My Field"         Type="TaxonomyFieldType"         ShowField="Term1033"         DisplaceOnUpgrade="TRUE"         Overwrite="TRUE"         Group="My Columns">   <Customization>     <ArrayOfProperty>       <Property>           <Name>TextField</Name>           <Value xmlns:q6="http://www.w3.org/2001/XMLSchema"                   p4:type="q6:string"                   xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">             {GUID of TaxHTField0 field}           </Value>       </Property>       <Property>           <Name>IsPathRendered</Name>           <Value xmlns:q7="http://www.w3.org/2001/XMLSchema"                   p4:type="q7:boolean"                   xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">             TRUE           </Value>       </Property>     </ArrayOfProperty>   </Customization> </Field> 

I deployed the solution to my dev farm, went to a site to check everything out, and when activating the feature something went wrong and I got an error page. I collected the correlation ID, and went to the logs to see what happened.

I found some errors that called out that field specifically by name, and gave an error that

The string ‘TRUE’ is not a valid Boolean value.

Ok, I figured that came from the IsPathRendered setting. Not a big deal if I have to configure that manually, so I removed that property from the field definition, cleaned and re-published the project, and ran Update-SPSolution to deploy the updated WSP.

When trying to activate the feature again, I once again got the “string TRUE is not a valid boolean” error, although it no longer called out my field by name.

Since then I have tried

  • Update-SPSolution -Force
  • Uninstall-SPsolution, Remove-SPSolution -Force, reboot server, Add-SPsolution, Install-SpSolution -Force

and other attempts to remove/reinstall the solution, and every time, when I go to activate the feature, I keep getting the same error.

That field was the ONLY field that had the extra property on it. There are a couple other taxonomy field definitions in the feature, but they only have the string property that has the GUID of the related TaxHT0Field note field.

So apparently, that little remnant of XML from the original field definition is still stored/cached in the Farm somewhere, even though I have repeatedly tried to re-add or update the solution/feature.

WHERE IS IT?? Where can I look to get rid of the bad XML so I can get my feature activated?

Keep in mind, the feature has never been successfully activated anywhere, so doing something with a Feature upgrade is not really possible, because there’s nothing to upgrade that way.

Any advice for Git workflow using branch per development team (and not per feature)

In our project, we have 5 teams working on a monolithic application in 3-week sprints. Until now, all commits go into master (via Gerrit). Our test pipeline is too lengthy to ensure quality pre-commit, so we have to accept that some commits break things. I’m aware that the root cause here is the pipeline, and a breaking commit should never reach master. We have to accept this, however, until our pipeline redesign is complete, and this will take several months in the least.

We’re now discussing the approach of “team branches”, where each team would develop and commit on their own branch, and update the master periodically. The heated part of the discussion revolves around merge or rebase. Our current understanding is:

Rebase

  1. On branch-team1: git rebase origin/master
  2. Resolve conflicts
  3. Push to branch: git push origin branch-team1 --force-with-lease
  4. Finally, rebase master: git rebase branch-team1

With this approach we see commit IDs changing (due to rebase + push –force), and part of our change history is invisible to Gerrit. The former has the effect that the entire team needs to halt work during the rebase, as their un-pushed work might get messed up due to the changing commit history.

On the plus side, this approach yields an easily readable history on master. Each commit is visible, and can be cherry picked or reverted.

Merge

  1. On master: git merge origin/branch-team1 (+ resolve conflicts)
  2. On branch-team1: git rebase origin/master

The main concern expressed here is that the history becomes much harder to read, as the master will mainly contain large “composite merge commits”. For debugging/blaming, the associated team branch would have to be checked for the further history. Also, reverting a single commit (originally on a team branch) becomes more tedious.

However, a short proof-of-concept indicates that the history is no different to the Rebase approach, except for the actual merge commit. Similarly, cherry picks / reverts seem just as easily done, with the sole exception being if part of the cherry pick / revert would actually be a change made during conflict resolution and thus part of the merge commit. This, however, seems a tad far-fetched.

A third way?

It seems both approaches have negative aspects (personally I don’t see much negative in the merge approach, but others on our project are clearly against it). It’s a bit hard to believe that with the power and popularity of GIT, there isn’t an established approach available which doesn’t require squabbling over.

Does anyone have some practical experience to share here?