During a web deployment I'd like to change some ACL settings. I found this article describing the process.
The article includes the following code snippet:
<PropertyGroup>
<!- Extends the AfterAddIisSettingAndFileContentsToSourceManifest
action to also set ACLs–>
<IncludeCustomACLs>TRUE</IncludeCustomACLs>
<AfterAddIisSettingAndFileContentsToSourceManifest Condition=“‘$(AfterAddIisSettingAndFileContentsToSourceManifest)’==”“>
$(AfterAddIisSettingAndFileContentsToSourceManifest);
SetCustomACLs;
</AfterAddIisSettingAndFileContentsToSourceManifest>
</PropertyGroup>
My question relates to the Condition attribute. From the comment, it appears that the intent is to append SetCustomACLs to the AfterAddIisSettingAndFileContentsToSourceManifest property. But from the condition, it appears that this block is only evaluated when AAISAFCTSM is not already set, so this isn't an "extension" so much as a "set-if-null".
So do the comment and markup disagree, or am I missing something?
I believe the Condition is there to ensure that if you've set AfterAddIisSettingAndFileContentsToSourceManifest somewhere else in the build stack explicitly, then it wont be altered. Having said that, I'd say that you aren't missing something, it reads to me the exact same way it reads to you.
Related
I'm adding liquibase to an existing project where tables and data already exist. I would like to know how I might limit the scope of changelogSync[SQL] to a subset of available changes.
Background
I've run liquibase generateChangeLog to capture the current state and placed this into say src/main/resources/db/changelog/changes/V2021.04.13.00.00.00__init01.yaml.
I've also added another changeset to cover some new requirements in a new file. Let's call it src/main/resources/db/changelog/changes/V2021.04.13.00.00.00__new-feature.yaml.
I've added a main changelog file src/main/resources/db/changelog/db.changelog-master.yaml with the following contents:
databaseChangeLog:
- includeAll:
path: changes
relativeToChangelogFile: true
I now want to ensure that when I run liquibase changelogSync[SQL] against a particular version of the db that the scope is limited to the first changelog init01, thereby allowing from that point on a liquibase update or updateToTag et al, to continue with changes following init01.
I'm surprised to see that the changelogSync[SQL] commands don't seem to offer some way (that I can see from the docs for how to do this.
Besides printing the SQL and manually changing it, is there something I've missed? Any suggested approaches welcome. Thanks!
What about changelogSyncToTagSQL ?
Wouldn't it cover your needs?
Or maybe you could try changelogSyncSQL with additional parameters "label" or and "context" ?
changelogSyncToTagSQL
context
labels
As it stands, the only solution I've found is to generate the SQL and then manually edit its contents to filter the change sets which don't correspond to your current schema.
Then you can apply the sql to the db.
I would like to try the new pipeline feature in MediatR: https://github.com/jbogard/MediatR/wiki/Behaviors
I tried the following, but it does not get executed
services.AddMediatR();
services.AddTransient(typeof(IRequestPostProcessor<,>), typeof(PostHandler<,>));
What am I missing?
You need to register the behavior associated with post-processors, like this unit test shows.
Your registration code would look like:
services.AddMediatR();
services.AddTransient(typeof(IRequestPostProcessor<,>), typeof(PostHandler<,>));
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(RequestPostProcessorBehavior<,>));
That behavior will get all the post-processors you registered and execute them.
Edit
After a comment about the post-processor running twice, I had a look at the code that registers MediatR in the ASP.NET Core built-in DI container, and it turns out instances of IRequestPreProcessor<TRequest, TResponse> and IRequestPostProcessor<TRequest, TResponse> are automatically registered as you can see here. What's left to do to get them running in the pipeline is just register the associated behavior. So the necessary registration is then:
services.AddMediatR();
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(RequestPostProcessorBehavior<,>));
I encountered the same issue as Larsi in the comment above. My code looked like this
services.AddScoped<IPipelineBehavior<AddMessageRequest, MessageResponse>, RequestPostProcessorBehavior<AddMessageRequest, MessageResponse>>();
but the behaviour still executed twice. My solution was to simply not register it manually, seems like the registration is handled otherwise now.
In my case services.AddMediatR(Assembly.GetExecutingAssembly()); was enough.
Would be nice if someone could expand on why this is.
See, I have a requirement in which I am supposed to change the "Auto Number Prefix" for only one profile, I am wondering if there is any way to achieve that?
You should be able to set AutoNumberPrefix in a rule side effect and have it apply only to that rule/profile.
<$AutoNumberPrefix="profile1_"$>
For those who wants the answer for this, I found the method to provide the different prefix for different profile type. Go in Admin Server-> Configuration -> Paste this code;
AutoNumberPrefix=<$if dDocType like 'Profile_name'$>Prefix Name<$else$>another prefix name<$endif$>
Adding the code shown as "correct" is actually the more inflexible way to do this. Any changes require a restart of the Content Server.
Jonathan's answer was really close, but the syntax used ensures that the variable "AutoNumberPrefix" remains in the profile context. It needs to be placed into local data to be used. This is accomplished using the function "dpPromote".
<$dpPromote("AutoNumberPrefix","profile1_")$>
Is there a simple way to check if a content-type, or a specific object, has Versioning enabled/disabled in Plone (4.3.2)?
For context, I am making some unique conditionals around portal_actions. So instead of checking path('object/##iterate_control').checkout_allowed(), I need to first see if versioning is even enabled. Otherwise, the action in question does not display for items that have versioning disabled, because obviously it isn't checkout_allowed.
I didn't have any luck with good ole Google, and couldn't find this question anywhere here, so I hope it's not a dupe. Thanks!
I was able to get this working by creating a new script, importing getToolByName, and checking current content type against portal_repository.getVersionableContentTypes(). Then just included that script in the conditional.
I was looking for something like this that already existed, so if anyone knows of one let me know. Otherwise, I've got my own now. Thanks again!
The first thing that checkout_allowed does is check if the object in question supports versioning at all:
if not interfaces.IIterateAware.providedBy(context):
return False
(the interface being plone.app.iterate.interfaces.IIterateAware:
class IIterateAware( Interface ):
"""An object that can be used for check-in/check-out operations.
"""
The semantics Interface.providedBy(instance) are a bit unfortunate for usage in conditions or TAL scripts, because you'd need to import the interface, but there's a reversal helper:
context.portal_interface.objectImplements(context,
'plone.app.iterate.interfaces.IIterateAware')
I want to delete this red-marked target, but am unable to.
The "minus" button in the dialogue remains greyed-out, it doesn't respond to backspace or delete keys and right-clicking just brings up help options. I can drag the missing-red-marked target above or below the working black target, but it doesn't let me delete it.
This missing red target only seems to appear in this edit schemes dialogue.
In my main project/target window, I just have the one good target there.
Any ideas how to clean this up and delete this missing target?
What worked for me was to designate another executable (or none) in the existing scheme's various actions (run, test, etc.). It's the fact it's in use in the scheme's actions that prevents its deletion. I discovered this during my research for Mastering Xcode 4 (yes, shameless plug). :-)
Try creating a brand new scheme (via "New Scheme" or "Manage Schemes...") and start using that.
Once your new scheme is building properly and is set as a default, you should be able to delete the old scheme with the bogus "missing" target.
The real issue here is explained by Joar Wingfors in the Xcode-users mailing list (emphasis mine):
In the scheme sheet you cannot delete things from one tab that some
other tab depend on. In this case you probably have to delete the
target from the test tab before you can delete it from the build tab.
Or something along those lines.
I had the exact same problem. Solved by closing the xCode and externally editing the schema file to delete the bundlableResource section for the missing library. Not the safest of all methods but it works.
First delete all schemes and then generate the schemes again. Work for me .
What Joshua said, a bit tailored. Go through all various actions and change the missing executable to an existing one.
In your case, go to 'Profile' and switch to the new app. Same if you encounter this in 'Test' tab.