Parent field readonly while linking excel to ADO - azure

I have linked ms excel to ADO using the plugin and I'm able to everything except for updation of parent story ID field ( column) . That field for me is coming as read only. The message I get is "TF84013: you cannot modify a field that is read-only or a work item that restricts updates to valid users based on current conditions". What should I do to fix this?

The Parent-Child link types are supported by the Tree list. I tested with tree list type and the parent field is modifiable.
You can refer to this document.

Related

Extending Kuali Document Business Object

I am facing an issue with extended attributes on a document (trying to extend a document table). I created the original table’s PK (FDOC_NBR) in the extended table and linked the two via a foreignKey of the customized original table’s ojb entry (as an “extension” reference-descriptor). I created the bo and dd for the extension and customized the original document’s dd to add the new attributes. On the extended BO itself I also added members (with setters and getters) for the 2 new columns + for the PK column of documentNumber. I also added the new attributes to the documet’s jsp. The pertinent module definition was already extended to include custom dd, ojb, etc. files.
Indeed, when opening the document the new fields are shown- however, when trying to submit the document (regardless of doing anything with the new fields) I get an error-
Error Details: OJB operation; SQL []; ORA-01400: cannot insert NULL
into ("KFSTEM"."TEM_TRVL_ARRANGER_DOC_EXT_T"."FDOC_NBR") ; nested
exception is java.sql.SQLIntegrityConstraintViolationException:
ORA-01400: cannot insert NULL into
("KFSTEM"."TEM_TRVL_ARRANGER_DOC_EXT_T"."FDOC_NBR")
Seems like somehow the system tries to insert a value of NULL into the extension’s PK field, instead of the actual document number. Trying to debug this, in the action’s route method and all the way down to DocumentDaoOjb.save (which is as far down as I can go) I see the document with the real doc number is passed on, so the problem seems to be purely with ojb trying to set this number to the extension table.
Does anyone have any experience with extended attributes on documents that could help shed some light on this?
KFS is using the KNS, and in the Kuali Nervous System, the primary key on the extended attributes object must be set through manual intervention.
In this case, it looks as if you're adding an extended attribute to a transactional document, the Travel Arranger document (TAA), which simplifies things. Basically, you'll need to extend org.kuali.kfs.module.tem.document.TravelArrangerDocument and override prepareForSave to set the document number there (it may be set already since prepareForSave should be called several times during the routing process, but there's no real harm from overwriting that information as the base document's number will remain the same).
Hope this helps!

Pulling custom field into Rally Query

I am creating a Query using the Rally/Excel plug-in. I am creating the report with a base type of Task but want to include User Story information in the Query.
I have been able to do this before by adding "WorkProduct.Release" into the columns listing. That works no problem. When I attempt this with a custom field named "CR#" I get no contents being returned.
I am able to pull custom fields from the Task itself without issue it just appears to be an issue when pulling from the parent object.
I have verified the field name and that the content is actually populated. Does anyone know a way to pull this data via the excel plug-in or if there is a limitation with pulling custom field information from a parent?
In Web Serivces API Workproduct attribute is Artifact. Artifact is a parent of Task, HierarchicalRequirement (user story) and Defects, and other work item types. Those types can have custom fields created on them, but the parent Artifact is not aware of them. It is not possible to traverse from Artifact to a custom field, and it should also not be possible to traverse to Iteration or Release from Artifact. Those fields do not exist on Artifact object in the API. It is possible to traverse Workproduct.FormattedID because FormattedID attribute exists on Artifact. That's where work item types inherit the FormattedID from. If I use Workproduct.Release or Workproduct.Iteration in Excel plugin in a query on a Task object following this syntax:
(Workproduct.Iteration = /iteration/12352898163)
I get this error:
(Workproduct.Iteration.Name = it123)
will produce a similar error.
I put this to the Rally Support folks and got the following answer, so the short answer is no...can't be done:
When you query using WorkProduct.FormattedID on a task, the data can
be returned because that field is part of "Artifact". You can see
this by looking at the Web Services API information, which I have
included some screenshots to illustrate this. The custom field you
are trying to query doesn't reside on Artifact, so is not found by the
query.
The actual work product that has your custom field would be either a
defect or a story, but the Task object does not reference back to that
to allow you to query.
You could do another query for the different work products and include
the custom field, then combine the two worksheets.

Sharepoint Extenal List and Custom Field Types

I have an odd issue.
I have client that wants a sharepoint list what is populated from a WCFService. That part is working quite well.
I have a bdcmodel that is mapping the WCF data and I can create an external list from the bdcmodel as well so that is working fine.
The issue I have is that one of the properties in the model is actually a collection of entities called Attributes. The objects in this collection simply have 2 properties Name and Value so really they are just a key value pair.
The client wants to see the list of attributes of the parent entity in the external list. So there would be an Attributes column and within that column would be the list of attributes for each parent object.
Is there even a way to do this? I am looking into Custom Field Types, but it seems like these are really intended to be singular values.
How would I create a list within and external list?
Any help anyone can give would be great even if its just to tell me that there really isn't a stable way to do this so I can go back to the client and tell them we will need to build a custom list to support this because the OOB external list and custom fields and custom field types won't support this kind of nested listing.
I decided to set up the custom field as a string and when I get my collection in from the BdcModel I am serializing it to JSON and then passing it to the field. When the field is viewed in display, edit or new I have overridden the FieldRenderingControl and I am tiling the collection out that way.

