I have created a promotion promoxyz with unilimited access and create coupon couponxyz which uses promoxyz, and gave it to user1 , he used it so promoxyz is saved in his active promotions as unlimited.
No after some time the business wanted the promoxyz to be limited to max use of "1", so the max number of uses is changed to "1" and published through BCC.
Now my question is why is the user1 is able to continue to use it as unlimited, Aparantly the updated promotion has no effect on user1. Is there a way to force the user1 promotions to point the latest setting in this case only once usage ?
Thanks
It is not effected becoz the latest change in the promotion asset is done in the BCC ie., in publishing server .But where as when user1 is using the promotion it is taking this promotion copy from production server.So unless you have the latest copy in production.You cant see the effected change.But still you can go in short cut.There are two ways
Deploy the version of your promotion in production server again.This
is traditional way.
Else go to dyn admin of production and then to
claimable repository/Product catalog (where ever your promotion
repository item is) and use
<update-item item-descriptor="your promo item descriptor" id="your promo id">
<set-property name="global"><![CDATA[false]]></set-property> <!-- Automatically apply to all orders -->
<set-property name="giveToAnonymousProfiles"><![CDATA[false]]></set-property> <!-- Give to anonymous customers -->
</update-item>
and in your API code do grant the promotion explicitly to that user to whom you want to.
PromotionTools.grantPromotion("userId(not login id)", "promotionId");
The recommended approach is to not modify existing promotions.
You should expire the current promotion (by adding an end date), and create a new one with an appropriate start date.
Related
In Keycloak, by default, users are able to change their first and last name in the account manager page. However, is it possible to disable this behavior?
Removing both fields in the theme results in those values not being sent and the form failing, and a hand-crafted POST request would defeat this method anyway.
I came across a similar problem and after reading this SO post, came to know that although you can disable/hide fields in ftl, you cannot disable form validation
For e.g I hid firstname field , but still cannot submit. Same was the result with disable as well:
I am not aware about disabling a particular field in some other way. However there is a workaround in which you can disable the entire account modification flow (Password can still be changed by Forgot Password option).
Bu default, account modification is enabled, but you can disable it for a particular realm by going to Realms -> Clients -> Account.
The result of this will be, the account page will be inaccessible:
You can remove the client role 'manage_account' for client 'account'.
In Keycloak, by default, users are able to change their first and last
name in the account manager page. Is it possible to disable this
behavior?
That can be done out-of-the-box (since Keycloak 14) by using the user profile functionality. First, the preview feature declarative-user-profile has to be enabled. For that start the server with:
--features=declarative-user-profile.
for the Quarkus version, or with
-Dkeycloak.profile.feature.declarative_user_profile=enabled
for the Wildfly version.
Bear in mind that:
Declarative User Profile is Technology Preview and is not fully
supported.
After starting the server with the aforementioned option, go to the Keycloak Admin Console and:
Go to the according Realm;
Go to the tab General;
Set User Profile enabled to ON
A new tab named User Profile (top right) will show up; click on it, and a set of configurable attributes will be shown.
Click on firstName, and then go to Permissions
In that section the permissions can be changed, accordingly. For example, if one sets Can user edit? to OFF, then when the user tries to change the firstName field in the account UI, that UI throws the following warning message:
The field First name is read only.
The same configuration can also be applied to the lastName attribute.
For the new Keycloak UI the workflow is exactly the same as the one I have just described. More information about the feature can be found in the official keycloak documentation (link)
You can use readonly property to disable email you can just change the following line:
<input type="text" class="form-control" id="email" name="email" readonly autofocus value="${(account.email!'')}"/>
I have created a gift purchase promotion particular items(like on purchase 5 X soaps get 10% discount) and using GetApplicablePromotionNames droplet for displaying those promotions on the items. GetApplicablePromotionNames is returning this promotion for the correct item but not validating pmd rules which has been configured with some customize property.I was validating channel of order should be STORE but for the product promotion displaying for channel=WEB as well.
I suspect you have encountered a known issue with version 10.1.2 with the EverythingQualifierService. The workaround is as follows:
Reconfigure the filters property of the EverythingQualifiesService.properties file to use the EverythingQualifiesService instead of the QualifierService.
There are a number of other known issues with promotions and the full list can be found with Oracle Commerce 10.1.2 Release Notes.
I am working with GWT / RequestFactory and a set of customer requirements regarding permissions. Let me explain a basic example:
Every user is assigned to a company. Every user should be able to edit company's core data - but only e.g contact information, website etc. Security-relevant ones like BIC/SWIFT, IBAN, Company name and so on can only be changed if the user has a certain permission XY.
So far so good, on the client side I can check the permissions and disable those fields the user is not allowed to edit. But what would be the most elegant way to ensure on the server side that those fields have not been set without permission?
My problem is that I cannot track changes on the server side. Having #PreAuthorize on every setter is not an option too, because it would end in an authorization-massacre in each and every entity.
At the moment I am following a workaround: every field that is secured / depends on a given permission is passed as an argument to the entity-method and is excluded from the proxy. That way, values cannot be set using the proxy and I can check in my server code if the user has permissions. If not, nothing happens. If user has permissions, I set the values manually. But that produces a lot of boilerplate-code and ugly method signatures because the number of values passed to the method could get large.
I hope you understand my issue. I'm looking forward for your opinions and tips. Thank you in advance.
Well, you can receive many answers (different each other), and all of them could be right, so, at the end is your call. Wait for others answers. I am going to give you the approach that I followed (and it worked pretty well). :D.
Under my opinion, the server should do less as possible, so keep the logic for allowing modify each param on the server I think it is not a scalable solution (if your system has 1M users modifying everything at the same time, will your server work fluent?). I prefer let the client do the job (like Roomba :D).
For solving that problem, in our system we implemented an Access Control List solution. You can store in your db, on each user entity, a list with granted permissions. So, when that information arrives to the client (after user's log in, for example), you can get them, and show the fields that he/she is allow to modify.
Something like:
if (canModifyPersonalDetails(user.getAcls(), ...) ) {
//show labels ...
}
if (canModifyBankDetails(user.getAcls(), ...) ) {
//show labels
}
You can not avoid server call for log in, so it is not a big deal send the extra information (think about the ACLs could be simple list of integers 0 means personal details, 1 bank details....).
If you are dealing with very compromised information and you prefer do some stuff on the server, in that case probably I'd set up a security level, when you are persisting/updating your proxy, I'd do something like:
if (isAllowForPersonalDetails(user.getSecurityCode()) {
//update the modified personal details
}
if (isAllowForBankDetails(user.getSecurityCode()) {
//update the modified bank details
}
user.update();
I am a big fan of clear User GUI's, and a very big fan of let the server free as much as possible, so I prefer the first option. But if you have constraints for modifying user entity in db, or you prefer do not modify your views, or any constraint with security, maybe the second option is the best one for you.
Hope that helps!
I'm using Drupal 6.16: When a user creates an account on my site I have them select a category (ie children, youth, adult, etc). This is done with the select list box using the content_profile module. I have a content type that posts an announcement. In this content type is a check box that says 'email group'. Right now it does nothing, but what I would like for it to do is e-mail all the users that are associated with the group they chose when signing up for their account. If this will require extra code please be specific as I am not a strong php programmer.
Thanks for the help!!
msindle
There might be some module that do it exactly, but I don't think so.
I would have done it using few building blocks:
Retrieve the list of emails using Views - define a view that gives you the addresses according to a given group argument.
Use Rules module that will send an email notification after node is created.
Combine the two (this is the hard part) - insert the values from the view as the recipients for the email. You might be able to do it using PHP inside the Rule definition, plus view execution.
Try to accomplish it, and if you get into troubles, you are welcome to contact me via shushu.i#gmail.com
I would try http://drupal.org/project/subscriptions module + http://drupal.org/project/messaging module. You can set preferences for automatic subscribing to content type. Maybe Rules module can subscribe users automatically after creating or updating content_profile. Or maybe Rules can flag users after creating or updating content_profile and Subscription module could autosubscribe flagged users.
Is there a way to block a given change based on the user role?
For example, I don't want any developer to be able to change a ticket status from 'development' to 'closed'. I want it to go through 'test', and allow 'test' to 'closed' only to users with the test role.
This is pretty straightforward tweak to the Trac Workflow. The documentation for adding optional testing is quoted below:
By adding the following to your
[ticket-workflow] section of trac.ini
you get optional testing. When the
ticket is in new, accepted or
needs_work status you can choose to
submit it for testing. When it's in
the testing status the user gets the
option to reject it and send it back
to needs_work, or pass the testing and
send it along to closed. If they
accept it then it gets automatically
marked as closed and the resolution is
set to fixed. Since all the old work
flow remains, a ticket can skip this
entire section.
testing = new,accepted,needs_work,assigned,reopened -> testing
testing.name = Submit to reporter for testing
testing.permissions = TICKET_MODIFY
reject = testing -> needs_work
reject.name = Failed testing, return to developer
pass = testing -> closed
pass.name = Passes Testing
pass.operations = set_resolution
pass.set_resolution = fixed
Now all tickets must go through the "testing" state before the "pass" state.
To ensure that only certain testers can change a ticket from "testing" to "pass", create a new permission called TICKET_PASS (the trac admin can do this in the web UI), and add the following to your the workflow section of your trac.ini:
pass.permissions = TICKET_PASS
IMHO, it's sufficient to just require that tickets go through testing before they pass. Any reasonable developer knows that they shouldn't move a ticket from the "testing" state to the "passing" state unless it's passed whatever quality control you do. And since there's a history of their actions, they can be blamed for inappropriately marking tickets as "pass". Restricting the privileges will probably get in the way (distracting the trac admin) more than it helps.
[NB: I had to remove all but one of the hyperlinks to documentation b/c my rep is too low. Sigh.]