what is the diffrence b/w dls:document-add-properties and xdmp:document-add-properties as both do same work in properties of a managed doc in Marklogic??
I use both one by one on a managed doc but they give the same result.
DLS uses the properties fragment to manage the DLS information. This is stored in document properties under the DLS namespace. Clobbering this information would make the DLS feature fail.
The version dls:document-add-properties() and associated calls fail if you try to write properties to the DKS namspace - this protecting the integrity of the system.
I would not use the XDMP version on DLS. Further to that, I would have the system with much tighter security on roles for which a DLS user's role really only had execute permissions for the DLS functions and not others that are not needed.
In addition to David's correct answer, dls:xxx code further guarantees that operations are made only on dls managed documents, that they are locked for update during the process, that the calling user has DLS permissions on the document, that the properties are valid and non-conflicting with dls internal properties.
Related
I'm getting an error when uploading my customized policy, which is based on Microsoft's SocialAccounts example ([tenant] is a placeholder I added):
Policy "B2C_1A_TrustFrameworkExtensions" of tenant "[tenant].onmicrosoft.com" makes a reference to ClaimType with id "client_id" but neither the policy nor any of its base policies contain such an element
I've done some customization to the file, including adding local account signon, but comparing copies of TrustFrameworkExtensions.xml in the examples, I can't see where this element is defined. It is not defined in TrustFrameworkBase.xml, which is where I would expect it.
I figured it out, although it doesn't make sense to me. Hopefully this helps someone else running into the same issue.
The TrustFrameworkBase.xml is not the same in each scenario. When Microsoft documentation said not to modify it, I assumed that meant the "base" was always the same. The implication of this design is: If you try to mix and match between scenarios then you also need to find the supporting pieces in the TrustFrameworkBase.xml and move them into your extensions document. It also means if Microsoft does provide an update to their reference policies and you want to update, you need to remember which one you implemented originally and potentially which other ones you had to pull from or do line-by-line comparison. Not end of the world, but also not how I'd design an inheritance structure.
This also explains why I had to work through previous validation errors, including missing <DisplayName> and <Protocol> elements in the <TechnicalProfile> element.
Yes - I agree that is a problem.
My suggestion is always to use the "SocialAndLocalAccountsWithMfa" scenario as the sample.
That way you will always have the correct attributes and you know which one to use if there is an update.
It's easy enough to comment out the MFA stuff in the user journeys if you don't want it.
There is one exception. If you want to use "username" instead of "email", the reads/writes etc. are only in the username sample.
When I try to switch to edit mode for a Report source, a popup comes up telling me
"A new task will be created for the following request of user XXX".
A transport request is also being suggested.
I don't want to save my changes in this request however, but in another existing one. I am not aware of any versioning systems being implemented in my system, and don't know how to check that.
Is what i'm trying to achieve possible? And if so, how?
No, this is not possible. There are very good reasons for this being an exclusive lock -- reasons that you should know about before you attempt to change anything. Briefly speaking
The CTS only notes that an object was touched, not what change was made.
When the transport is released, the entire object in its current state is exported - there is no delta/diff logic involved.
Therefore you can't separately transport changes to the same development object. Furthermore, if you serialize this manually, the second transport will always comprise the changes of the first one.
Things get slightly more complicated with partial objects - you can have LIMU METH objects (methods of a class) in different transports, but as soon as you try to lock the R3TR CLAS main class, you'll have to resolve that.
I have a custom object with a master-detail to opportunity. Is there a way to determine if the user has read or read/write access when querying this custom object?
To clarify my needs, I'm looking for a way to render my page (non-visualforce) with a clear distinction between records they have only read access to and records in which they may edit.
The user will have the same access to that as they have to the opportunity. The Profile object exposes permissions but it doesn't appear to allow you to find out about CRUD settings for objects.
Are you creating an integration piece or working with Visualforce? If you're using Visualforce the interface will respect security controls automatically, hiding data they're not allowed to see and making fields read only when using <apex:inputField> if they do not have permission to write to the field.
** Edit **
Maybe somebody will have a better solution, but how about trying to update the records you query, storing whether each was a success or failure, and then using that to control the interface? Bit of a hack, if I find anything else I'll be sure to update.
** Edit 25/01/2012 **
Have just come across this: http://www.salesforce.com/us/developer/docs/api/index_Left.htm#StartTopic=Content/sforce_api_objects_userrecordaccess.htm?SearchType=Stem
Pretty sure that'll give you exactly what you need!
This might contain answer to your question http://salesforceblogger.blogspot.com/2012/04/query-user-access-level-in-apex.html
There is an UserRecordAccess table which is exposed with API 24.0 with which u can easily check for access instead of banging ur head with share object.
I don't know of a way to query to find out the level of access however if your apex class uses the With Sharing keyword it will respect sharing on the object thus when you attempt to update the data you'll get a DML exception which you could catch.
If you're not using With Sharing then apex doesn't respect the Sharing model and technically the user will be able to update the data even if they don't have access.
As pointed out by LaceySnr if you're using visualforce the <apex:inputfield> element will display read-only automatically to the user if they only have ReadOnly Access.
I'm in the process of building a plugin that includes a behavior and several related models. My goal is to make this as easy as possible for the developer using the behavior. My perfect world has the dev simply attaching the behavior to any relevant models and configuring it.
The behavior interacts directly with one of the models and a hasOne association is being created on the fly, but the other models contain supporting data that is important. What I'd like to do is to have that model pull in its related data by modifying the Containable models.
In short:
MyModel (which actsAs the behavior) gets bound to top level model during the behavior's setup method.
The supporting models are directly associated to the top level model
In MyBehavior::beforeFind, I'd like to ensure that supporting model data is returned without the user having to know to ask for it when calling MyModel::find( ... ).
I haven't found the right keys that will allow me to modify these things at runtime. Maybe it's not even possible given that I want to essentially interact with another behavior (Containable).
Any thoughts would be appreciated.
This code automatically adds some contains to the find before it is run, you just have to make sure that your behavior is attached before the containable behavior or it will not work. The beforeFind callback for a behavior is only run once, so once containable has been called adding something like this does nothing. Took me a while to get it going because of that.
https://github.com/infinitas/infinitas/blob/dev/core/contents/models/behaviors/contentable.php#L65
Using parent child relationship where a parent can have children while each child has only one parent, does using Children.all().ancestor(parent.key) a good solution where a child is constructed by setting parent=parent.key in the constructor? Is the 1000 limit applies with this kind of query?
The query returns what you'd expect, all Children which have the specified parent anywhere in their ancestry. The query expresses exactly that, so I doubt there's a simpler way of doing the same thing. But App Engine does keep adding features and surprising me :-)
Possibly you need parent.key(), I think it depends whether you're in Python or Java.
Btw, it's not recommended to use ancestor-parent-child to model relationships in your data. Entity groups exist to enable transactions, not for use as a "free" ReferenceProperty. parent-child should be a low-level implementation detail, meaning either "these two entities may need to be modified in a single transaction", or perhaps "I am playing an optimization trick which allows me to use list properties without having to load the list into memory when I get the entity". As a rule of thumb, if the entities don't all "belong" to the same user, then they shouldn't be parent-child related, because relating them in that way introduces contention when different users try modify them via different datastore nodes:
http://code.google.com/appengine/docs/python/datastore/keysandentitygroups.html#Entity_Groups_Ancestors_and_Paths
Another way to get descendants (children) of a parent entity in Google App Engine that I just discovered:
childrenEntities = db.query_descendants(parentEntity).fetch(1000)
Not sure if it will be helpful to you. It was helpful to me because I was having difficulty figuring out how to access the child class(es) which were created with a python module I installed.
As others have indicated elsewhere, the 1000 limit for everything was removed in February 2010. See the linked blog entry for more details re: this.