I've got an events channel set up on a client site where everything is working just fine. However they now have a single event that runs every Sunday. Due to using the start_on parameter to only show events from the current month onwards this recurring event is now displaying a blank page.
Is there a simple way to have the entries publish date automatically updated to the current month or somehow display recurring events correctly. Client is unwilling to spend money on a new module such as Solspace Calendar.
You could set up a cron job on the server to run a PHP script which would modify the entry date on your recurring entry.
Yeah I see your dilemma, Sean - separating the event from its month and year (year in particular) to have one even display multiple times... What about using MX Clone to simply allow them to create multiple instances of the same entry (granted, they'd have to adjust the date for each one too, but that can be done en masse from the mass edit screen if you're using one of the native date fields and not a custom date field)?
Could you make the entry sticky? Not sure whether that would override the start_on parameter or not.
Related
I'm looking for a way (using SuiteScript 2.0) to handle real-time persistent (stored) field updates, where a field might have changed in NetSuite (for example a lead time was just updated), and it doesn't matter if a user saved the change, or some other automated process changed that field. I just want to be able to pick up on that change:
The moment that it's done, and
Without regard for who or what kicked it off (e.g. it could be a person, but it could also be an automated change from a workflow, or a formula on the field itself which pulls values from another field)
Doing some research I found some options that looked somewhat promising at first. One being the afterSubmit event in a client script, and the other being the fieldChanged event. My issue however is, from what I understood those only really seem to be triggered by a user manually going in and making those changes, but this is only one part of the puzzle and doesn't seem to cover changes made outside of the scope of the user making those changes. Is that correct however? Or would one of those events still be able to capture changes done to that field regardless of who (or what) initiated or triggered the change, and right at the moment the change was saved/ persisted to the database?
UserEvents are basically triggers. In their deployment records you can set the context in which they fire so you can get them to fire in all circumstances (called contexts in Netsuite) but one.
That circumstance is User Events are not fired for record saves made in User Event scripts. i.e., if an AfterSubmit UserEvent script loads, changes and saves your record a fresh user event will not be fired.
Since I don't see the option in schedule properties of an agent, I was wondering if it's possible to run an agent once every 3/6 months, or even every year?
I only see -more than once daily,daily,weekly,monthly,never..
Pick the closest option in schedule properties, eg monthly, and then add code at the beginning of your agent that checks the date and depending on the result either exits without doing anything, or continues running the main body of the code. Works fine with agents written in lotusscript, never tried it with #formula.
I'm trying to create some sort of reservation system in SharePoint using a calendar list. It's been recommend to me to create events and add a column which allows a user to claim it. From there, claimed events would change color and only those who've claimed the event would have permission to unclaim the event.
This is what it would look like (see alternative option):
What I'd like to be able to do though, is instead of having to create three events like shown in the alternative option, creating 1 event (see original) and have that be broken down into 3 events or more, maybe using some form of drop down asking for intervals (ie. 15m, 30m, 1h). Based on the selected interval, it'd break the event accordingly.
A possible solution is in your main event you add another field named Interval.
The you design a workflow when you create the event that creates new events according to the interval specified using a while loop while incrementing the start time with your interval.
Those new events have a content type with a field named UserClaimed. you then associate another workflow to those new events that checks for that field and changes permissions on the event to only allow modifications of that event to the user specified.
This is the general idea, the implementation should not be that hard
just a thought -
I mean, the reason i think you want the events to pre-exist is so that users can easily create them in the correct time slot (rather than clicking the new item menu, which throws them away from the calendar view/context). Is that right?
If so, allow me to offer you this scenario:
If you are using KWizCom's Calendar Plus web part (yeah, I work for KWizCom...) it allows you to type in the event in the calendar itself directly.
Something simple like: "1pm-2:30pm Training meeting with Josh"
check the demo video here: http://www.kwizcom.com/sharepoint-add-ons/sharepoint-calendar-plus-web-part/overview/
Also, drag and drop events in the calendar to move them easily, and it also supports color coding events based on categories (meta data, views, sources, etc.).
The one thing you will need to develop is the unique meeting logic, and owner permissions.
meaning, an event handler that does not accept 2 meetings at the same time for the same room (define the unique resource field, if any), and the logic that allows only the person who created an event to edit or delete it.
ping me, I can help with the event handler - perhaps we can add this to our product, this is actually a cool idea. my work mail is shai at kwizcom dot com
How can a workflow be told to wait until a specific date, or date field?
It works with timeout equals date, but I would much rather use wait until process time is on or after date.
When I try this the workflow is postponed until our distant ancestors have died of old age; it is the same if I put in a date field instead of a specific date (which is the end goal):
You want to consider what is considered a "timeout" for the desired behavior. The following links provide some more context.
Also, unless you have a really specific use case for using a specific date (like year end deadlines or processing) -- you'll probably want to use a datetime field on an entity as the basis for the right side of the comparison. You can always use the dialog on the right to choose a fixed date/time before or after any of the entity datetime fields.
http://social.technet.microsoft.com/wiki/contents/articles/11291.microsoft-dynamics-crm-2011-workflows-wait-and-timeout.aspx
http://www.powerobjects.com/blog/2012/11/06/multiple-waiting-workflows-wait-conditions-and-timeouts/
http://www.dynamicscrmtrickbag.com/2009/07/12/waits-timeouts/
Yes, it will use the current value of the field each time the workflow is checked.
Related: CRM2011 Workflow: What happens if the field which is used in the condition of the workflow is updated after the workflow has started?
I'm currently writing an application that moves Notes documents between databases based on the amount of days that have elapsed from the creation/modified/last accessed dates. I would just like to get ideas on a simple and convenient way to create documents with specific dates, without having to change the time on the Domino server, so that I could test out my application.
The best way I found so far was to create a local replica and change the system clock to the date I want. Unfortunately there are problems associated with this method. It does not work on the modified date - I'm not sure how it is getting the modified date information when the location is set to Island (Disconnected) - and it also changes the modified and last accessed dates when the documents are replicated to the server replica.
Someone suggested trying to create a DXL of the document, modify the date time in the DXL file, then import it back into the database as a Notes document; but that does not work. It just takes on the date-time that it was created.
Can anyone offer any other suggestions?
You can set the created date for a document by setting the UNID (which is fundamentally a struct of timestamps, although the actual implementation has changed in recent versions). Accessed and modified times, though, would be unsettable from within the Notes/Domino environment, since the changes you make would be overwritten by the process of saving the changes. If you have a flair for adventure and a need to run with scissors, you could make the changes in the database file itself either programmatically from an external application, or manually with a hex editor. (Editing the binary will work -- folks have been using hex editors to clear the "hide design" flag safely for years. Keep in mind that signed docs will blow up badly, and that you need to ensure that local encryption is off for the database file.)
There's actually a very simple way to spoof the creation date/time: just add a field called $Created with whatever date/time you want. This is alluded to in the Notes C API header file nsfdata.h:
Time/dates associated with notes:
OID.Note Can be Timedate when the note was created
(but not guaranteed to be - look for $CREATED
item first for note creation time)
Obtained by NSFNoteGetInfo(_NOTE_OID) or
OID in SEARCH_MATCH.
Unfortunately, there's no analogous technique for spoofing the mod or access dates. At least none that's ever been documented, as far as I know.
I imagine given how dependent Lotus Notes is on timestamps (for replication, mainly), there isn't an API call that allows you to change the modified, created, or last access dates of a note. (More on the internals of Lotus Notes can be found here.)
I dug around the Notes C API documentation, and found only one mention on how to get/set information in the note's header, including the modified date. However, the documentation states that when you try to update that note (i.e. write it to disk), the last modified date will be overwritten with the date/time it is written to disk.
As an alternative, I would suggest creating your own set of date items within the documents that only you control, for example MyCreated, MyModified, and MyAccessed, and reference those in your code that moves documents based on dates. You would then be able to change these dates as easily as changing any other document item (via agents, forms, etc.)
For MyCreated, create a hidden calculated form field with the formula of #CREATED or #NOW. Set the type to computed when composed.
For MyModified, create a hidden calculated form field with the formula #NOW, and set the type to computed.
MyAccessed gets a bit tricky. If you can do without it, I suggest you live work with just the MyCreated and MyModified. If you need it, you should be able to manage it by setting a field value within the QueryOpen or PostOpen events. Problems occur if your users have only read access to a document - the code to update the MyAccessed field won't be able to store that value.
Hope this helps!