There are many complex resources in oneM2M with nested attributes e.g. subscription, group etc.
If an UPDATE request is sent to update a nested attribute e.g. eventNotificationCriteria>missingData>number of subscription resource then all other existing eventNotificationCriteria (if present) should remain intact including duration in missingData and only number should be updated.
Is this how the nested attribute UPDATE should be handled?
This is correct. The CSE must take care only to update or create those attributes that are listed in the UPDATE request, and leave all others untouched.
You may check TS-0004 "Service Layer Core Protocol Specification", section "7.3.3 Hosting CSE actions" and especially section "7.3.3.7 Update the resource":
Attributes that are not included in the Content parameter of the addressed resource shall not be changed by the Hosting CSE.
Please note, that when attributes of a resource are updated some (usually read-only) attributes that are managed by the CSE may be updated as well, e.g. the lastModifiedTime attribute. Also note, that even when an update value is the same as the value of the attribute, the update is performed nevertheless (including the update of the lastModifiedTime attribute).
Related
I have a new Windows Application that I am adding Application Insights to. Adding a new chart gives the ability to Group on specific custom properties using a drop down. This drop down has 65 properties that AI must have added at some point. There were not specifically added.
We have a main AppInsights that takes all events. We've also created a AppInsight for development. The list of custom properties in the drop down is different between these two, even though the source code is the same.
It makes me suspect that there is some process that creates the drop down contents based on the incoming data.
The problem here is that the code has changed, and some properties are no longer available. We want to eliminate these values from the drop down, and add the new ones.
I am perfectly happy just deleting the entire list. Is there a way to do this?
The items that are available in the group by are properties that have ever been received by the back end in data you've sent, and aren't editable.
for custom properties/metrics, there's a limit on how many properties the backend will allow before it stops collecting new named custom properties. Conceptually, think of it as the backend storing an array of 200 elements for each telemetry item you sent, and mapping each custom property name to an index, and that mapping lasts forever. (i believe at the current time that limit is 200 each, but we're working on expanding that)
so if developers did things in your dev portal, even sent one item with custom property "foo", then that property will be there forever, and takes up one of those 200 slots. They can't be deleted or cleared at the moment.
Also, the contents of the group by box is also limited to events that have sent less than some threshold of distinct values, too. (I'm not sure on that exact value, but i believe it < 100 distinct values.) So fields like Id fields, or guids, etc, will eventually stop showing up as group by options, because the group by would create N distinct buckets of 1 item.
It seems like this would be something already mentioned in the App Insights UserVoice site, or documented in the azure documentation for group by but i'm not seeing it.
The only real workaround at this time is to create a new application insights resource in azure, and start submitting data to that new resource instead of your old one. And then you have to be proactive about never submitting custom properties that you're never going to use, or mixing case, as "Property1" and "property1" will be distinct properties...
If this is a big issue for you, i'd suggest submitting it to microsoft connect as a bug, or entering a uservoice suggestion above. I'll pass this on as something that really needs to be documented in the group by thing in the azure docs, too.
I know there are a lot of questions about the delete rules of Core Data relationships, but I didn't find an answer to my "problem".
In my Core Data Model, I have a many-to-many relationship between the CDMTransaction and CDMTransactionTag entities (CDMTransaction.tags <<->> CDMTransactionTag.transactions). Each transaction can be linked to zero, one or more tag, and then every tag can be linked to one or more transaction (or zero, but this doesn't make sense to keep it, and this is what I'm working on).
So when I delete a tag (will a "Nullify" delete rule), it is removed from the transactions that had this tag. This is OK.
But what I would like to do, is when I delete a transaction and its linked tag(s) remained unused (CDMTransactionTag.transactions.#count == 0), this/these tag(s) should be also deleted.
Can I set a "Cascade" rule for the CDMTransaction entity? It would delete all its linked tags, even if they are still linked to other transactions, no?
Am I forced to do that programmatically?
Thanks!
Edit: in fact, I just would like to delete the CDMTransactionTag instances when their .transactions.#count == 0 (so it shouldn't be checked only when I delete some transactions, but also when I change the tags of a transaction).
Don't know if you are still pursuing to a solution within your desired scope.
I'm dealing with similar issues and would like to share my findings so far:
Among the delete rules, only cascade will delete the object(s) (e.g. in your question: your *Tag entity instance(s)) at the relationship (1st) destination,
it does delete the destination objects even if they are "still linked to other transactions" unless...,
unless the "linked to other transactions" is a relationship(2nd) with delete rule of deny,
because only deny rule can prevent source object to be deleted when there is at least one object at the relationship(2nd) destination among the rules; and,
the delete rules are to specify what should happen if AN ATTEMPT is made to delete the source object, (i.e. the moment just right before the possible source object deletion occurs).
I have not yet tested the above design for the similar issues but I will try and post the result later if I may see some ongoing activities to the post.
I have 3 business units (1 parent and 2 children), 3 users (for each business unit), 2 forms (for each business unit) and 1 plugin for the incident entity.
The incident plugin (create, pre-operation) is setting a default value in the attribute 'Case Origin' (caseorigincode) depending on user's business unit.
My problem is what if the user of the parent business unit creates an incident? how the plugin knows from which form that incident is created to set the default value?
What is the best approach to do that?
Thanks.
Unfortunately I don't think there is a way for the plugin to know which form was submitted. However, you could add a hidden field that gets set via javascript to something different for each form. Then, in the plugin you could query that field to see which form was used.
Be sure to check for null/empty as well, because the update could have been submitted programmatically without the use of a form.
IIRC all CRM entities (both stock and custom) should have a OwningBusinessUnit attribute which is an EntityReference to the Business Unit the record's Owner belongs to.
That should tell you exactly from which BU the record is being created.
(NOTE: The question is inconsistent, since it is stated that caseorigincode is set depending on the BU at first, then it asks about forms. I assume the first is the actual logic: check the BU to set the field)
(NOTE #2: This could be accomplished through a workflow aswell: Check Condition on Owner's BU and Update Record accordingly. Run on create.)
Given a user can only be a member of one business unit then you shouldn't need to worry about which form it was created in. Simply get the SystemUser from the EntityReference of the created by user and use the BusinessUnit EntityReference that provides you with.
Is it possible to validate the Xpage's ACL depending on the Source document's field value.
We need to make the Authors & Readers ability at XPage level (as per requirement I am not supposed to use the ROLES, since, it is dependent on each individual Authors which is stored in backend document FIELD).
Kindly suggest the approach, as I am not even looking HideWhen for the Buttons(edit,save etc)
Example code in the ACLEntry[0] in Xpage:
if getComponent("inputText1").getValue() == sessionScope.user {
session.getEffectiveUserName();
} else {
return false;
}
Thanks.
I do not quite understand your code on that property...
To query the readers/authors level at XPage level I suggest to use the database.queryAccess method (http://www-10.lotus.com/ldd/ddwiki.nsf/dx/NotesDatabase_sample_JavaScript_code_for_XPages?opendocument&comments#queryAccess)
You try to compare the username only. This may fail if your access level is computed by a membership in a group where your username is not relevant.
XPages' ACL depends on the database ACL, so you have to setup the levels there - the XPages' ACL is in addition to the "real" ACL as far as I experienced.
I also experienced that readers fields affect the ability to use an XPage to open a document by default.
I hope my answer is not too confusing ;-)
I think the question is valid (to my current knowledge):
If I want to design a workflow application but the current approver should not edit the full document I want to give him only access to parts (ie. a comment field and the approval button).
The question above relateds somehow to access controlled sections in old LN development. I so far also didn't find a good solution
What you describe is a very common workflow scenario. There are several ways how you can implement that efficiently. Here is what I would do:
Have one (or more) custom controls that render the "payload" (the fields the requester fills in)
assemble them into one bigger control that is used to render the form
compute the mode to read/edit depending on who is opening the form and the mode (new, pending approval, approved, rejected etc.)
Optional: when submitted remove submitter from the author field
Have one "Approval Control" that show only when the current user is the (current) approver and status is "pending approval" That control has fields that are NOT bound to the document, but a scope variable
The approval button triggers SSJS that takes the scope variable values and updates the document (and triggers notifications, access change etc)
The approval component can be used for any approval form. You then can contemplate not to give the approver write access since you could handle that in code.
What I need
I have a custom Entity with that with multiple fields. Admin Role has "god" access. All other roles except for one have read only. The one non admin role with update access, should only be able to update a single field.
What I believe to be true
I believe I have three main options to implement this requirement:
Enable Update Access to the role for that entity then write Javascript to disable all fields on the form for that role, except for the one that I want that role to be able to edit
Enable Update Access to the role for that entity then create a new form that disables all fields on the form for that role, except for the one that I want that role to be able to edit.
Enable Update Access to the role for that entity then turn on field security for each field, disabling access using the field security, for each field except for the one I want them to edit.
What's the Best Practice?
What options should I choose?
If I go with options 1 or 2, will the user be able to edit the field on the bulk edit form?
From a user perspective, I think it's confusing when a form opens up with things enabled, then they get locked down. Plus someone could possibly get data in there before the fields get locked. I'd say you'd have to combine this with a plugin to prevent changing fields you don't want changed.
I like this option better, although again, the field can be unlocked if someone knows what they're doing, so a plugin to double check would be nice.
This would avoid having to double check in a plugin, but you also have to rely on the admin correctly setting up security for new fields going forward. If that's not a concern, this might be best.
Bulk edit is a global privilege, so they'd have bulk edit for all entities. Also, the bulk edit form does not load scripts, so that knocks out option 1. I'd say if it's just this one field, I might leave the privilege locked down and provide my own Bulk edit button on the grid that would show a custom page that just has that one field on it, then handle the updates though script.
2 is most likely best, or as an alternative put the fields in the header or footer rather than as read-only fields on the form.
This also means the fields won't be available to bulk edit, but other methods such as data import or workflows would let users get round this if they know how and have rights to do such things.
3 Field Security is the most robust and works for all scenarios
Possible option 4: create another entity to contain those fields and apply different security to that entity. If created as a child, show the record in a grid on the form with the values included in the view. If it is a parent then you could use methods such as showing the values via an HTML webresource page included on the form.