I designed a site in share point. There is a column called "Issue ID (linked to item)" in ALL Issues view. I am using this column to list and identify the items which are created by employees. It increases by 1 as a new issue is created. Unfortunately, I have to reset this ID to 1 because during the test period I created and deleted blank issues. Although they were deleted, the share point increasing Issue ID from the last deleted issue (89).
Is there an easy way to do this? how can I reset this auto number? I need to reset this counter as soon as possible without any risk...
Do you kindly help me? I would be glad if you explain it in detail.
Thank you,
If your Issues list wasn't heavily customized and nor referenced by GUID in any custom code, the simplest and most supported option would be to recreate it with the same name after deletion as a customized template you could have saved without contents from list settings page before deleting or as a standard Issues list.
Related
Where does the code that makes a PX Formula work exist? I at first assumed it was a SQL Trigger, but I can't seem to find it there. This is why I ask....
I've added a custom field to the SO, called usrSpeedyTotalExt2. I'm trying to get that to sum the SOLine.CuryLineAmt. I added attributes to the SOLine DAC to append the follwing:
[PXFormula(null, typeof(SumCalc<SOOrderExt.usrSpeedyTotalExt2>))]
This seemed to work, but know I'm fining that the value is consistently twice as high as it should be. I've got a second field that's doing the exact same thing.
What's increasingly odd is that I had the same problem with the field, and I thought I had done something wrong so I deleted the PXFormula, created a new field and then added the PX Formula to populate the new field. As such, there shouldn't be any code populating the old field, but strangely it's populated, so there must b e some business logic that's stuck and somehow still populating it.
Any thoughts on how I track this down?
I believe that I figured out the problem...I think that the code may have been imported and published on more than one company, then published from the proper company to multiple tenants.
My fix was to go to the live company, un-publish all, then go back to the company the customizations live in and publish to the appropriate tenants. It would appear that now I'm only getting the proper totals. IDK how that might have happened, but at least it appears to be fixed.
I have removed sharing from a record in CRM manually. It is not shared via cascading rule eather, but it remains in Principal Object Access table. As I can see, the script for controlling growth of POA, published by Microsoft, deletes only rows with object ids which er deleted from CRM, can't see logic which removes those unshared records.
Does anyone know if CRM contains logic for this at all? Has anyone had experience with deleting those rows despite of being unsupportet action?
Thanks in advance
I can't tell you very much about how the POA table is populated or cleaned up, but I can tell you how to delete it:
http://dotnetdust.blogspot.com/2014/01/lessons-learned-deleting-312-million.html
Sharing also present for some entities even you can't see it in UI. Implicit sharing is created during entities merge or for email activities when there are different users in to:, cc: fields, for workflow logs, process sessions, etc.
I wrote short article about it: http://tunnik.name/principalobjectaccess-table-clean-it-up-fast/
It has links to other articles which can help dig into that subject.
If I create a new Account Advanced find view I am finding some very odd behaviour.
I follow these steps:
Create new view for Account
Go to Criteria
Criteria has been prepopulated as below
Which is odd on its own - why prepopulate?
Anyway, if I then add something, say Status = Active , it duplicates the first criteria as below:
Other than 'your server is FUBAR'd' - anyone have any ideas what could be causing it?
edit: if I export, the XML does not show the duplicated filters as below shows:
Reply received from Microsoft. A colleague has verified this and found it fixed the issue in our case.
A filter had been applied to the default view for Account (I must admit I wasn't aware of this!).
When you click to create a new view, part of the code executed retrieves the current default view and uses that as a template.
Removing all filters on the default view therefore solve this issue.
I'm not quite sure why it should have had the affect it did when adding new criteria, but I think I'll choose not to think about that!
I have read many posts that say the automatically assigned list ID number in Sharepoint 2007 does not change.
It is very important that the list items in my sharepoint site stay in the same order as when they were originally created. My initial image was that I could sort on the ID # to keep the list in order (since it wasn't supposed to change). It has not worked out. I have noticed that the ID changes and my data gets out of order.
Could anyone please explain to me how the automatically assigned ID # works in Sharepoint 2007? How/When is it assigned, reassigned? Is there an action that causes the # to change?
When a workflow runs does Sharepoint reassign the item w another ID#? I do have several workflows running on this site.
A list item id is just like a SQL identity column. It is automatically incremented, is (or should be) unique within a particular list and doesn't change. Are you able to identify a point in your process where you are seeing an id change?
maybe you can take a look at the back-end sql server, there is no way you can manupilate it on user interface or object model as i know.
We need to fetch the items added/updated after the user's last visit.
We need this information from 3 separate lists under the same web.
Pointers on how to accomplish this would be very helpful (and does SharePoint provide any API for this).
Kind regards,
Filtering by modified date is straightforward enough, though the method will depend on the type of view - the tricky part is getting the last login time - you're probably going to need a bit of custom code to save that.
Brute force would be to run a foreach on every version until you reach a version before the users last login date, and do this on every list item, and then again on every list. You can see which fields changed this way by seeing what changed between versions. You can narrow down the the set of items to do this on by only querying for ones with a modified date since the users last login
As for finding the users last login, sorry I can suggest anything for that. I've not looked for it before.