I have created a workspace dashboard, and the reprompt value on the widgets keeps defaulting to the last value the workspace was run on. Is there a way to keep that from autosubmitting on the last value or defaulting to null?
We setup a saved read-only version of the dashboard for users to view. It had all the preferred defaults saved. If users wanted to make changes they had to save a copy in their own space, so their prompt changes would only affect their personal copy.
Related
I've struggled with this issue my entire Acumatica career. The customer asks for a custom field made for a base Acumatica page. They give me the data type of the field. I create said field. The customer decides to change the spec which in turn changes the type on the field. I change the field type in Data Access, but it doesn't work. I change the field type in every place I know to find it (Data Access Class, .XML, CustObjects), the field still contains the same properties! I delete the field completely, run a clean publish to make sure it gets wiped and recreate the field with the same name. Nope! Some how the old type still remains assigned to that field. I have even completely deleted the project, ran a clean publish, recreated the project with the same name, ran another clean while empty, recreated the DAC object with the same name, ran ANOTHER clean publish, and it STILL has the old control type despite not being set in the project XML or CustObjects table.
How do I change the field type of a Usr field created via the Data Access section of the Customization Project?
My current solution is I just append a 2 to the name, so it becomes UsrFieldName2, which I really don't want to keep doing because this will mess up reports and anything else directly linked to that data field.
I was recently tasked with modifying a Lotus Notes application in my workplace.
Before starting I created a new replica of the live program into my PC drive using Replication > New Replica option.
After I modified it and entered some dummy data, I went back to check on the live program. Only to notice that not only did my dummy data appeared in the live server, but also the form design that I modified replaced the live design (luckily I just added some fields, so its no big issue).
Naturally I deleted the dummy data from the live version view. And when I come back to my test version, when I try to delete the exact same dummy data, I get an error saying
Document locking is enabled. You must lock the document before deleting.
So I did that, which gives me another error saying that document has already been deleted. Meaning that although my original form data was deleted, the view data still remains in limbo. I can open it and see the form's content, but I cannot edit it anymore.
I was lucky that I deleted the dummy data through the live version, but now I want to delete the same data from test version.
Is there anything I can do to fix this?
Important note: If you need a test database which is completely separate to any live database, don't create the test database as a "new replica". Create it as a "new copy" instead (in the Notes client, use File -> Application -> New Copy).
Making your local database as a new replica means that it replicates changes between the local file and whatever server you replicated it from.
Most likely, your Notes client had been previously configured with scheduled replication enabled, so any changes (in either design or data) made in either the local database or server database are automatically replicated to the other. I can't tell you how often it replicates, since that's a configurable option, but it's probably once every few minutes.
In the case of your "already deleted" document, the deletion in the live database would have been replicated to the local database. To make the document disappear locally, simply close and reopen the database (but if prompted to delete documents currently marked for deletion, choose No).
Edit...
Another thing to try to make the local document disappear is manual replication. You can get a list of local database replicas via what the Notes calls the "Open List". This appears by default as an "Open" button immediately below the File menu, or its contents may appear in a vertical bar down the left side of the Notes window if you've ever chosen to dock the Open List.
In the Open List, click the "Replication and Sync" option. Its icon is two curved arrows that almost form a circle.
"Replication and Sync" lists all databases for which you have local replicas. To immediately replicate just one database, find that database title, right-click it, and click "Replicate Selected Application".
If the database is currently open in Notes when replicating, you may also need to manually refresh the view to make deleted documents disappear (the F5 and F9 keys should both refresh the current view, but you only need to press one of them).
When I create a new record on the Service Request (SR) application (Maximo 7.6), I would like to set the required Reported Date (SR.REPORTDATE) field blank. Before save action, the user will input data into that field. I wonder how this could be done?
Thanks for the help.
If you look in Database Configuration to see if REPORTDATE has a Default Value, I think you'll find &SYSDATE& in there. If I'm right, then you can delete that default value, save your changes, and apply your changes. Otherwise, you'll need to do as #Dex suggested.
My mind immediately goes to an automation script. A default value control or the default value setting in Database Configuration may work too and is recommended before a script if you have the expertise to confirm or deny this theory.
As for the automation script, I think you can create one with an object launch point on SR on the "add" event. The script would simply set that field to null, which shouldn't change the "required" flag either, so the rest of your needs will still be met.
mbo.setValueNull("REPORTDATE");
In Kentico, is there a way to know the date the content was published for the first time? In the view_cms_tree_joined view there are fields called DocumentLastPublished and DocumentCreatedWhen but the latter is populated when the user save the content initially even if it's not published and the former is updated when the content is republished. Should I look at the workflowversionhistory?
You'd have to look through the workflow history for that document and get the initial publish state. If you don't want to do that (might be pretty messy and lengthy) you could always add a field to the page type for an initial publish date which will allow someone to add that date or default to when it is saved and not allow it to be editable after it is saved by using a macro on the enabled property of that field.
I have a requirement to disable the integration between Sharepoint and Word in a project that I am working on. This requirement comes from the request that the user is able to edit the properties of the document but not edit the document itself. The request has also been made to disable the Shared Workspace toolbar that appears when a document is open. The solution must exist on the server as some of the users are external. The users have also requested that they are able to use the Outlook/Sharepoint Integration. Does anyone have any thoughts on how this can be accomplished?
I'm guessing they want to change some document properties, apply those as new field values and print - but not change the original.
Here are some ideas, not sure how useful they could be.
1) apply a password for editing the Word document - It may still allow changing properties & printing.
2) strip out doc the properties and put them in a sharepoint list, with the document itself as an attachement - the document then remains as read-only, but the properties are held separately
3) If your documents are in a list, Allow changes on the list, but demand changes be approved, so users only get to see their own changes, no-one else sees the changes they made. Changes will sit there pending approval. Periodically you can go and reject any changes.