Sharepoint lookup field and WebId="

I try to add lookup field in content type. Field has this definition:
<Field ID="{c80e8e3c-7124-4772-a39d-5b69f131d542}"
Name="Site"
Group="Tieto Intranet Columns"
Type="Lookup"
DisplayName="Site"
StaticName="Site"
List="Lists/FavoriteSites"
ShowField="Title"
PrependId="TRUE"
WebId="~sitecollection"
>
FavoriteSites list, which I want reference by this lookup field, exists on the site collection scope. Deployment goes fine, but when I create list based on content type with this lookup it looks like that lookup field is not connected to FavoriteSites list. I add some data into FavoriteSites and than I a try to add something into second list with lookup field on FavoriteSites. Unfortunately drop down select, which should show me data from FavoriteSites list is empty.
When I create new lookup column to FavoriteSites manually everything is OK.
Do anybody have some idea where can be problem in this lookup definition?
UPDATE:
As Rich recommended me, I set log level on Verbose a find this message:
The WebId=~sitecollection and List=Lists/FavoriteSites attributes specified for field {c80e8e3c-7124-4772-a39d-5b69f131d542} in feature {d86c7005-d31d-43ae-b86b-38f28b81072e} could not be found. Set List={39CEC23E-FB28-47B3-BC36-C21780AD1D94}.
I don't understand it because list FavoriteSites exists. FavoriteSites list and also second list with Site field are deployed by one feature on site collection scope.
I can't specify list in lookup by GUID because I don't know the guid in deployment time.
What that log message means is that Lists/FavoriteSites does not exist in either the site collection root site or the site where the feature is being activated (if the latter is a subsite).
If Lists/FavoriteSites is being created by a feature, then make sure that it is activated before your Fields feature. Put the ListInstance element right above your Field element if you have to. But the message is clear: the list does not exist at the time that your custom field is being provisioned to the site collection. And that is why it is not working.
To be clear, the list has to exist at the time that the feature is activated, not just when you create a list instance that will use that field.
P.S. I found this by checking the "documentation" for the Microsoft.SharePoint.SPFieldElement.PerformFixUpIfLookUpField method.
Try changing the list field to the ID of the list e.g. List="{4641f5f2-b358-4805-9d7d-e910d2243fb5}"
I would also recommend using SharePointManager to look at the Field definition of your manually created field and to easily find the blooming guids of lists etc.
I had the same problem. In the end my problem was that you can not declaratively reference a list that is in the rootweb. The ~sitecollection token in the WebId property is not working because it will write the Guid between braces, while SharePoint expects it without braces (explanation can be found on http://martensboarterstun.wordpress.com/2013/06/15/how-to-create-a-list-definition-with-a-lookup-field-declaratively/). I ended up placing the Rootweb ID in my list definition.

Cascaded ListBoxes using SPFieldMultiChoice - issue defaults to default Content type

I wound up modifying the source from a publically posted POC: http://datacogs.com/datablogs/archive/2007/08/26/641.aspx, which is a custom field definition for cascading drop downs. The modifications were to allow parent-child list boxes where a user can multiselect for filtering and selecting the values to be written back to a SharePoint list.
I got the parent-child cascading behavior working, but the save operation only takes the default Content Type value.
I changed the base type for the custom field control from "SPFieldText" to "SPFieldMultiChoice", along with changing the FLD_TYPES field definition values from: "Text" to "MultiChoice"
Steps Explained:
1. The custom field is created which is derived from ‘SPFieldMultiChoice’ class. The custom field allows multiple values to be selected.
2. The Field created using above custom field is added to custom content type created from GUI derived from ‘Document’ Content type.
3. The custom content type is added to the document library.
4. The document is uploaded and custom content type is selected and tagged to document.
A. The correct content type gets tagged with correct metadata if type of document is .xls,.doc,.txt etc
B. The default content type i.e. ‘Document Content Type’ gets tagged if type of document is .xlsx, .docx.
Issue Summary – Point#B: is an issue as correct content type is not tagged and default content type gets tagged if type of uploaded document is .xlsx or .docx.
However same content type , same custom field works if type of document is .xls or .doc.
Appreciate your inputs in this regard.
Thanks for taking the time to read through my post.
Cheers, ~Poonam
Not sure why this is happening, it might be a good idea to notify Microsoft of this behavior. The difference between .doc and .docx you describe is very, very strange. Could you try setting the content type in an itemeventreceiver, to force the ContentType or ContentTypeId field of the item to reflect the correct content type explicitly.
i.e.
item["ContentTypeId"] = new ContentTypeId("0x010100your_id_plus_the_part_added_by_list");
the_part_added_by_list is the extra guid that is added when a ctype is added to a list
this is because ctypes in a list are basically children of the actual ctype you added
i.e. 0x010100 YOURGUID 00 LIST SPECIFIC GUID,
you can get this full id using a tool like Stramit CAMLViewer, or progr. by looping through the SPLIst's ContentTypes collection.
(my guess would be to do this in the ItemUpdating / ItemUpdated event to see if there is a difference in ctype during those calls)

Resources