I'm using symfony 1.4.8 and I have some code that basically looks like this (in a Filter):
$user = $this->getContext()->getUser();
if ($condition)
$user->addCredential('cred');
else
$user->removeCredential('cred');
die($user->hasCredential('cred');
No matter what I have done, it always registers that it has the cred credential. The die always outputs 1. I've even removed the if/else and just ran removeCredential() but it still dies with 1. Also of interest is that this is the ONLY place where this credential might be added (or removed), so I don't understand how I ALWAYS have it. I'm using sfDoctrineGuardUser plugin.
The following code is puzzling:
$user->removeCredential('cred');
var_dump($user->hasCredential('cred')); // bool(true)
also this:
var_dump($user->getCredentials()); // array(0) { }
var_dump($user->hasCredential('cred')); // bool(true)
I've also tried clearCredentials() with no luck. How can I remove this credential? I'm completely at a loss here.
Is your user a Super Admin? In such case hasCredential() always returns true.
Related
After clicking the "Return" action on a selected item from a completed Purchase Receipt, we're trying to get the "Open PO Line" value to default to false. Anyone know how customize this?
The field defaulting seems to be overwritten when we press the "Return" button. We've tried several different events in the grid but none of the seem to work.
The desired result is to default the "Open PO Line" to false after a return and once the return is released the Purchase Order line associated with the return should remain completed.
Research
The AllowOpen field on POReceiptLine is a PXBool. This means that the value must be populated via a PXDBScalar, PXFormula, etc. or via some business logic in the graph. To see what is happening, let's look at the DAC for POReceiptLine...
#region AllowOpen
public abstract class allowOpen : PX.Data.BQL.BqlBool.Field<allowOpen> { }
protected Boolean? _AllowOpen;
[PXBool()]
[PXUIField(DisplayName = "Open PO Line", Visibility = PXUIVisibility.Service, Visible = true)]
public virtual Boolean? AllowOpen
{
get
{
return this._AllowOpen;
}
set
{
this._AllowOpen = value;
}
}
#endregion
As you can see, there isn't any logic to this field in the DAC, so we need to turn to the graph to see how it is used. (Even if there were logic in the DAC, we would need to see if the graph does something. However, logic in the DAC might have been an easy override with CacheAttached - unfortunately, not in this case.)
Let's turn to POReceiptEntry where the return is handled. We find AllowComplete and AllowOpen being set in the POReceiptLine_RowSelected event, as we would expect since it must be populated on the graph side of code having no logic in the DAC.
if ((row.AllowComplete == null || row.AllowOpen == null) && fromPO)
{
POLineR source = PXSelect<POLineR,
Where<POLineR.orderType, Equal<Required<POLineR.orderType>>,
And<POLineR.orderNbr, Equal<Required<POLineR.orderNbr>>,
And<POLineR.lineNbr, Equal<Required<POLineR.lineNbr>>>>>>
.Select(this, row.POType, row.PONbr, row.POLineNbr);
// Acuminator disable once PX1047 RowChangesInEventHandlersForbiddenForArgs [Legacy, moved the exception here from PX.Objects.acuminator because the condition was changed]
row.AllowComplete = row.AllowOpen = (row.Released == true) ?
(row.ReceiptType != POReceiptType.POReturn ? source?.Completed == true : source?.Completed != true) :
(source?.AllowComplete ?? false);
The field is populated in the row.AllowComplete = row.AllowOpen = (row.Released == true) ?... section of code.
Subsequently, we see that the CopyFromOrigReceiptLine method sets this value to false on the "destLine" being created.
destLine.AllowOpen = false;
As that isn't "true" then we know this isn't our spot. Continuing on, we see in UpdatePOLineCompletedFlag that AllowComplete and AllowOpen are being set. This could be our spot (or one of them).
row.AllowComplete = row.AllowOpen = poLineCurrent.AllowComplete;
Side note: It is worth noting that this line appears twice in an if then else. In both cases it is going to be executed, therefore it would be better coding practice to place this identical statement AFTER the if then else since both the if and else conditions will execute this same statement regardless of the if.
This particular use appears to be pulling the value from the AllowComplete field of the PO Line being received. At this point, you should consider if you need to look upstream at the PO Line to see if the field there needs to be manipulated as well. I cannot answer that for you as your business case will drive the decision.
There also is a line in the Copy method that sets AllowComplete and AllowOpen.
aDest.AllowComplete = aDest.AllowOpen = (aSrc.CompletePOLine == CompletePOLineTypes.Quantity);
The Copy method is overloaded, and the other signature of the method sets the values to true.
aDest.AllowComplete = true;
aDest.AllowOpen = true;
Both of these cases may need customization as well, but I don't think it's the primary issue.
Next Steps
At this point, we see that either the field is being set in UpdatePOLineCompletedFlag or in methods that seem related to copying records. You will need to investigate further if the copy related methods warrant a change as well. However, I think the initial focus should be on the UpdatePOLineCompletedFlag method.
If we find the other points identified require customization, we likely will handle them all the same way... Override the base method/event, invoke the original method/event in our override, and then force the values to fit our business case. Careful testing will be needed since forcibly altering these values may create unforeseen negative ripples.
Something to try
We want to update (or create) a graph extension for POReceiptEntry to override the UpdatePOLineCompleteFlag method. This compiles, but it is completely untested on my part. We need to create a delegate and specify the PXOverride attribute. Then we want to execute the base method before we override the field(s) in question.
Note the extra code (commented out) as a reminder that you need to be careful of methods (typically events) updating our record in the cache and needing to be located so that we don't use a stale copy of the record. I don't think that's necessary in this case, but it seems to be somewhat obscure in code samples that I see. Of course, that is because I'm always looking at the code repository which rarely has graph extensions overriding event handlers!
#region CreateReceiptEntry Override
public delegate void UpdatePOLineCompleteFlagDelegate(POReceiptLine row, bool isDeleted, POLine aOriginLine);
[PXOverride]
public virtual void UpdatePOLineCompleteFlag(POReceiptLine row, bool isDeleted, POLine aOriginLine, UpdatePOLineCompleteFlagDelegate baseMethod)
{
//Execute original logic
baseMethod(row, isDeleted, aOriginLine);
/* If the base method has updated the cache, then we would need to locate the updated record in the cache to proceed
* This tends to be the case more often with event handlers, so it probably isn't needed in this case.
* This is just for reference as a training reminder
//If row has been updatd in the baseMethod, let's go get the updated cache values
POReceiptLine locateRow = Base.transactions.Locate(row);
if (locateRow != null) row = locateRow;
*/
//Override the fields to false - need to test to see if this creates any issues with breaking existing business logic
row.AllowComplete = row.AllowOpen = false;
}
#endregion
If this doesn't get you the specific answer you need, I hope it at least gives you some insight into how to hunt down "the spot" to change. I suspect you may need to update the POLine for a complete solution as hinted above. (See the event handler POReceiptLine_AllowOpen_FieldUpdated for the code that leads me to that conclusion.)
Good luck with your customization, and happy coding!
I'm using Sysdig to capture some events and have a small chisel (LUA script) to capture and format the events as necessary. On the on_init() I'm requesting fields like so :
f_field = chisel.request_field("<field>")
My question is how can I check if a field exists before requesting it? I'm going to use a new field only just released on 0.24.1 but ideally I'd like my chisel to continue to work on older versions of sysdig without this field. I've tried wrapping the call to chisel.request_field in a pcall() like so :
ok, f_field = pcall(chisel.request_field("<field>"))
and even implementing my own "get_field" function :
function get_field(field)
ok, f = pcall(chisel.request_field(field))
if ok then return f else return nil end
end
f_field = get_field("<field>")
if f_field ~= nil then
-- do something
end
but the error ("chisel requesting nonexistent field <field>") persists.
I can't see a way to check if a field exists but I can't seem to handle the error either. I really don't want multiple versions of my scripts if possible.
Thanks
Steve H
You're almost there. Your issue is in how you're using pcall. Pcall takes a function value and any arguments you wish to call that function with. In your example you're passing the result of the request_field function call to pcall. Try this instead..
ok, f = pcall(chisel.request_field, "field")
pcall will call the chisel method with your args in a protected mode and catch any subsequent errors.
Using the code:
function createNewBody(name,mass)
if not world.body[name]==nil then
print("This body has already been created. Maybe you meant to update it's values?\n")
else
world.body[name]={mass=m,x=0,y=0,xAccel=0,yAccel=0,xR=0,yR=0,properties={gaseous=false,texture=""}}
world.bodies=world.bodies+1
end
end
This code shows no errors, but when I bind createNewBody(moon,1.622) to a key and then use it, it lets me spam the key without showing the error message.
And, yes, I have defined world.bodies and world.body
not world.body[name]==nil is parsed as (not world.body[name])==nil. Since the result of not is a boolean, it is never nil.
Try not(world.body[name]==nil) or world.body[name]~=nil.
I faced with very strange problem. I had a set of tests which I run daily on Jenkins and without any noticeable changes some asserts(expects) started fail. THe strange thing here is that they fails ONLY if I execute tests from Jenkins on Browserstack. Locally everything just fine, locally on browserstack everything is fine, on saucelabs everything is fine. I have 3 it() blocks with similar expects:
value1 = $('.someclass');
value2 = ..
value3 = ..
expect(value1.getText()).toContain('tratata');
expect(value2.getText()).toContain('uhuhuhu');
expect(value3.getText()).toContain('ahahaha');
they are all situated in different it() blocks. Now strange thing:
When I execute tests, test with 1st assert block passes just fine, on the 2nd it block it says that assert fails(i do some stuff in order to change values), but manually / locally I see that everything is fine. Also while test is getting executed I see that values are getting changed ( i even did screenshots and check visual log on browserstack). In the 3rd it block I did other action and assert fails again, BUT it compare it with value which I was expected from step 2, not step 1!! SO looks like for some reason I am one step behind... If I comment it block or just asserts in the 1st test, 2nd one passes fine, but 3 fails. If I comment 2 it block, 3rd passes fine.
Sounds like that in this particular case for some reason some magic happens and only on Jenkins and only on Browserstack. By the way tests have been working for a while without any problems and started fail without any updates.
I though that for some reason I have problems with control flow, I WAIT for elements to be presented in addition, I tried browser.sleep() anti-pattern also to investigate it better, but it magically keeps be on the step behind.
I am not looking for particular solution directly, but any suggestions will be highly appreciated, I am not sure which additional info I should provide, hope I described the problem enough.
#protractor2.1.0
#jasmine2.3.2
browser.ignoreSynchronization = false
it('', function () {
expect(viewBookingDetailsPage.totalCostSection.depositDue.getText()).toContain('542.00');
expect(viewBookingDetailsPage.totalCostSection.remainingBalance.getText()).toContain('4,878.00');
expect(viewBookingDetailsPage.totalCostSection.totalDepositAmount.getText()).toContain('5,420.00');
});
it('', function () {
$(viewBookingDetailsPage.eventAndItemsSection.addItemsBtn).click();
helper.waitElementToBeVisisble(viewBookingDetailsPage.addItemsModal.modalOpen);
viewBookingDetailsPage.addonItemAttribute(0, viewBookingDetailsPage.addItemsModal.events).click();
helper.waitElementToBeVisisble(viewBookingDetailsPage.addItemsModal.eventSelectionPopup);
viewBookingDetailsPage.addItemsModal.availableEvents.then(function (events) {
//Morning event
events[3].$('i').click();
viewBookingDetailsPage.addonItemAttribute(0, viewBookingDetailsPage.addItemsModal.selectItem).click();
viewBookingDetailsPage.addonItemAttribute(1, viewBookingDetailsPage.addItemsModal.selectItem).click();
viewBookingDetailsPage.addItemsModal.addButton.click();
helper.waitElementToDisappear(viewBookingDetailsPage.addItemsModal.modalOpen);
helper.waitElementToBeVisible(viewBookingDetailsPage.addonItemDetail(0, 0, 0, viewBookingDetailsPage.eventAndItemsSection.itemName));
expect(viewBookingDetailsPage.totalCostSection.depositDue.getText()).toContain('592.00');
expect(viewBookingDetailsPage.totalCostSection.remainingBalance.getText()).toContain('5,328.00');
expect(viewBookingDetailsPage.totalCostSection.totalDepositAmount.getText()).toContain('5,920.00');
});
});
it('', function () {
viewBookingDetailsPage.addonItemDetail(0, 0, 0, viewBookingDetailsPage.eventAndItemsSection.removeItem).click(); ----- method just returns element into multiple internal repeaters
expect(viewBookingDetailsPage.totalCostSection.depositDue.getText()).toContain('580.00');
expect(viewBookingDetailsPage.totalCostSection.remainingBalance.getText()).toContain('5,220.00');
expect(viewBookingDetailsPage.totalCostSection.totalDepositAmount.getText()).toContain('5,800.00');
});
I fixed this with waiting directly to text to change:
browser.wait(function() {
return viewBookingDetailsPage.totalCostSection.depositDue.getText().then(function(text) {
return text === '592.00USD';
});
}, 15000);
I am sure that something goes wrong here, but it worked for me. If I will have some free time I will try to enhance the answer and investigate it deeper.
This post hints at the fact that one of the steps could be blocked waiting to complete: http://makandracards.com/makandra/1709-single-step-and-slow-motion-for-cucumber-scenarios-using-javascript-selenium. Not sure if that helps at all.
Just new in Prestashop (1.6.0.6), I've a problem with my product page in admin. All translatable-field are to display:none (I inspect the code with chrome).
So when I want to create a new product I can't because the name field is required.
I thought that it was simple to find the .js whose do that but it isn't.
If somebody could help me, I would be happy.
Thank you for your help
Hi,
I make some searches and see that the function hideOtherLanguage(id) hide and show translatable-field element.
function hideOtherLanguage(id)
{
console.log(id_language);
$('.translatable-field').hide();
$('.lang-' + id).show();
var id_old_language = id_language;
id_language = id;
if (id_old_language != id)
changeEmployeeLanguage();
updateCurrentText();
}
When I set the Id to 1 (default language), it works. It seems that when I load the page, the function is called twice and the last calling, the id value is undefined. So the show() function will not work.
If somebody could help me. Thank you.
In my console, I see only one error
undefined is not a function.
under index.php / Line 1002
...
$("#product_form").validate({
...
But I find the form.tpl template and set this lines in comment but nothing change.
EDIT: According to comment on this link http://forge.prestashop.com/browse/PSCFV-2928 this can possibly be caused by corrupted installation file(s) - so when on clean install - try to re-download and reinstall...
...otherwise:
I got into a similar problem - in module admin page, when creating configuration form using PrestaShop's HelperForm. I will provide most probable cases and their possible solutions.
The solution for HelperForm was tested on PS 1.6.0.14
Generally there are 2 cases when this will happen.
First, you have to check what html you recieve.
=> Display source code - NOT in developer tools/firebug/etc...!
=> I really mean the pure recieved (JavaScript untouched) html.
Check if your translatable-fields have already the inline style "display: none":
Case 1 - fields already have inline style(s) for "display: none"
This means the template/html was already prepared this way - most probably in some TPL file I saw codes similar to these:
<div class="translatable-field lang-{$language.id_lang}"
{if $language.id_lang != $id_lang_default}style="display:none"{/if}>
Or particularly in HelperForm template:
<div class="translatable-field lang-{$language.id_lang}"
{if $language.id_lang != $defaultFormLanguage}style="display:none"{/if}>
Case 1 is the most easy to solve, you just have to find, where to set this default language.
Solutions
HelperForm
Look where you've (or someone else) prepared the HelperForm object - something like:
$formHelper = new HelperForm();
...
Somewhere there will be something like $formHelper->default_form_language = ...;
My wrong first solution was to get default form language from context - which might not be set:
$this->context->controller->default_form_language; //THIS IS WRONG!
The correct way is to get the default language from configuration - something like:
$default_lang = new Language((int)Configuration::get('PS_LANG_DEFAULT'));
$formHelper->default_form_language = $default_lang->id;
...this particularly solved my problem...
Other form-creations
If there is something else than HelperForm used for form creations, the problem is still very similar.
You have to find where in files(probably tpls) is a condition for printing display:none for your case - then find where is the check-against-variable set and set it correctly yourself.
Case 2 - fields don't have inline style(s) for "display: none"
This means it is done after loading HTML by JavaScript. There are two options:
There is a call for hideOtherLanguage(), but there is wrongly set input language - that means no language will be displayed and all hidden.Solution for this one can be often solved by solving Case 1 (see above). In addition there can be programming error in not setting the after-used language id variable at all... then you would have to set it yourself (assign in JavaScript).
Some script calls some sort of .hide() on .translatable-field - you will have to search for it the hard way and remove/comment it out.
PS: Of course you can set the language to whatever you want, it is just common to set it to default language, because it is the most easier and the most clear way how to set it.