I wrote a program that sends the following
to App: 8=FIX.4.4|9=156|35=V|34=2|49=id|52=sometime|56=id1|146=1|55=EURUSD|460=4|167=FOR|262=1|263=1|264=1|265=0|267=2|269=0|269=1|10=114|
I receive this. I get the bid and the offer as expected:
from App 8=FIX.4.4|9=217|35=W|34=4|49=id1|52=sometime|56=id|42=sometime1|55=EURUSD|262=1|268=2|269=0|270=1.12438|271=50000|269=1|270=1.12442|271=50000|10094=sometime2|10=002|
But as I request snapshot + update on full refresh, it sends back the following;
to App: 8=FIX.4.4|9=118|35=j|34=3|49=id|52=sometime|56=id1|45=2|58=Conditionally Required Field Missing (299)|372=W|380=5|10=210|
Data Dictionary of my broker is the following: DataDictionary
UseDataDictionary=Y
ValidateUserDefinedFields=N # tried with Y, same
DataDictionary=C:\Users\Documents\FIX44.xml
Any idea of what I did wrong please?
Thank you folks!
Check your counterparty's documentation for what fields they expect you to send in the MarketDataRequest (35=V) message.
In the default DataDictionary, QuoteEntryID (tag 299) doesn't belong to MarketDataRequest or in any of the repeating groups it contains. This means that your counterparty has made a DD customization and added it somewhere.
So your main mistake is that you are not looking at your counterparty's docs, and your local DD is not in sync with theirs. That latter part is not burning you here in this question, but it will burn you later. Get your DD in sync!
Back to this issue: Sure, you're adding QuoteEntryID to the message, but you're adding it to the top-level of the message body, and your counterparty probably isn't looking for it there. If you look again at the default DataDictionary, QuoteEntryID always belong to a group, so your counterparty probably wants it in in a group also. You just need to read their docs to find out which group it is.
TLDR: Counterparties always customize the DataDictionary -- always read your counterparty's docs!
Related
So, I got as far as finding the group_channels function, but this doesn't seem to store user info. Example:
channel_layer = get_channel_layer()
context['players_list'] = channel_layer.group_channels('lobby')
I get {'players_list': ['daphne.response.WbZyUfNixL!sbzfJEzdPp', 'daphne.response.KfDHQnHLdw!DpoOqdGute', 'daphne.response.JqlcVVMuny!xHLDSaCzUz', 'daphne.response.mWrYVXDKoI!AjkyadSsPe']} as a response.
How can I list users connected to Group('lobby')? Thanks in advance
You are in the right path to the solution, that is how it is actually done. Perhaps what you're missing is adding the proper procedures to the consumer, so it adds the required data.
In django-channels v.2.x the consumer includes this information automatically, but you have to add it manually in v.1.x, using for that a decorator or a proper declaration inside a Generic Consumer, as explained in the documentation.
I am trying to get additional fields when making a call through Asana's Python API Tasks.find_by_project(). My code for the call is:
project_tasks = Tasks(self.client).find_by_project(project_gid, opt_fields= ["name", "memberships", "gid"])
And I am getting:
{'id': 408541814417314, 'gid': '408541814417314', 'memberships': [{}], 'name': 'Reports - Develop quality control report to run for MES'}
It seems like I can only access the fields that are populated by the compact task record, but I need additional fields and would like to get them without re-looping through all the tasks and getting the complete task. Oddly, it returns an empty list, but when I look at the full tasks record there are memberships for this task.
I saw this question, which seems to be similar but the given (attempted) solution doesn't work for me (I get no additional fields):
How can I access custom fields from Asana API using Python?
In case anyone else runs into this issue, I had tyo work with Asana to get this figured out. memberships isn't callable, you have to call Tasks(self.client).find_by_project(project_gid, opt_fields= ["name", "memberships.section", "gid"]) or Tasks(self.client).find_by_project(project_gid, opt_fields= ["name", "memberships.project", "gid"]) you can also apparently call opt_expand=['memberships'] to get all of the data.
from asana:
Thanks for your patience!
We heard back from our Platform Team regarding the issue. What you are
experiencing is currently expected behavior, but it is not intuitive,
because the membership object doesn't have any data of its own.
If you wanted to get the nested data, you can specify which data you
want opt_fields=['memberships.project', 'memberships.section'] in
their opt_fields request. Another option is to use
opt_expand=['memberships'] to get all of the data.
Hope this helps! Let me know if there's anything else I can assist you
with.
On Telegram, every group has a chat-id that my bot saves whenever it is added to a group.
If an owner of a group converts it to a supergroup, will the ID of the group change? And if it does, how can we get the new chat-id for the group?
I've looked for this all over the internet without success, so I'm asking here to self-answer to help people looking for this in the future, saving them the time trial and error took me.
After testing it out for myself, the chat-id does change on migration to a supergroup.
However I found the following way, using python-telegram-bot to keep your chat-ids updated:
def migchat(bot, update):
oldchatid = update.message.migrate_from_chat_id
newchatid = update.message.chat.id
# process those values as needed (e.g. update a database)
dispatcher.add_handler(MessageHandler(Filters.status_update.migrate, migchat))
This uses the Filters submodule to call migchat whenever a chat is being migrated.
This is how the JSON response of the message from the /getUpdates call looks like:
I am connecting to an order session but I get execution reports without ExecID field. I change the requirement to no for ExecID field in ExecutionReport messages from the data dictionary but quickfix still sends reject message. Thanks for any help.
It sounds like what you've changed in the data dictionary makes the ExecID optional rather than mandatory. If you wanted to remove "the requirement" altogether then you'd have to remove the ExecID from the fields making up an execution report in the data dictionary. However, if you did that and your cpty still sent it in the exec report (because it's still configured in their data dictionary) then it would (provided you're using your own DD validation) fail validation.
Why don't you want the ExecID field?
Why can't you ignore it if it's sent to you?
After creating an opportunity, when I click on save, it gives me this warning for some users:
"Operation prohibited by access rules, or performed on an already deleted document (Operation: read, Document type: User Modification)."
What's causing this problem?
Update: I have created a new user of admin type and I added these groups:
Sales/User,Sales/User All Leads,Survey/User,Tools/User. It gives me a warning while creating an opportunity.
I added the following groups to the new user and it's working fine: Employee, PartnerManager, Marketing/User, Accounting/Accountant, Accounting/Invoice, Accounting/Manager, Administration/Access Rights, Human Resource/Manager, Human Resource/User, Knowledge/User, Marketing/Manager, Project/Manager, Sales/Manager, Tools/Manager, trimax/AdminMeeting, Trimax/SalesExecutive, Trimax/Vertical, Trimax/SalesHead, Trimax/SalesManager, Useability/AnalyticAccounting, Useability/Extended, View, Useability/MultiCompanies, Useability/No One, Useability/Product Uos View, Useability/Product Variant, Warehouse/Manager, Warehouse/User, Tools/User, Administration/Configuration
But in already created user if I remove the above groups which give warning ,then also it shows same warning.
The solution I mentioned above was for new users,but for some existing users it was still giving problem. So I removed some unwanted groups, which I didn't needed for those users and it worked, now it does not show warning. Was the warning due to some access right overlap or something else?
Those users probably don't have access rights for the opportunity object, or some child object. Read the access rights documentation for more details.
Update: You said that you're having trouble configuring a new user. As an experiment, try adding permissions to an existing user instead of starting a brand new user. Also, check that you've configured the roles as well as the permissions, that trips me up sometimes.
Another Update: You said that removing some groups stopped the warning. It may be that you have removed all access rules from the object. If no groups are explicitly granted access to something in OpenERP, then everyone is granted access. If you really want to figure out what's going on, I suggest you read the documentation I linked to above. You can also search for the error message in the source code and see exactly what it is complaining about. I find it really helpful to run the OpenERP server in debug mode, and step through the code when I'm trying to understand some weird behaviour like this. You can also try and figure out exactly which change triggers this error by adding and removing groups until you find a single change that makes the problem happen.
Hi these is due to the access right problem .So you give the proper access right to your user(for creating the oppurtunity)
same problem here.I'm using Multi-company, I provid all permistion to the user